Overview
If you haven’t read it already, be sure to check out this post where I talk more about the motivation for this tutorial.
This MVC setup is perfect if you want to build an application like Jotlet.net, 280Slides.com, or even Gmail. If you’re aiming to build a more traditional web app like BaseCamp, Flickr, or Digg, then this still might be a good resource. A good rule of thumb: If you web application has 1 page load, then this is a great setup! If your app has more than 1 page load, read on anyways and you still might be able to apply some of these principles.
The approach I outline below - as with all my tutorials - is server agnostic. I’ll be using PHP to power the demos, but you can easily use Ruby, Java, or even Lisp! 
Goals
- Clean simple code
- Separate the logic of the view and the model
- Cache data on the client side - minimize AJAX calls
- Provide clean interface to data so disparate view objects can work together on same data model
- Maximize both model and view code reuse
The Tutorial
I’ve split this tutorial into multiple Phases. Each phase builds upon the previous, and each has its own demo and sample code that it walks through (and download!). So be sure to check them all out!
The first Phase sets up the foundation on which all the other’s will rely - so it’s a great place to start. Each next phase will add a bit of functionality onto the code from the previous phase.
- Phase 1: Loading data from the server
- Phase 2: Saving data to the server
- Phase 3: Managing Multiple and Relational Data Types (coming soon)
- Phase 4: Initializing the model with data (coming soon)
- Phase 5: Offline mode (coming soon)
17 responses so far ↓
1 Curtis
// Aug 6, 2008 at 8:12 pm
Wow, this is really good stuff already. Already learned quite a bit, can’t wait for the rest.
2 Happy Tarot » Code » Model-View-Controller in JQuery // Aug 6, 2008 at 8:44 pm
[...] Model-View-Controller in JQuery [...]
3 Joel Gascoigne
// Aug 8, 2008 at 4:36 am
I really like the idea of this concept, I will be keeping an eye on this for your later parts. May I suggest looking at the PHP function json_encode(), though
4 links for 2008-08-08 [delicious.com] « Talkabout // Aug 8, 2008 at 8:39 pm
[...] Model-View-Controller in JQuery "Goals [...]
5 links for 2008-08-09 [delicious.com] « Talkabout // Aug 9, 2008 at 8:35 pm
[...] Model-View-Controller in JQuery "Goals [...]
6 jQuery : the Official JavaScript Library of Listotron | Listotron Blog // Aug 10, 2008 at 8:48 pm
[...] can check out his extensive front-end Model-View-Controller JavaScript development pattern here. We will be applying this methodology to Listotron, so expect more specific examples and tutorials [...]
7 Joel Gascoigne
// Aug 12, 2008 at 6:35 am
Hi Adam,
I’ve actually been putting a heavily modified version of the model-view-controller pattern you describe above into practice in one of my current projects, as it is a rather large project and there is heavy use of AJAX throughout.
I have actually gone for having a model, view and controller object extended from jquery, smiliarly to you have it but I then have requirement for separate pages and therefore separate models, views and controllers. For example, I have a page named “create”, so I have a createModel, a createView and a createController which are extensions of model, view, controller.
Having been working with the pattern extensively for a couple of days, it seems to make the code very maintainable and clean, but I have come across one problem:
Have you thought about how to handle sending parameters when requesting items? Some items require different values sent back depending on one or more parameters sent to them.
I therefore modified the model to optionally accept parameters and go for POST rather than GET if indeed parameters are required. Seems fairly straightforward, right? Then there’s the problem of caching the same named item but for different combinations of parameters, and this is where I’ve come a little stuck. Caching seems a little redundant once you realise that if parameters are being sent then the response will be different a lot of the time.
I think this idea needs to be extended a little. There needs to be some way of storing items along with the set of parameters which was sent with the request for the item, very crudely put would be something like cache[item][parameters] - but parameters can be any number of parameters and possibly arrays to send too, so this quickly falls over.
This is rather long now! What are your thoughts on the matter?
Joel
8 adam
// Aug 12, 2008 at 8:41 am
Just to be clear - “caching data” in this MVC pattern isn’t referring to the browser caching AJAX requests automatically, as I think you’re describing here.
To fix that, I always opt for the browser never to cache AJAX requests. This can be done by sending back no-cache headers from the server. A less graceful solution is to add a random parameter to the end of the query string: ajax.php?rand=[random number].
The goal of the Model in the the client MVC is to cache data locally, so that we don’t have to AJAX as much in the first place. Asking the model for “Item number 5″ shouldn’t even fire an AJAX call if that item is already cached in the Model.
Keep your eyes out for Phase 2 of the tutorial - I hope to be finishing that up relatively soon. That phase will handle both loading and saving data to the server, and I think that will speak more directly to your app development.
Cheers
9 Joel Gascoigne
// Aug 12, 2008 at 10:45 am
I’m talking about caching data within the model, in order to avoid multiple AJAX requests for the same item. But the problem arises when you’re requesting items where you’re sending parameters.
For example, in most moderately sized web applications, you’re going to need more than just GET without any query string or POST parameters. This cropped up for me when using AJAX to retrieve a URL friendly title for a page, the “item” name may be “url_name”, but the value of the item will differ depending on the “full name” of the page for which that short URL is generated. So in this case you would request the “url_name” with a parameter “full_name”. So then retrieving “url_name” in the future returns the cached “url_name” which would not be the desired result, since the “full_name” may have changed.
I hope you understand the problem I’m describing now.
10 adam
// Aug 12, 2008 at 12:52 pm
Ah- I think I understand you now,
In the tutorial as it’s outlined in Phase 1, items are only cached by their unique ID. So if we needed to also be able to ask the Model for items based on something other than their ID (some other parameters in your request), then the cache is no longer very useful. I think this what you’re getting at?
The solution in this case ends up being much more application specific. It often ends up being useful to hash the data on much more than just the ID - maybe the created on date, maybe a user ID, in your case maybe “full name”. Then when asking the Model for data related to some other parameter, the Model can look up data in a 2nd or 3rd hashtable.
Stay tuned for Phase 3 where I’ll be solving a similar problem and caching data on more than just an Id.
Cheers
11 Joel Gascoigne
// Aug 12, 2008 at 1:28 pm
Yep I think you’re with me now - and I had thought about a hashtable approach, I think that’s the only real solution to the problem. Whatever the solution, it needs to be as abstracted as possible, and there may be good reason for certain items to never be cached.
I’ll be keeping tuned for the later phases, thanks again for opening my eyes to using the much used model-view-controller pattern client-side!
I expect I will be developing my own version of this, so I will let you know if I come up with some method for caching items with additional data - I certainly think it is something which is necessary in order to make this truly usable.
12 Peter C
// Aug 22, 2008 at 11:42 pm
Hi Adam and Joel,
Just googled onto this Ajax’ed MVC model. I’ve been looking at JavascriptMVC.com.
° I like your model involving Cache-V-C on the browser and MVC on the server. Would like to add that in some complex situations, you may need to synchronize data back to the server.
° I’m looking forward to implement this model and to put more intelligence on the browser to offload the server. There would be lots of security concerns (e.g. session info).
13 mohangk.org/blog » links for 2008-09-03 // Sep 3, 2008 at 3:06 pm
[...] Model-View-Controller in jQuery | Wulf An interesting ongoing tutorial on implementing the MVS stack within the browser (A-la JavascriptMVC.com). Looks intriguing and possiby a solution to the mess large javascript applications tend to be. However, the jury is still out (IMHO) as to the whether a MVC framework within the browser is really the best solution for this (tags: jQuery mvc framework AJAX tutorial) [...]
14 Bob
// Oct 3, 2008 at 2:47 pm
Your demo seems to be failing 100% of the time, not 10%.
INteresting stuff though
15 admin
// Oct 3, 2008 at 3:24 pm
@Bob
thanks for the heads up, everything should be working now
16 lambert
// Oct 30, 2008 at 10:58 am
when’s part 3 coming out? =)
17 Adam Wulf
// Oct 31, 2008 at 1:13 pm
@lambert,
soon? i hope? i’ve been swamped at work lately, but I’ll try and get it out asap
Leave a Comment