topics: functional programming, concurrency, web-development, REST, dynamic languages

Saturday, April 19, 2008

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


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
TriBook app 1
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:

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'];


return Ext.apply(view, {
init : function() {

Ext.each(['search','book','result'], function(id){;
});//make a nice graphical box on dom el

var roomform = v.RoomForm();

var roomview = v.RoomView();

var roomreserve = v.RoomReserveView();

}//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
TriBook app 1

TriBook app 1

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).



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: '',
fieldLabel: 'Date',
format: 'd/m/y',
name: 'date',
listeners: {
'change': filter,
'select': filter
fromCfg = {
id: 'roomform.from',
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
bodyStyle:'padding:5px 5px 0',
width: 310,
defaults: {width: 200},
defaultType: 'textfield',
items: [dateCfg , fromCfg, untilCfg, minCfg],
listeners: {
'render': function(){
dateField = Ext.getCmp('');
fromField = Ext.getCmp('roomform.from');
untilField = Ext.getCmp('roomform.until');
minField = Ext.getCmp('roomform.min');


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

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 function. You must really check out that trinity!

Sunday, April 6, 2008

There is still HOPE for templates...

I am interested in JavaScript. One reason I got interested in JavaScript was a discussion about templating languages with Trifork colleagues Joakim and Kresten (or perhaps it would be more correct to say that we were discussing better ways of implementing the View-part of traditional Model-View-Controller web applications). I ended up liking the idea that the best approach was to dump templates altogether and write the whole client application in a high-level language, i.e., JavaScript, rather than using any of the existing templating languages. Hence, the interest in JavaScript. In fact, I got so interested in JavaScript that I forgot all about templating languages again. That was until recently when I remembered the original discussion, and started thinking about templating again. It was actually some good fun thinking about this -- who would have thought? Anyway, enough about me... Here is the idea.

The language is called HOPE Templates, or just HOPE. The acronym is for Higher-Order Partially Evaluated Templates. Obviously two important ideas are (i) higher-order: templates are a type of functions and the input and output of these functions can be templates; (ii) templates are partially evaluated, meaning that general templates with multiple inputs can be specialized with respect to each input.

That's it! These two powerful concepts are the core of the language. I'll illustrate the HOPE idea through a series of examples.

Simple Template 1:

Hello World!

Any string is a (zero-order) template; when applied, the above template always outputs 'Hello World!'

Simple Template 2:

HelloTpl = λx.Hello x!
RuleTpl = λx.x, you rule!

This defines two named templates, e.g., 'HelloTpl' takes an input 'x' and outputs "Hello x!", where 'x' is replaced with what-ever the template is applied to. Note the use of λ for template abstraction -- this is to suggest the higher-order functional nature of templates (and it is concise too).

An important concept here is that any text in the program that is not a bound variable (or any language syntax) is just zero-order templates. Conversely, if a variable is bound by a lambda, then its occurrence means to 'insert the input template here'. We allow the α-conversion from the lambda calculus so that λx. Hello x! is the same as λy. Hello y!. This means that we can insert/apply templates without having to escape characters: if there is a clash we can always just α-convert.

So far nothing new.

Simple Template 3:

ConcatTpl = λx,y,arg. (x arg)(y arg)

This template is meant to be used as a higher-order template that takes two templates (x,y) and an argument (arg). It applies each template to the argument.

Example 1:

ConcatTpl HelloTpl RuleTpl ~
  λarg.(HelloTpl arg)(RuleTpl arg) ~
     λarg.(Hello arg!)(arg you rule!)

The application of a template is left-associative so the first line is (ConcatTpl applied to HelloTpl) applied to RuleTpl. The ~ is an equivalence relation invented for this blog posting. You can think of it as meaning 'is the same template as'. I haven't defined it formally, but it must be similar to the lambda calculus conversion rules.

I'm not sure about brackets yet. They are needed for grouping and are definitely not part of the output.

Partial evaluation. Consider the following template:

Tag = λname,clz,content.
<name class="clz">

This is just a normal curried function so we have

Tag div ~
<div class="clz">

However, we can do also partial evaluation (application with respect to one or more named arguments). For example

Tag clz:selected ~
<name class="selected">

Now I think it starts to get interesting ;-)

A final concept I would like is something like the following called operator definition. A simple definition could be:

Mine = λx.I own x!

An operator definition generalizes a simple definition by having variables on both sides of the equality symbol. For example:

x.y = λx,y,z.<x class="y">z</x>

This does several things. First it defines a named template '.', like

. = λx,y,z.<x class="y">z</x>

But it does more! It also allows for the following syntactic sugar: .highlight meaning

.highlight ~λx,z.<x class="highlight">z</x>

and e.g.

div.highlight ~ λz.<div class="highlight">z</div>


div.highlight HOPE! ~ <div class="highlight">HOPE!</div>

Combined with a notion of default values, this looks similar to something we seen before and like ;-), but I believe that it is much more powerful!

Here are a few notes to myself:

  • How do you implement it efficiently? I don't know. But on my language get-to-know-better list is Scheme, and it think this might be a good candidate language to use when implementing this. HOPEfully I will blog about that one day.

  • Dealing with data: lists and maps. Pattern-matching on data types. How much do we need?

  • Modules and imports... namespacing

  • whitespace

  • flexible language syntax: an idea where the language syntax can be redefined locally in case it overlaps too much with the template content...

  • This could make templating fun again ;-), but remember to stay within templating.