login/register

Snip!t from collection of Alan Dix

see all channels for Alan Dix

Snip
summary

When working on a web application that involves a lot of... the first things you learn is to stop tying your data to... too easy to create JavaScript applications that end up a... jQuery selectors and callbacks, all trying frantically t...
With Backbo

Backbone.js
http://documentcloud.github.com/backbone/#Introduction

Categories

/Channels/HCI stuff/implementation and architecture

[ go to category ]

/Channels/techie/JavaScript

[ go to category ]

/Channels/techie/web development

[ go to category ]

For Snip

loading snip actions ...

For Page

loading url actions ...

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 data are notified of the event, causing them to re-render. 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.

HTML

<p>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. </p> <p> With Backbone, you represent your data as <a href="#Model">Models</a>, 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 <i>"change"</i> event; all the <a href="#View">Views</a> that display the model's data are notified of the event, causing them to re-render. You don't have to write the glue code that looks into the DOM to find an element with a specific <i>id</i>, and update the HTML manually &#x2014; when the model changes, the views simply update themselves. </p>