I recently reworked the Djukebox UI. It's still ugly, but it uses way cooler things behind the scenes. The original incarnation had a main page which housed the player, a hidden iframe for uploading new tracks while letting the user continue browsing and listening, and another iframe for the current page content so that the player could keep playing while the user clicks around through lists of tracks and albums.

It worked pretty smoothly, but it's not cool and new. This is an old, hacky way of doing things. The point of Djukebox is to be a playground to do new things. The new solution is more interesting and adds even more options that can be implemented in the future. I decided to add a REST API and use a combination of ajax calls to that new API and a JavaScript templating system to update the page. The final combination I ended up with was Tastypie for the REST API and Handlebars.js for the JavaScript templates.

Tastypie was picked because its up to date and being actively developed as well as mostly straightforward and easy to use. Tastypie was easy to extend and add the functionality I needed to when it was missing it. The most interesting bit was making the details of related resources toggleable. By default the related resource details are either never shown or always shown as defined on the field in your resource. I wanted to be able to specify in the URL whether to give me details or not. What I ended up with was a little mixin based on this blog which allows me to add a "details" querystring parameter which takes a comma separated list of related resources to show the details of.

This isn't perfect. As the comment say, it uses the resource_name and collection_name, but those are not necessarily how they are named in the response. You also run the risk of creating an infinite loop of related resources, although fortunately Tastypie will catch that and blow up long before it eats up your server resources.

The handlebars templates also presented some interesting issues. The standard way of using handlebars templates is that you put the html template inside <script> tags in your html. Unfortunately, handlebars templates use {{tag}}, just like Django. When this is also a Django template, then the Django parser tries to deal with these tags. The solution to this is to put the templates into separate files, which is fine by me since I prefer separating them out anyway, and then use ajax to pull those in. I wrote some JavaScript which downloads my templates using ajax requests and then compiles them and sticks the compiled template into another JavaScript object so that I don't have to continually download and recompile them. Just to be safe, prior to using a template, I double check to make sure the cache object has the template there and if not, I download it with my function to update the display as a callback.

Here's a slightly shortened example: