Having discussed some player frameworks let’s come to the heart of the new engage player. We need to have a framework that ties the different plugins, handles the events and separates the UI from the data and the logic so we don’t have to do all that manually.
In this post I want to introduce backbone.js — backbone’s own introduction is self-explanatory:
With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a “change” event; all the Views that display the model’s state can be notified of the change, so that they are able to respond accordingly, re-rendering themselves with the new information. In a finished Backbone app, you don’t have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.
Let’s analyze some of the arguments and mention some other features:
- The new player should provide a basic API with events like “update”, “redraw”, etc. A plugin (e.g. a player or an annotation feature) throws events and implements event listeners for the defined events. So no plugin has to know about the other plugin(s)
- underscore.js used as the template engine
- jQuery used as the default library
- all that happens over a RESTful JSON interface
At the moment I do think that backbone.js would be a great choice. I don’t know, yet, whether the framework is too big or doesn’t fit our purposes for a player. So the question is whether we want to use backbone.js or some smaller frameworks tied together to have some more freedom. In the next posts I will discuss and introduce some of these other frameworks with a similar goal that would be a great choice as well.