caching MVC objects

usually when caching I like to try and cache the network requests. The reason for this is that it is easy to add on to a program without effecting anything else. Unfortunately this is not always the best way - especially when we can receive an object through more than one request. This can happen easily when using a framework that can request single objects and collections.

In my current project this is easily handled as a collection only returns a summary of the object, which means the only true way to get the full object is through a single request just for that. The problem comes when you can make a request for a collection that has the full information on an object. This isn't really an issue if we get the single object first and then get the collection - because we don't know what objects are in the collection. For single object caches to be useful when calling a collection we would need to be able to pass some indicator to the server which objects we already have in cache and then for the server to only pass back that those objects are in the collection rather than the entire information about the object. Then we'd need to change our collection reading to first try and get the object out of cache when parsing that collection.

Where this matters will be if a collection is read in first - providing all the information for an object - then we try to get that single object. If you're using a central store for your objects then this would be a good place to save the information. You can change the flow so that any part of the program that gets a model tries the store first (which it should anyway) and only then if it doesn't exist in the store should it try to query the server. We can then set the object's sync when reading from teh server to save it's information to some persistent local storage.

The trick is then where we read the local storage from. There are two options that I would consider. The first would be to update the store so that it reads all the saved information in at readtime. This is the quickest way as it can read in all the storage at once, however it may slow down the initialization of your program as it will have to parse the json in to your objects before becoming available.

The second solution would be to include the reading in to your sync. Instead of calling the server straight away it can look in local storage for the json data and use that. This is my preferred method as it keeps all caching code in the object sync - however if you have many different types of objects then it could lead to duplicate code across the different syncs, however you may be able to write some middleware or a mixin to handle this cache. It also means that you are only reading what you need out of local storage so although it may mean more reads (and it will have to check local storage everytime it tries to read an object externally) you will only bring in the information that is needed so there will be less memory usage and the reads will be spread out rather than all at once at the start of the application.

The V in MVC

I just read http://addyosmani.com/blog/digesting-javascript-mvc-pattern-abuse-or-evolution/ and it's got some good points. The main points you should take away is that there are already some great frameworks to work with and that there are many different approaches to the classic pattern. Most of these approaches are similar enough that you won't feel out of place if you switch between frameworks.

There is one point that I disagree with however, and that is that a view must know about the existence of models. I agree this is how a lot of frameworks work, especially when you think about ones that offer binding through templates or attributes on dom elements - but it doesn't have to.

I wrote PlastronJS and it follows a similar model as most MV* frameworks out there where the view is really little more than a template. The reason for this is that it's easier to get started and usually when you're doing a single page application there is no need for a great deal of abstraction.

So we turn our attention to the V in MVC. How can we have a view without knowing about the model? Well the easiest way is to build a view before building anything else. The second is to give it an interface that we can get, set and listen to and that's it. Here is a rather simple example:

View = function(text) {
  this.element = $('<div>').text(text);
}

View.prototype.setText = function(text) {
  this.element.text(text);
  this.emit('textChanged');
}

View.prototype.getText = function() {
  return this.element.text();
}

We've created a view. It can be updated by passing in text and if anyone makes a change to the view then it will emit that the text has been changed and the text can be read. It doesn't know anything about a models existence - nor what type of model. We could hook up any type of model to this view. Knowing about the model is the job of the control. The control is what knows about the model and the view.

So what is the advantages of having a separate view like this and not including it in with the controller or binding it in the DOM? Well for one thing the view does not have to know about the model. You can make simple and generic views that do things like display a text area or a graph and then re-use those views. You can also easily swap out views for different devices. If you want to change the view you won't have to change the rest of the control and it's bindings (unless it implements a different interface). There is also the possibility of building up larger views by adding together smaller views (it's like point-free programming for UI!)

So why don't more frameworks (including my own) do this? Well it's just harder to get started with and takes more code. You have to defined these views to begin with. Most people will look at it and think it's an awful lot of work to do to get a single page app going, and it is. You won't see and advantage to building an app with an abstracted view until much later in development.

**EDIT**

here is a little more detail about how to use it. Let's take the text view from above - we can use this to display any model. Let's say we have the user as a model - the user might have many different things on it (like usage limits) but we want to display the username at the top of the page. All we need to do is create a Control that pipes in the username of the model. So something like:

UsernameControl = function(model, view) {
  this.model = model;
  this.view = view;
  this.view.setText(model.get('username');
  this.model.on('username:change', function(username) {
    view.setText(username);
  });

usernameC = new UsernameControl(user, new View());

Now we may also have a shopping cart model and want to to display the amount, we can do exactly the same but create a shoppingCartControl, pass in a new instance of the view and hook up the total to the text. The trick is that the view stays generic and it's the control that hooks up what should be displayed. This is a simple example with only one parameter being passed through but you could build up views from smaller views or even have a view factory (one that will replicate the "text" div however many times you need for different values).

Initial Closure Meetup review

First of all, thanks to everyone that attended. We had around 35 people show up which is more than I ever expected when this was first put together. I think it shows the interest out there in the tool set and means that there is the ability to grow a solid community around the technology.

Thanks also to Nathan Naze who organized the space and took those newer to Closure under his wing - I'm sure they all learned a lot and there will be new users coming in.

The topics ranged throughout the talk and we covered a lot of bases as it was a round table discussion. One of the main subjects was work processes and how everyone used the tools. A lot of people use http://plovr.com/ or are now going to give it a go. The rest just use the scripts that come with the library with make or ant. Because of the interest our next meetup will be called "show us your stack" and I'm hoping to get a few people to take us through their workflow. I've put it up for a couple of months time at: http://www.meetup.com/Closure-Tools/events/68334272/ though it is far from confirmed. Let me know if you would like to share your setup, I'm thinking that a quick run through of a few people's setup will help (so anywhere from 5-30 mins just let me know how long you need).

Another important topic was the sharing of closure specific libraries. At the moment you can find projects in the wiki at: http://code.google.com/p/closure-library/wiki/RelatedProjects but it can be hard to find especially for new users. I'd like to see a communtiy driven website which can list libraries, externs, IDE setups etc. that we can share with each other. Anyone good at website design?

I also talked about a "starter pack" that would include projects like plovr, http://bolinfest.com/coffee/features.html, https://github.com/rhysbrettbowen/PlastronJS, https://github.com/rhysbrettbowen/G-closure and some gss style sheets (ala bootstrap), IDE components and a tutorial that could help users start on single page apps using interfaces and patterns that are familiar to them. I haven't started on the project yet but I'm hoping for contributions (especially with the IDE components) so we can lower the bar for entry into the toolset.

There was also some discussion about a package manager (perhaps a fork of NPM) which would help users with discovery and use of modules.

These are all really exciting propositions and the future looks bright.