So. I've converted the SongList of the Medialib view to use PropDict! There are still a few lingering bugs which I need to pop, and some more optimization would be nice. This of course uses the /mediainfo controller which means that we get temporary entries and then we swap them out when the mediainfo request calls back.

I also started on the quest to normalize my CSS namespace, which is now mostly done. This is a nice thing to have because it starts to make sense why things are where they are and the likes. It gets kind of confusing trying to figure out what you're swapping out when the CSS ids are ambigious things like ``entry.'' So that's fixed mostly now, with the occasional commit to chase a mistake or a forgotten id.

So last night I talked to my mentor and decided my first target should be to ressurrect the /mediainfo controller with my new PropDict. The idea behind the controller was to reduce the size of data pushed into javascript space. The way it mostly works now is that when you request anything that has metadata, for example playlist or medialib view, it pushes out a complete mediainfo dict for each entry in that list as a list to javascript space via the controller.

/mediainfo was basically a way to make lazy loading possible. Instead of returning lists of mediainfo dicts the other controllers would return list of medialib ids and then /mediainfo would be called to get the medialib dict when it was needed. So with that we can resolve parts of a list as it's being exposed.

One of those nasty things I had to do in my PropDict implementation was scary for-loop hell. So I've been worried about performance. Today I decided to look into how MochiKit finds indicies of entries in an array since that was largely my problem. What I learned was they did basically the same thing as me, iterate and compare (though they use their nice compare() function instead of if ( blah == blah ). At this point I decided to write a little benchmark app. It takes the start time, calls a function, takes the end time, and then swaps the time for a List Entry on an HTML Page (MochiKit.DOM \o/). What I learned is that the time difference between the implementations is almost negligable, usually within 0.001 seconds aside from some weird times where one call will take a seemingly long time. I do think I need to make the benchmark more complete testing a variety of functions and usage, but conversly it seems that either implementation would work.