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:
When working on a web application that involves a lot of JavaScript, one of the first things you learn is to stop tying your data to the DOM. It’s all too easy to create JavaScript applications that end up as tangled piles of jQuery selectors and callbacks, all trying frantically to keep data in sync between the HTML UI, your JavaScript logic, and the database on your server. For rich client-side applications, a more structured approach is often helpful.
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:
- A lot of the current code is composed of “jQuery selectors and callbacks, all trying frantically to keep data in sync between the HTML UI, [and the] JavaScript logic” — that’s one big reason that we want to rewrite the player, everything is being done by hand and that is quite a mess
- 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.
bwulff01
CallToPower
dbck
mabel86
rdgrrlf
Denis, this library looks interesting. If every model change on the client side is tied to a REST call to the server then it would be possible to move all of the tracking code into Java code, which would be much nicer (e.g. asynchronous inserts, reducing REST put requests, etc.). Does backbone.js provide any server side code, or just the templates/libraries for the client side? Will it work well with our REST infrastructure?
Chris, that would definitely be possible! Backbone.js does not provide server side code (as far as I know), it’s “just” the template engine/library/JavaScript patterns. A RESTful web service is exactly what backbone.js expects so I think it would fit pretty nice (example).
The benefit of this is that we wouldn’t have to change our server side approaches, which are already fairly well defined. Though it’s a bit unclear to me how nice this looks code wise, since the example binds all entities to a particular url, but in our rest code right now we bind to specific kinds of entities with different path parameters. The example code is….dense, but I imagine it would only need to be created once and could be put into an EntityFactory class of some kind on the Javascript side.
No, we don’t have to change much on the server side (maybe remove the shared resources and put the player in the actual module).
Backbone has a router (Backbone.Router) that has to be implemented by us, we can route any request to any site and we can use wildcards etc. for parsing, e.g. /series/series/:id or /series/series/*id.
Let’s say we want to implement an annotation function/plugin:
- create an ajax prefilter function that modifies the base url and the resource url of all ajax requests to grab the data from
- create an annotation collection (extend Backbone.Collection)
- define an endpoint in the collection
- create an annotation view (extend Backbone.View)
- create a new annotation collection
- fetch annotations via the collection (which fires up an ajax request)
- define a render function inside the view taht parses the data into a template
- create a new instance of the view
- let it render by any page (routed by the router).