ModelItem Problem!!!

[justin thomas]

So trying to add additional music specific information to MB and i realized it is probably impossible given the modelitem implementation that is stuck in MB core for the mcml. The major problem is that the Item implementation is not dynamic. 

My only other option is to package my music plugin with craigs theme and release it like that from now on. Which means really only his theme will have access to the specific music information. Which i dont really want to do.

The only OTHER way i can think of, is making item dymanic by using string indexers. 

Use a factory to register property resolvers and then add a call to item to retrieve these properties running through the registered properties.

so you will end up getting information in mcml from item by doing something like item["AlbumName"] or item.GetProperty("AlbumName") ... not to sure what will work in mcml.

WDYT?

thanks Justin

 

[Eric Reed]

That type of implementation will render the whole binding mechanism of MCML useless.  I don't think that would be a good idea.  MCML is wacked enough as it is.

 

What information are you trying to add?  Why does it need to be dynamic?   

 

The biggest issue with adding properties to Item (or any persistent data)  Is that it invalidates the cache.  The part that needs to be dynamic is the serialization but I'm not familiar enough with that implementation to tell how hard it will be to make it survive new persistent data without blowing the cache.  We have been waiting on a few new attributes people would like to see because of this issue.

--
You received this message because you are subscribed to the Google Groups "VideoBrowser Devs" group.
To post to this group, send email to videobro...@googlegroups.com.
To unsubscribe from this group, send email to videobrowser-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/videobrowser-devs?hl=en.

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.733 / Virus Database: 271.1.1/2647 - Release Date: 01/29/10 14:35:00

[justin thomas]

Well Music specific information is what i want to add, so that we can use it in the mcml, like lyrics, album, artist, track, etc etc etc etc.

it would be nice if it was dynamic cause we (anyone, not just code MB developers) can add information that can be used in the mcml also the whole plugin architecture is dynamic so surely that would need to follow suit, i dont understand how this will invalidate the cache, because the Item is not persisted, it is purely used as an modelitem (implements IModelItem) which is necessary for the stupid mcml, as far as i understand.

I also dont see how it is going to render the binding useless, the old stuff can stay, having said that apparently the mcml cant call a function and use the returned string so it probably wont work, unless that is wrong and it can.

Sorry if i sound like a bastard, but this has really put a pebble in my panty :)

[Eric Reed]

LOL.

 

I'm pretty sure item is persisted - at least the metadata parts of it which is what you are talking about - more metadata.  Of course, if you wanted to add this stuff and NOT persist it then it wouldn't affect the cache.  You could add a dynamic field like you suggest and not persist it but that means you would have to load it from the source every time and that seems like a pain when we have this nice persistence model.

 

There's a couple bits I'd like to see added at the metadata level so I could be convinced to bite the invalid cache bullet for Thunderblade.  We'd just want to add a line to the installer that blows the old cache away so we are sure we re-build it properly.  Not sure how Sam and Jas feel about this, though.

 

You can invoke a method that returns a result from MCML and you can pass it parameters.  However, you would have to take care of managing the display yourself because you couldn't use binding.  It could be done but might be ugly and who knows how it will perform and each theme will have to be coded properly to support it.

 

Any way you could accomplish what you want with specialized baseitems and overrides of already existing properties (like summary)...?

Version: 9.0.733 / Virus Database: 271.1.1/2647 - Release Date: 01/30/10 02:35:00

[justin thomas]

Aren't BaseItem's (Movie, Song, Series etc) persisted - i am talking about Item, neither of which extend the other. 

Extending movie is not a good option, seems very nasty. Not only that it will break a lot of the if (baseitem is Movie) logic.

So what i am thinking of is implementing an interface that i will share with others ie theme developers - this is also not a good solution, because it creates unnecessary dependencies but is my only option. It will make it hard for theme devs to get the information but what must i do.

thanks for your input.

[Eric Reed]

You already have a sub-classed baseitem for "song" don't you?  You simply need to hang your specialized type off of the chain where ever it makes sense.  "Album" and "Artist" would be derivatives of "Folder" I would imagine.   But, of course, the problem is that there is no way for anything else (other than your plugin) to know about these types...  Hence the interface you are talking about, I guess.

 

I don't think this is necessarily a horrible implementation, though, because themes need to account for this specialized information in their layout anyway.  Rob already does this with Vanilla doesn't he?

[Eric Reed]

What if we defined a single, extensible field on baseitem like you suggested and then an interface to add fields and values and retrieve values.  Then, this field would be "known" to the whole of MB and could then be interacted with by the core, any theme, or any other plug-in...

 

This field could be a simple dictionary keyed by a string with a specialized class that defines the type and value (and whatever else needs to be there) as the member.

 

Of course this creates the cache issue but I think we could deal with that.

[Sam Saffron]

You can extend your Song instance all you want and the access it via ModelItem.BaseItem the UI plugins will have to do some work to ensure that the type of the baseitem matches Song before grabbing bits of data. 

As for allowing anyone to hang any bit of information of any item, im kind of against it, its a support nightmare. If we need to extend Movie to allow for more fields so be it. But big fat salad Im against. 

So to recap, subclass baseitem / show / movie / whatever to allow for extra fields in your plugins, this will be persisted. 

Extend IShow et. el with any common required functionality. 

Perhaps consider some fancy helper in ModelItem that enables late bound error free access to fields (Eg, GetProperty("Foo") which will call BaseItem via reflection and handle errors) 

[justin thomas]

Song is not accessible from the theme, because it is part of MusicPlugin so casting of baseitem in a theme is out. - cant do.

Extend Movie (ie Song:Movie) kind of blows the whole idea of inheritance out the water, that is such a bad idea i don't even want to think about it. - wont do.

Reflection on each property of each song in a 250gig collection thats going to be very slow. - wont do.

There are really 2 options in my mind, add the properties to ITEM or combine the music via a interface with a theme, which will make it hard for other theme devs. I am probably going to go will the latter because i am forced too. I dont even want to begin to explain how difficult it is to do this ....

[Sam Saffron]

Justin, 

Something got lost in translation. 

You already have your class Song, it inherits off Music which in turn inherits off Media which is fine and should not change. 

It has properties that are persisted in the backend (MediaType, RunningTime and MediaInfo)  there is some overlap with the videos stuff so perhaps a new base interface for stuff with mediainfo and running type and mediatype should be introduced. 

You are asking, how can a UI plugin that does not reference the Music plugin display these properties. 

1. MCML is late bound, the theme should be able to access ModelItem.BaseItem.RunningTime just fine. It just has to make sure its dealing with a Song so this works. 

2. Reflection does not have to be slow, in fact have a look at my light weight code gen stuff. It is ultra fast. The UI is not walking through the whole 250gigs of music, it is displaying a single item, the overhead of traditional reflection is minuscule in this context.