Introducing Backbone.js…

Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions,views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.

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.

This is similar to most other template based general purpose javascript frameworks today, and the way Backbone.js is approaching is code centric and gives the developer a high degree of very finely granulated control over how the application is tied together and driven…

Backbone Aura is a decoupled, event-driven Backbone architecture for developing applications and can in the same sentence be coined as a General Purpose Application Micro Architecture.

The application is broken down into AMD modules that contain distinct pieces of functionality (eg. views, models, collections, app-level modules). The views publish events of interest to the rest of the application and modules can then subscribe to these event notifications.

All subscriptions go through a facade (or sandbox). What this does is check against the subscriber name and the ‘channel/notifcation’ it’s attempting to subscribe to – if a subscriber doesn’t have permissions to do this (something established through permissions.js), the subscription isn’t allowed through. The rest of the application is however able to continue functioning. 


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s