Now that the JavaScript extensions are released, I have spent some time debating on where to begin with the main core of the library. That is, the MVC portion. I want to make sure that I have time to contribute to this blog on a regular basis (something I am struggling with already) while at the same time not losing focus on my other projects. Hence, I need to find a balance.

My decisions of what to blog and what code to share will be based on the needs of my current project. Hopefully, this project will proceed in a logical, orderly manner (ha, ha, ha), and so the JavaScript library can be built at the same time and also in a logical, orderly manner (getting that dreamy look in my eyes just thinking about it). More importantly, and perhaps more difficult, I must resist the urge to use already existing libraries which might make my project go faster.

Of course, in this I have already failed. I am already using the YUI Testing Tools. But, at least that’s only on the developer side, and not the end-user side.

Anyway, I finally decided that since the View is where it all starts (user input) and stops (system output) in an MVC architecture, that it would be a good place to begin. Also, I typically develop with the user interface first, since the UI really describes how the application should function, so it makes sense to begin with the View. With all that said, I do want to point out that my first and foremost priority is to get the “plumbing” in place. Therefore, I’m not going to spend a whole lot of time on fancy animations and other visual icing. And I’m sure I’ll be delving into Controllers and Models fairly quickly, since a View without them won’t really do anything useful.

What is this MVC of which you speak?

So, how about an MVC review before we get started, eh? MVC stands for Model-View-Controller, and represents the holy triad of application design.

The Model is the representation of the real-world data that makes up the application. The model is typically a database model, but could be any internal representation of real data.

The View is the visual presentation of the Model, and its the only portion of the MVC architecture that the user will interact with. Typically, the view is associated with the computer screen, but it could be just a small section of the computer screen or some other representation of the data, such as a printout.

The Controller is responsible for application state. It handles the communication between the View and the Model. When a user makes a gesture on a View to save data, by clicking on a “Save” button for example, the Controller passes that request and the data that was submitted to the Model. The Model then saves the data and passes the results back.

The MVC rules of engagement

That’s the MVC in a nutshell.  But to be more specific, here are the rules I will follow when implementing MVC in this library:

Model Rules

  1. Can read and write data directly to the underlying store (i.e. the server).
  2. No interaction with the user.
  3. Does not directly change the application state, but can change application data.
  4. Does not listen to any events (it is told what to do, then it fires events to report results).

View Rules

  1. No direct access to underlying data store.  Can only read data through a Model (cannot request the Model to update any data).
  2. Heavy interaction with the user (user gestures are fired as events to Controllers).
  3. Does not change the application state (but can change its own state, for example to show visual cues to the user).
  4. Listens to events from Models (application data changes) and Controllers (application state changes).

Controller Rules

  1. No direct access to the underlying data store.  Can read and write data through requests to a Model.
  2. No interaction with the user.
  3. Controls and directs all application state changes (makes requests to the Model to change application data).
  4. Listens to events from Models (application data changes), Views (user gestures) and other Controllers (application state changes).

Here is the short version of those same rules:

  1. A Model does NOT alter the state of the application, and does NOT interact directly with the user or format data for display.
  2. A View does NOT change application data and does NOT change the state of the application.
  3. A Controller does NOT change application data, and does NOT interact directly with the user or format data for display.

So there you have it, the basic rules for the library. I’ll try to post code often, even if it is incomplete, so you can see not only what I’m doing, but also why I’m doing it. Look for the first installment next week (I recommend subscribing to the RSS feed)!