The JS model layer

Gravatar
08 Mar 2010

To build the best possible JS RIA, we need to build a data or model layer. This needs to be handled in a way which goes beyond simply embedding the data in the HTML, and also beyond relying on simple collections of hashes and arrays.

A web server needs to send data to the client, as part of an initial "platform" which the client can build up the UI and behaviour from. A client therefore holds onto and manages this snapshot of "state" which it has received from the server.

The lifecycle of these data objects need to be managed on the client end, persisting the state (when necessary) as part of the process. A "state manager" needs to work with collections of objects, which can be manipulated locally and bound to the UI.

js-model is our solution to this. It should feel straightforward and familiar to you - particularly if you're used to ActiveRecord and its ilk.

This is possibly the hardest part of a Javascript MVC framework to standardise on. More than anywhere else, it is open to interpretation and differences of opinion. I will briefly run through a number of different options moving towards the kind of thing I like.

I am going to focus on non-degradable functionality, and am tallking about the types of RIAs that would previously have been done in Flash. I'm a firm believer in the capabilities of using HTML 5 to build almost native feeling apps.

HTML5 WebSockets give you a persistent connection between server and browser which you can use to send text data back and forth. Here we explore an event-centric message format on top of WebSockets to ease the development of Javascript Real Time Applications.

Let them eat State

Gravatar
05 Feb 2010

In the past, there has been a noticeable level of scorn for the "View" part in web-based-MVC architecture. Phrases such as "putting too much logic in the view" are often apt, but can be unhelpful when looking at the bigger picture. This has led to people trying to write UI code/behaviour from the comfort of their area of familiarity - Server code.

The main reason why I believe we ("Server-side" devs) need to rethink this attitude relates to statefulness.

There are several aspects to building javascript UIs, and you need to do a bit of planning beforehand if you want them to be successful. 2010 is set to be the year of Javascript's ascendancy, and you can't ignore it. You also need to start using it properly (if you aren't already). We have evolved beyond the level of chucking event handlers inline in views and it is not possible to just hope for the best as things get more complicated.