HTML-free Web-applications with ExtJS [Designing client/server web-apps, Part I, Section III]

Recap

This article is Part I, Section III of a series discussing the development of client/server web-applications where the client is written in JavaScript and running in a browser. The first article discusses the use of namespacing in large JavaScript applications; it can be found here. The second article gives a high-level overview of our design, and introduces the model part of Model-View-Controller.

This third section of Part I discusses the View in MVC, introducing the concept of HTML-free views in web-applications.

Below is a sample image of the GUI for our client application. It is no so much the application that it interestering, but rather it's design and implementation.

TriBook - a simple room-booking client application

Click for large image


The view package object
The package object com.trifork.tribook.view contains all the objects and constructor functions related to the graphical user interface of the client. Particularly, it contains a special singleton object, View, which is an observable object, observed by the Controller; view objects also observe the model, reacting to and reflecting changes.

Apart for the singleton View, the package also contains constructor functions for the various components that exist in the client GUI. In our example room-booking application, TriBook, we have a few such components:

• com.trifork.tribook.view.RoomForm
  a form-component for entering query data about available rooms


• com.trifork.tribook.view.RoomReserveView a list component that shows a list of rooms to reserve at certain times


• com.trifork.tribook.view.RoomView a list component showing the list of available rooms that match the current query in the RoomFoom component.

The View object composes the view using these three components. For example, View contains this code:

namespace("com.trifork.tribook.view");
using(com.trifork.tribook.view).run(function(v) {
 
  v.View = (function() {//singleton module pattern
   var view = new Ext.util.Observable(),
       events = ['addreservation','removereservation','query','reserve'];
   
   Ext.each(events,function(e){view.addEvents(e);});
  
   return Ext.apply(view, {
       init : function() {
     
         Ext.each(['search','book','result'], function(id){
              Ext.fly(id).boxWrap();
         });//make a nice graphical box on dom el
         
         var roomform = v.RoomForm();
         roomform.render('search-inner');
     
         var roomview = v.RoomView();
         roomview.render('result-inner');
     
         var roomreserve = v.RoomReserveView();
         roomreserve.render('book-inner');
    
       }//some details omitted here
     });
  })();
});

The code constructs the custom components and tell them to render themselves to various dom elements, e.g., 'search-inner'.

The other important role of View is to define a collection of 'logical' or 'application' or 'domain' events, which the controller (and other view components) may react to. The application events in our room booking app are defined in the events array, e.g., 'query' fires when the user changes the current query in the RoomForm, representing the action of searching for available rooms in a certain time period. 'addreservation' adds a room and a period to the queue of rooms to be reserved (represented as a com.trifork.tribook.model.Reservation object). 'reserve' represents the event that the user wants to actually commit to reserving the rooms in the queue of reservations.

The View object itself doesn't actually contain the code that fires the application events; this code is in the individual view components. E.g., RoomForm fires the 'query' event on View in response to the user changing the form field values (if they validate).

Another way of thinking of this is in terms of event bubbling. Just as DOM events bubble up the dom tree, one can think of the application event 'query' bubbling from the RoomForm object to its parent, the View object. In this way, interested listerners can listen centrally on View and doesn't have to be aware of the structure (i.e. the individual components) of the GUI.

Regarding the use of machine code... (HTML)
The client UI is written without using HTML.

Actually that last statement is not true... However, using ExtJS with say YUI as a base, one has a multitude of high-quality, easily composable and configurable GUI components that are much more high-level than the ubiquitous text markup language. In our view markup is used in two ways: for highly specialized view components and for representing page structure at a high-level. For the latter, the HTML (declaratively) describes the logical placement of three components at the same level: a form, a component for showing a list of rooms, and a component for showing a list of reservations. That is it. The divs are transformed into specialized components using JavaScript. For the second point (highly customized components) we still leverage JavaScript (specifically ExtJS components, XTemplate and DataView).


First let us take a look at a form for entering room search criteria. It's a pretty standard web application form except that it is built entirely in JavaScript. The components are so standard that we just need to compose the fields and specify validation and event handling; no HTML or CSS involved. Here's a sample image:

TriBook - search form with input assistance and validation





Lets look at some code. One interesting thing to notice in the code below is that although we are writing UI code in JavaScript, the ExtJS framework allows for a highly declarative specification of UI components using configuration object literals (the *Cfg variables below).

namespace("com.trifork.tribook.view");

using(com.trifork.tribook.view).run(function(view){
 
 var model = com.trifork.tribook.model,
     ctrl = com.trifork.tribook.controller;
 //utility fields and functions defined below
 var dateField,fromField,untilField,minField, getCurrentPeriod, filter;

 view.RoomForm = function() {
       var dateCfg = {
            id: 'roomform.date',
            xtype:'datefield',
            fieldLabel: 'Date',
            format: 'd/m/y',
            name: 'date',
            listeners: {
               'change': filter,
            'select': filter
            }
           },
           fromCfg = {
            id: 'roomform.from',
            xtype:'timefield',
            fieldLabel: 'Free from',
            name: 'time',
            format: 'H:i',
            increment: 30,
            minValue: '09:00',
            maxValue: '17:00',
            listeners: {
                  'change': filter,
                  'select': filter
            }
           }, 
           untilCfg = { ... },
           minCfg = {
             id: 'roomform.min',
             fieldLabel: 'Min. size',
             name: 'size',
             validator: function(v) {
                 if (isNaN(Number(v))) {
                    return 'Please enter the least number of people that must be supported by the room.';
                 }
                  return true;
             },
           listeners: {
              'change': filter
           }
     };
  
 
     var form = new Ext.FormPanel({
         labelWidth: 75, // label settings here cascade unless overridden
         frame:false,
         bodyStyle:'padding:5px 5px 0',
         width: 310,
         defaults: {width: 200},
         defaultType: 'textfield',
         items: [dateCfg , fromCfg, untilCfg, minCfg],
         listeners: {
          'render': function(){
              dateField = Ext.getCmp('roomform.date');
              fromField = Ext.getCmp('roomform.from');
              untilField = Ext.getCmp('roomform.until');
              minField = Ext.getCmp('roomform.min');     
          }
         }
       });
 
       model.Model.rooms.get().on('load',filter);
  
       return form;
     };
        //detail omitted
});

The filter function that is called when ever the form changes will validate the form; if valid, an event 'query' is fired signaling that the user has queried for available rooms. Notice that the 'query' event carries a parameter, a domain object called a RoomQuery that captures the essence of the query.

...
function filter() {
   var p = getCurrentPeriod(),
       v = +minField.getValue(); 

   if (p === null || isNaN(v)) {//Not valid
 return;
   }
   
   view.View.fireEvent('query', new model.RoomQuery({
      start_at: p.start,
      end_at: p.end,
      min_size: v
   }));
}
...

The main points...

• Events and event bubbling. Our application is event driven. Just like dom events bubble up the dom tree and listernes can listen at different levels, our application event bubble up the component tree, e.g., from the RoomForm to the View object. This principle is useful for decoupling for two reasons: (1) observers can attach listerners at different levels of abstraction, e.g. other view objects which may know about the view structure may listen directly on a view component, while listeners in the controller package object may listen directly on the View object, not caring which concrete UI component is the source of the event. (2) individual UI components can focus on mapping dom events to application events with domain concept parameters; they need not be concerned with how those application events are handled.


• HTML-free views. Except for highly customized components, the view is HTML free. This lets us work at a much higher level of abstraction, i.e., configuring and composing components rather than creating markup tags, and manipulating the dom tree.


• ExtJS (once again). In version 2 of Ext, components can be specified mostly in a declarative manner which is much more succinct and less error prone. Components are highly customizable and extensible. Even when low-level specialized components are needed ExtJS has support. The brilliant function Ext.DataView combined with Ext.XTemplate provides a powerful tool for presenting lists with tailored HTML; the lists are neatly abstracted with the Ext.data.Store function. You must really check out that trinity!