Using MVC/MVVM/MVB in JavaScript for Rich Application Interfaces.

Rich Applications Interfaces make heavy use of JavaScript to create the desired user experience.  Structuring and organizing that Javascript code is a bit of art and we are now seeing the emergence of "frameworks" such as Backbone.js to assist.  It is somewhat odd that it has taken this long to mature this area.

The underlying issue I think is that the web community started using Javascript for "glitz" rather than rich UI's.  As a result, much of the teachings and tutorials focus on using JavaScript to make your web-page look attractive.  For example, one has all sorts of animations and slideshows, fading effects, etc.  Each of those "glitzy" examples tended to be a local effect and required no coordination with other elements on the same page.

As an example of a rich UI, consider a screen which is used by customer support to locate a particular customer.  Part of the screen consists of "Live Search" where the system is searching for a customer.  As the representative types, AJAX queries are sent to the backend server to obtain a list of possible candidates.  The representative selects one customer from the possible matches and expects the screen to display enough information to verify they are working with correct customer.

In this example, we have multiple coordinated entities on the screen.  These are the user input for the search, the possible customer list, along with a detailed view of the selected customer.  Let's visit each entity and describe how it is expected to work.

Search Input

The search input is a text input with validation.  As the user types, the input is validated and a possible auto-complete suggested.

One thing that is important in the UI is that user input is not blocked waiting for AJAX responses.  So our input cannot spin-wait for a response.  It also has to account for the AJAX call being asynchronous and possibly having a large latency.

This suggests a simple MVC for the user input.  The user input keeps tracks of what the user types and provides validation.

There is a model in this UI component which contains what the user typed and its validity.  It generates events when the underlying model changes.

Possible Customer List MVC

The possible customer list component could be thought of as a service (or an actor) whose job is to retrieve a list according to the current search criteria. It might generate an AJAX request each time the search input changes.  

This component has a model which is comprised of:

• A (conceptual) queue of input search criteria
• The result set
• A flag indicating an outstanding AJAX request

In MVC terms, control over the model happens by pushing a search criteria to the front of the queue.  The result set is what is viewed.

JavaScript programming is inherently single-threaded.  One often shifts to message-driven design concepts in order to capture behavior.  In the case of this component, it responds to two messages (aka events).  One message is the arrival of new search criteria.  The other message is an AJAX response.

The arrival of a new search criteria message results in the following behavior:

• The criteria is pushed onto the queue
• If the queue is not-empty and there is no outstanding AJAX request, send an AJAX request for the search criteria at the head of the queue.
• Mark the result set as invalid.  Notify any listeners if there is a result state change

The AJAX response message processing is:

• Clear the outstanding AJAX request flag
• If the search queue is empty, we know that the search was the most up to date.  Then:
• Update the result set and mark it as valid
• Notify all listeners
• Else:
• Discard the response and leave the result set as invalid
• Drain the queue until the last element is reached
• Submit an AJAX request for the last element

Note that this is a simplified version.  One often uses timers to notice when the user has stopped typing to avoid sending excessive AJAX requests.  Timer expiry is handled as another form of message arrival.

Note as well that this MVC does not touch the user presentation.  It is purely a behind-the-scenes service.

Presentation of the Possible Customer List

This MVC is wrapped around a "select 1 of N" component.  The MVC listens to changes in result set status and updates the underlying component.  It provides a view of the current selection.  It notifies listeners when the current selection changes.

Presentation of the Selected Customer

This is an MVC as well.  It responds to changes in the current selection as well as AJAX responses.  Like the possible customer list, it needs to address changes in the selected customer while it has an outstanding AJAX request.

Next post: aligning this design with published MVC/MVVM/MVB principals.