Syntax-highlighting in web pages

You shouldn't see this page really ;-) I've moved the blog to:

http://blog.higher-order.net

Please update your feed reader, and go to:

http://blog.higher-order.net/2008/07/29/syntax-highlighting-in-web-pages/

to read the post.

Moving blog...

I am moving my blog to: blog.higher-order.net.

Please go to that URL for further updates...


-- Karl

Manual code specialization:a poor-mans partial evaluation in JavaScript

Recall the object function that Douglas Crockford is promoting in his work on prototypal inheritance in JavaScript:

function object(p) {
  function F(){}
  F.prototype = p;
  return new F();
}

The object function creates a new object which has the input object (p) as it's prototype.

On the comp.lang.javascript newsgroup Richard Cornford showed a functionally equivalent version which has better performance in general:

var object = (function(){
   function F(){}
   return function(p){
      F.prototype = p;
      return new F();
   };
})();

In this version, all invocations of object share the same F which has its prototype mutated with each call. Cornford argues:

[The first version of 'object']... is an example of the process that clearly expresses what is being done, but is not particularly efficient as it creates a new - F - function each time it is executed, but all of those - F - functions are essentially identical. If this is to be done often then a more efficient approach would be to only create a single - F - function and put it where it could not be modified by external code.

Now, it is important to notice that in general one has to be careful when applying this technique to recursive functions as a variable mutation in one level of recursion may affect others. Also, if we were to put threads into JavaScript, this code would go from being thread-safe in the original form to non-thread safe in the optimized form. However, for now, this technique can be applied in performance-critical functions.


In fact, there is a general technique here that one might call code specialization via higher-order functions (which can be seen as a poor-mans form of partial evaluation). Here is a simple example of that general technique: The 'mk_tag' function creates the string for an html tag with a class attribute and a text-contents.

function mk_tag(tag_name,clazz,contents) {
   return '<'+tag_name+' class="'+clazz+'">'+contents+'</'+tag_name+'>';
}

Using code specialization via higher-order functions (by currying), we can make specialized functions for writing e.g. 'div' tags, and specialized (faster) functions for making 'div' tags with certain classes. The trick is to compute as much as is possible with the given inputs before returning the specialized function:

//a curried version which specializes to it's input
function curried_mk_tag(tag_name) {
  var tag_hd = '<'+tag_name+' class="',
      tag_tail = '</'+tag_name+'>';

  return function(clazz) {
     var head = tag_hd+clazz+'">';
     return function(contents) {
         return head+contents+tag_tail;
     }
  }
}

var mk_div = curried_mk_tag("div")
var mk_div_green = mk_div("green")
var mk_div_blue = mk_div("blue")
mk_div_green("karl")//<-- "<div class="green">karl</div>"
mk_div_blue("karl")//<-- "<div class="blue">karl</div>"

This is elegant as functions can be reused, e.g., 'mk_div_green("karl");mk_div_green("krukow")'. But notice that it is more efficient than simply using a general currier (e.g., Diaz); essentially it is a form of manual partial evaluation.


I'll post some performance measurements in a later posting, but initial results show that we can reduce execution time by roughly 40% by using the sharing form of the object function.

More Examples

I'm not sure how many JavaScript programmers are familiar with this type of optimization. Here are a bunch of real-world examples where it can be applied:

Prototype - Ajax.request function

var Ajax = {//original
  getTransport: function() {
    return Try.these(
      function() {return new XMLHttpRequest()},
      function() {return new ActiveXObject('Msxml2.XMLHTTP')},
      function() {return new ActiveXObject('Microsoft.XMLHTTP')}
    ) || false;
  },

  activeRequestCount: 0
};

The thing to notice here is that every time getTransport is called prototype will recompute which XMLHttp transport to use. However, the result of Try.these will always be the same in a particular run of Prototype, i.e., the showing of a page in one browser. So we might as well precompute which object is the correct one:

var Ajax = {//modified form
  getTransport: Try.these(
         function() { new XMLHttpRequest(); //test if it exists
            return function() {return new XMLHttpRequest();}
         },
         function() { new ActiveXObject('Msxml2.XMLHTTP'); //test
            return function() {return new ActiveXObject('Msxml2.XMLHTTP'); }
         },
         function() { new ActiveXObject('Microsoft.XMLHTTP');
            return function() {return new ActiveXObject('Microsoft.XMLHTTP'); }
         }),

  activeRequestCount: 0
};

jQuery - attr function

//original...
attr: function( name, value, type ) {
 var options = name;

 // Look for the case where we're accessing a style value
 if ( name.constructor == String )
  if ( value === undefined )
   return this[0] && jQuery[ type || "attr" ]( this[0], name );

  else {
   options = {};
   options[ name ] = value;
  }

  // Check to see if we're setting style values
 return this.each(function(i){
  // Set all the styles
  for ( name in options )
   jQuery.attr(
    type ?
     this.style :
     this,
    name, jQuery.prop( this, options[ name ], type, i, name )
   );
 });
}

With jQuery we can't write a curried form as that would break compatability. However, we can still perform optimizations like what we had with the 'object' function. Notice that the function supplied to 'each' is created with each invocation of 'attr', you can also see a for-loop where a check to 'type' is made with each iteration. In our optimized version, attr chooses which inner function to give to 'each' by checking type first.

//modified form
jQuery.fn.attr = (function(){
    var type,
        options,
        inner_type = function(i){
          // Set all the styles
          var t  = type,
              s  = this.style;
          for (var name in options ) {
              jQuery.attr(s,
                          name, 
                          jQuery.prop( this, options[ name ], t, i, name )
              );
          }
        },
        inner_no_type = function(i) {
          for (var name in options ) {
              jQuery.attr(this,
                          name, 
                          jQuery.prop( this, options[ name ], null, i, name )
              );
          }
              
        };
    
    return function( name, value, t ) {
                type = t;
                options = name;
  // Look for the case where we're accessing a style value
  if ( name.constructor == String )
   if ( value === undefined )
    return this[0] && jQuery[ type || "attr" ]( this[0], name );

   else {
    options = {};
    options[ name ] = value;
   }

  // Check to see if we're setting style values
  return this.each(t ? inner_type : inner_no_type);
 };
})();

fun with with - part II

Here is one implementation of a function 'scope' which lets us write code like:

with (scope({ sn : dk.ourclient.supernavigator, 
              u : com.trifork.utils})) {
  
            
  with(sn) include()(model,view)
  with(u) include()(Format)
  
  run(function(mod,view,fm){
        //do stuff
  });
}

The function that is given to 'run' will be called with variable 'mod' bound to dk.ourclient.supernavigator.model, 'view' bound to dk.ourclient.supernavigator.view and with 'fm' bound to com.trifork.utils.Format.

Note that it is important that the function given to run is executed in a scope that does not see the functions introduced by the outer 'with' statement - this would be dangerous. In order t acheive this, the variable 'run' 'include' and 'sn' and 'u' are written so that they can only be used one time: once called they delete the reference to them selves. Similarly, suppose com.trifork.utils has a property 'include' then if we did:

 with(u) include()(Format,include)

we would expect the 'include' from u, and not the include function from our "package DSL".

This code does that (though I haven't tested it thoroughly):

function scope(spec){
    if (spec.hasOwnProperty('module')) {
        throw new Error('Reserved word "module" may not be used.');
    }
    if (spec.hasOwnProperty('run')) {
        throw new Error('Reserved word "run" may not be used.');
    }
    
    var objects = [];
    
    for (var p in spec) if (spec.hasOwnProperty(p)) {
       spec[p] = object(spec[p])
       spec[p].include = function(){
          delete this.include;
          return function(){
              for (var i=0,N=arguments.length;i<N;i++){
                  objects.push(arguments[i]);
              }  
          };    
       };
    }
    spec.run = function(fn){
          for(var p in this) {if (this.hasOwnProperty(p)) {
              delete this[p];         
          }}
          return fn.apply(objects[0],objects);
    }
    return spec;
}

fun with with

WARNING: After reading this blog you may start playing around with the evil 'with' statement in JavaScript. It's actually quite fun, but note that I'm not encouraging it's use in general.

In a previous blog I advocated the use of namespacing in JavaScript programs. To support namespacing I presented a pair of functions 'namespace' and 'using'. The former introduces a namespace, e.g.,

 namespace({
     com:
       trifork:
         tribook: ['model','view','controller']});

ensures that object 'com' exists with a property 'trifork' which in turn has a property 'tribook', etc. The using function brings such a 'package' or 'module' object into scope. For example

 using(com.trifork.tribook.model,
       com.trifork.tribook.view).run(function(model,view){

   var meet = new model.Room('meeting 1');

 });

Now, in the last couple of months I have been working in several projects using these functions, and I feel they have really helped me structure the JavaScript code -- one project has several thousands of lines of JS code structured in files and modules mirroring the package structure (i.e., dk.ourclient. ...). In these projects, a usage pattern occurs. Many files started:

namespace('dk.ourclient.supernavigator.controller');

using(dk.ourclient.supernavigator.view,
     dk.ourclient.supernavigator.model,
     dk.ourclient.supernavigator.controller).run(function(v,m,c) {

     c.ContactController = function(spec) {
       //... m.xxx, v.yy
     };

});

I was annoyed with the WET (i.e. as opposed to DRY) repeated occurrence of 'dk.ourclient.supernavigator'. One alternative pattern would be:

namespace('dk.ourclient.supernavigator.controller');

using(dk.ourclient.supernavigator).run(function(sn) {
     var m = sn.model,
         c = sn.controller,
         v = sn.view;

     c.ContactController = function(spec) {
       //... m.xxx, v.yy
     };

});

Which is what we started using. However I was looking at an alternative way to bring sub-modules or packages into scope. I experimented with several forms; here is one of them.


You can think of the following as a small DSL for importing or using package objects in javascript (note, part of the DSL is the JavaScript with statement). It uses a form: (where 'obj' is a package object to be used)

with(f(obj)) {
   //code
}

By introducing an intermediate function 'f' and using 'f(obj)' instead of 'obj' itself, we can avoid some of the issues with 'with'.

Question: Does the following code make sense: (with an appropriate definition of the 'scope' function, this is valid working JS code!)

with (scope({ sn : dk.ourclient.supernavigator, 
              u : com.trifork.utils})) {
  
            
  with(sn) include()(model,view)
  with(u) include()(Format)
  
  run(function(mod,view,fm){
        //do stuff
  });
}

What does it do? Wait and think before you read on...

I will post an update with code that makes this work later. Hope this is good fun to you, but note that in our project we used the simpler form mentioned previously:

using(dk.ourclient.supernavigator).run(function(sn) {
     var m = sn.model,
         c = sn.controller,
         v = sn.view;

     c.ContactController = function(spec) {
       //... m.xxx, v.yy
     };

});

and I'm sure that Crockford would prefer this too ;-).

/Karl

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!

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">
  content
</name>

This is just a normal curried function so we have

Tag div ~
λclz,content.
<div class="clz">
  content
</div>

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

Tag clz:selected ~
λname,content.
<name class="selected">
  content
</name>


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>

so

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.

Extending Ext.data.Record to support inheritance for domain types

As I've previously blogged about, the JavaScript framework ExtJS provides an excellent support for developing models in Controller-Model-View architectures in web-browser client applications. One of the tools Ext provides is the function Ext.data.Record.create: using this one can easily create constructor functions for domain concepts. For example, in our room-booking application, TriBook, we defined a Reservation type concisely like this:

com.trifork.tribook.model.Reservation = Ext.data.Record.create([
       {name: 'start_at', type:'date', dateFormat:'d/m/Y-H:i'},
       {name: 'end_at', type:'date', dateFormat:'d/m/Y-H:i'},
       {name: 'room'}
]); 

That is: a Reservation object has 'start_at' and 'end_at' Date properties as well as a 'room' property (which refers to a 'Room' domain object, defined of course using Ext.data.Record.create).

One point made in a previous article is that Ext.data.Record.create returns a JavaScript constructor function for the defined domain concept. This means that we can add domain logic to our domain types by augmenting their prototypes, e.g.,

Ext.apply(com.trifork.tribook.model.Reservation.prototype, {
     isPreLunchReservation: function(){//just an example...
         var sh = this.get('start_at').getHours(),
             eh = this.get('end_at').getHours();
         return 6 <= sh && eh <= 11;//must end before noon...
     }
});

This is all very useful, particularly because Ext.data.Record objects are supported by a bunch of other Ext functions, as discussed previously.

However, there is no built-in support for inheritance in domain concepts. For example, suppose that we like to create a sub-type of our reservation domain type: a RecurringReservation, which one can use e.g., to reserve a room the same time each week. It would be nice to be able to write the following:

var m = com.trifork.tribook.model;
m.RecurringReservation = Ext.data.Record.extend(m.Reservation, [
      {name:'interval', type:'string'}//can be 'daily','weekly', 'monthly' or 'yearly'
]);
var rr = new m.RecurringReservation({
           start_at:'17/03/2008-08:00',
           end_at:'17/03/2008-09:30',
           room:room_ref,//assuming room_ref refers to a m.Room object.
           interval: 'weekly'
});

Now, the object referred to by 'rr' should have all the specified state, and all the domain logic of Reservation should be inherited, e.g., 'isPreLunchReservation' also works for RecurringReservation objects.

The following is an Ext extension that makes the above snipplet work:

Ext.data.Record.extend = function(sp,fields){
        var sb = Ext.extend(sp,{}),
            sb_f = sb.prototype.fields.clone(),
            Field = Ext.data.Field,
            i,N;

        for (i=0,N=fields.length; i<N; i++) {
                sb_f.add(new Field(fields[i]));
        }
        sb.prototype.fields = sb_f;
        return sb;
};

Client/Server Web-apps -- the model (Part I, Section II)

This article is Part I, Section II 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 next couple of articles will look at one way of using the Model-View-Controller (MVC) design pattern when structuring the client. In doing so, we will touch upon other topics: Crockford's singleton and module patterns, inheritance and the observer/observable design pattern. This article gives a highlevel view of the architecture and presents the Model-part of MVC.

Introduction.

In our webapp, the model-view-controller pattern is used in a manner close to MVC in non-web applications, e.g. Swing applications, which is quite different from the common MVC pattern for web-apps (e.g., as done in JSP Model 1 and Model 2 architectures, Rails, JSF etc.). For example, in the JSP Model2 architecture, the controller is a Servlet that receives a HTTP request, possibly manipulates the model (implemented as a collection of Java Beans), and finally dispatches to the view (implemented as a collection of JSP templates that consult model objects when rendering HTML).

Our server doesn't deliver any HTML. The server's responsibility is simply to implement a HTTP-based RESTful API for accessing resources (in fact, the server application itself is not structured by MVC, since it has no view in the traditional sense). The JavaScript client is decoupled from the server application and interacts with it only through the exchange of JSON data. Hence, our web-application is much more like a traditional distributed client/server application than a regular HTML-centric web-application. In fact, also our client application will be HTML-free! (I kind of like the name 'HTML-free' web-applications for this type of web-app). This sounds impossible, and actually it only mostly true ;-). However, using the JavaScript framework ExtJS, we are able to only use HTML for the 'lowest-level' custom functionality: all other GUI elements are composed of (JavaScript-) customized Ext Components and Containers. This let's us develop the view largely without thinking about HTML or ugly HTML-templates (of course Ext uses HTML internally).

So, it is the client that is structured by MVC. In fact, MVC can be implemented quite elegantly in JavaScript (I wonder if this is connected to the fact that MVC was originally developed for GUI applications written in Smalltalk, a language that in some ways is close to JavaScript).

We will use the singleton pattern for the controller, model and view, and so there are no constructor functions for these objects. Each of these are accessed as:

    com.trifork.tribook.controller.Controller
    com.trifork.tribook.model.Model
    com.trifork.tribook.view.View

Their responsibilities are as follows:

• Model represents the state of the application in terms of concepts from the application domain (Rooms and Reservations in our example). It is an observable object, which fires events when state changes.


• View sets up all the GUI elements. It is also an observable object. The events fired by the view are not low-level events like DOM events; instead, they are logical events which are triggered by such low-level events, e.g., clicking on a button. An example logical event could be 'room reservation'.


• Controller initializes model and view. It also listens on model and view events. For example, a controller component will be responsible for handling the logical 'room reservation' event fired by the view. Controller also manipulates the model (thus triggering more events) in response to, e.g., the result of Ajax requests.

An advantage of the event-driven programming model is that there is a loose coupling between the source of events and code that responds to such events. Furthermore, most of the time there can be several handlers for each event, and such handlers need not be aware of each other.

Recall that our example application, TriBook, is a simple room-booking application for reserving meeting rooms at Trifork. In the following we will look at the structure of the model-part of our TriBook application. We will be using the JavaScript framework ExtJS (the strongest JavaScript framework I know of) when defining the Model and associated domain concepts; also, we will use the namespace and using functions from the previous article.

The Model
The object: com.trifork.tribook.model is a so-called package object; it does not contain any logic, and serves only as a container for all objects and functions related to the model. In our TriBook application, this includes: Model (the model-object mentioned above), Room (a constructor function for the domain concept of a Room), Reservation (constructor for Reservation objects) and RoomQuery (constructor for objects representing a query for available rooms).

When defining domain constructor functions, we will use ExtJS, specifically: Ext.data.Record. This object has a method, called create, which is a higher-order function that returns a constructor function for a 'record' object, which are ideal for domain modeling for several reasons (as we shall see). This should make much more sense, when seeing the code:

namespace("com.trifork.tribook.model");
using(com.trifork.tribook.model).run(function(m){
 
    var format = 'd/m/Y-H:i';
    m.Reservation = Ext.data.Record.create([
     {name: 'start_at', type:'date', dateFormat:format},
     {name: 'end_at', type:'date', dateFormat:format},
     //belongs_to room
     {name: 'room'}//no 'type' means arbitrary object
    ]); 
});

This code defines the Reservation domain concept: a reservation has a start and end time and refers to a Room object (the room being reserved). The 'dateFormat' property tells Ext how to parse a string to a Date object.

Since Ext.data.Record.create returns a constructor function, we can add domain logic to our domain objects by augmenting their prototypes. Below, we illustrate this with the Room domain concept which has a method 'isFreeFor' that returns true iff this room is available to the input RoomQuery object:

namespace("com.trifork.tribook.model");
using(com.trifork.tribook.model).run(function(m){
   var rsvReader = new Ext.data.JsonReader({
      root: "reservations" 
   }, m.Reservation);//converts JSON objects to Reservation objects
 
   m.Room = Ext.data.Record.create([
        {name: 'name', type:'string'},
        {name: 'room_code', type:'string'},
        {name: 'description', type:'string'},
        {name: 'max_size', type:'int'},
        {name: 'picture_url', type:'string'},
        {name: 'map_url', type:'string'},
  
        //Room has_many :reservations
        {
         name: 'reservations', 
       
         //this tells Ext how to convert a JSON array to
         //an array of m.Reservation objects
         //room is a reference back to the room object itself
         convert: function(rsvs,room) {
             Ext.each(rsvs, function(r){
                 Ext.apply(r,{room:room});//adds a room property to r
             });
             return rsvReader.readRecords({'reservations':rsvs}).records;
         }
        }
     ]); 
 
   //is this room free for input room query object?
   m.Room.prototype.isFreeFor = function(query) {
         return (query.get('min_size') <= this.get('max_size')) && 
          ! this.get('reservations').some(function reserved(period) {
                      //... details omitted
             });
   };
});

I think it is noteworthy how succinctly we can define domain concepts using Ext, e.g., {name: 'name', type:'string'} declaratively specifies that rooms have a 'name' property of type 'string'. Further, using Ext.data.Record objects as our domain objects we can leverage other Ext functions in several ways: for example Ext.data.JsonReader or Ext.data.XmlReader automatically converts JSON or XML data representations of domain objects to actual domain object instances. Furthermore, the Ext.data.Store abstraction gives us a client-local cache of domain objects; something we will be using in the Model object.

The observable/observer pattern. It should come as no surprise that we are also leveraging ExtJS in our use of the observable pattern: the com.trifork.tribook.model.Model objects is an instance of the type Ext.util.Observable. This gives us the ability to add named events which can be fired and all listeners notified. For example, we have the following (note that Ext.apply(A,B) copies all the properties of object B to object A):

namespace("com.trifork.tribook.model");
using(com.trifork.tribook.model).run(function(m){
      //details omitted here...

      m.Model = (function() {//inline
          var model = new Ext.util.Observable();
          model.addEvents('beforequery','query','beforerooms','rooms');

          return Ext.apply(model, {
             init: function(conf) {
                     this.rooms.set(conf.rooms);
             },
             //attr_accessor defined below
             rooms: attr_accessor('rooms'),
             query: attr_accessor('query'),
             pendingReservations: attr_accessor({
                            name:'pendingReservations', 
                            setter: false
                        })
         });
       })();
//details omitted here...
...

Ignore 'attr_accessor' for now, it simply creates a property on the Model object (if you know rails you can probably guess what it does) - we will get back to this later. Model is an observable object with events: 'beforerooms', 'rooms', 'beforequery' and 'query'. The client application always has a current query which represents the period in time that the user is presently interested in (represented as a form in the view). The controller makes sure that the query property of the model is updated when the user changes the form values, and hence the 'query' event is fired with the updated value as a parameter. Other view components, in turn, listen on this model property and react to these changes, which removes dependencies from the view and gives a looser coupling.

Using Ext, adding an event listener can be done as follows: m.Model.on('query', function(q){...});. When the 'query' event is fired on the model, the supplied function is called, binding an optional event parameter to q. Similarly, firing an event is simple: m.Model.fireEvent('query', new m.RoomQuery(...));. When an event is fired, all listeners are invoked in turn.

The full model source is:

/*extern com, Tri, Ext*/
namespace("com.trifork.tribook.model");
using(com.trifork.tribook.model).run(function(m){
  var State = {
      rooms: null,
             query: null,
             pendingReservations: new Ext.data.Store()
  };
 
  m.Model = (function() {//inline
     var model = new Ext.util.Observable();
     model.addEvents('beforequery','query','beforerooms','rooms');

     return Ext.apply(model, {
        init: function(conf) {
          this.rooms.set(conf.rooms);
        },
       //attr_accessor defined below
       rooms: attr_accessor('rooms'),
       query: attr_accessor('query'),
       pendingReservations: attr_accessor({
                   name:'pendingReservations', 
                   setter: false
       })
     });
   })();
 
 //create an attribute accessor pair.
 function attr_accessor(spec){
  spec = typeof spec === 'string' ? {name: spec, setter:true} : spec;
  var name = spec.name, 
      before = 'before'+name,
      res = {
        get: function(){
           return State[name];
        }
      };
    if (spec.setter) {
      res.set = function(val){
            var old_val = State[name];
            if (m.Model.fireEvent(before,val,old_val) !== false){
                   State[name] = val;
                   m.Model.fireEvent(name,val,old_val);
            }
      };
    }
    return res;
 }
});

Conclusion
At the end of this writing, I somehow feel that I've not completely expressed my points as clearly as I would have liked -- this paragraph is an attempt to remedy this. Since I am unsure how to re-write this posting more concisely, I'll just try and emphasize my main messages:

• Our 'web-app' should be thought of as a regular distributed client/server app. The server uses RESTful HTTP, and is HTML free; it's primary format for resource representation is application/json. (All this is a topic of a later posting). The client is written JavaScript and is (almost) HTML free. The client is structured after MVC. Client and server constitute a HTML-free webapplication!


• The MVC design is event based; this simplifies components and reduces coupling. The view manages the GUI and converts user actions to logical application events. Controller handles application events. Model represents the state of the (client) application; it fires events when state changes.


• The package object com.trifork.tribook.model contains domain concepts (e.g. Room); it also contains the actual Model object. The state of Model is represented via the domain concepts.


• I highly recommend ExtJS in developing this type of client application. Ext is extremely useful in M, V and C; for this posting we focused on M, where the Ext features support for:
  
  
  
  • concise definition of domain concepts using Ext.data.Record
  
  
  • client caches (collections) of domain objects, asynchronously linked to a server backend, i.e., Ext.data.Store, Ext.data.HttpProxy
  
  
  • observer/observable design pattern: Ext.util.Observable
  
  
  • XML and JSON parsing and mapping to domain concepts (Ext.data.JsonReader, Ext.data.XmlReader)
  
  
  • and of course Ext itself is highly extensible and event based
  
  
  
  
  
  

JavaScript parasitic inheritance, power constructors and instanceof.

Abstract. This posting shows how one can make Crockford's power constructor functions play nicely with the JavaScript keyword 'instanceof.'

[update: March 18, 2008. I asked Crockford what he thinks about this pattern, and he actually discourages the use of 'instanceof' -- instead, he prefers to "... rely instead on good design and polymorphism."]

The inheritance model of JavaScript is based on a combination of the 'new' keyword and the prototype property of (constructor) functions. JavaScript Guru Douglas Crockford (aka 'Yoda') argues that this model (which he calls pseudo-classical) is awkward. Instead, he proposes an elegant, powerful and simple model (parasitic inheritance), using so-called power constructor functions. Note, familiarity with the above concepts is necessary for complete understanding of this post [and something that every web developer should know anyway ;-)].

The advantages of power constructor functions include support for private, shared and public variables as well as simplicty (avoiding new and prototype). There is a mismatch, however, between constructors and the JavaScript keyword, instanceof. Consider the following example:

//recall that the object function creates a new object which has
//the input object, o, as its prototype
var object = (function() {
     function F() {}
     return function(o) {
         F.prototype = o;
         return new F();
     };
})();//included for completeness.
var OriginalPerson = {
   sayHello: function(){
      return "Hello, my name is "+this.getName();
   },
   getName: function(){return 'Adam';}
};

function Person(name) {
  var p = object(OriginalPerson);
  p.getName = function() {return name;};
  return p;
}

function Guru(name,topic) {
  var g = object(Person(name));//Technically we don't need object(.) here
  g.getTopic = function() {return topic;};
  return g;
}

var karl = Person('Karl');
var crockford = Guru('Douglas','JavaScript');

karl instanceof Person;//<- false 
crockford instanceof Guru;//<- false 

Hmm... Clearly, any environment that makes crockford instanceof Guru evaluate to false must be getting something wrong!

In general, one has to do something to make super-constructors work with instanceof. The expression exp1 instanceof exp2 where exp1,exp2 are JS expressions (exp2 must evaluate to a function and exp1 should evaluate to an object) works with following semantics:

First exp1 is evaluated, say, to o then
exp2 is evaluated, say, to f. If o is an object and f is a function, the entire expression evaluates to true only if following o's [[prototype]] chain, we can reach f.prototype.

This means that to make this work, we must ensure that the object created has Person.prototype or Guru.prototype in its prototype chain.

What I would really like to end up with at the end of this blog entry, is to be able to write code similar to:

var OriginalPerson = {
   sayHello: function(){
      return "Hello, my name is "+this.getName();
   },
   getName: function(){return 'Adam';}
};

var Person = OriginalPerson.parasite(function(Host,name) {
  var p = object(Host());
  p.getName = function() {return name;};
  return p;
});

var Guru = Person.parasite(function(Host, name,topic) {
  var g = object(Host(name));
  g.getTopic = function() {return topic;};
  return g;
});

Guru('Douglas Crockford','JavaScript') instanceof Guru;//<-- true 
Guru('Douglas Crockford','JavaScript') instanceof Person;//<-- true

The extra parameter Host is supposed to represent the "Host" of the parasite (i.e., Person in the case of Guru), the idea being that the parasite function will somehow 'wrap' the Person function to set it up so that 'instanceof' works, and then finally feed this wrapped function to the parasite (via the Host variable). I won't be able to write the code exactly as above, but we will get close... Anyway, hopefully this will make more sense very soon!

We will get there in two steps. First we code it up manually (so to speak) and secondly we will do the meta-programming with parasite.

Incidentally, we can exploit Crockford's 'shared secrets' technique to get the prototype chain working. Consider the following code.

function Person(name, proto) {
  var p = object(proto || Person.prototype);
  p.getName = function() {return name;};
  return p;
}
Person.prototype = {
   sayHello: function(){
      return "Hello, my name is "+this.getName();
   },
   getName: function(){return 'Adam';}
};
Person('Karl') instanceof Person;//<-- true

The key here is the statement: object(proto || Person.prototype). This ensures that the object created has Person.prototype in its [[prototype]] chain. The proto ||-part is intended to be used as a 'shared secret' between a parasite 'sub type'/'sub power constructor'; the invariant is that proto || Person.prototype will always denote an object which is Person.prototype or has it in its prototype chain. It can be used as follows:

function Guru(name,topic,proto) {
  var g = object(Person(name, proto || Guru.prototype));
  g.getTopic = function() {return topic;};
  return g;
}
Guru.prototype = object(Person.prototype);
Guru('Douglas Crockford','JavaScript') instanceof Guru;//<-- true
Guru('Douglas Crockford','JavaScript') instanceof Person;//<-- true

Actually, I feel some pleasure in the assignments:

Person.prototype = {
   sayHello: function(){
      return "Hello, my name is "+this.getName();
   },
   getName: function(){return 'Adam';}
};

and Guru.prototype = object(Person.prototype);: Intutively, these objects are the 'prototypes' of the objects created by the power constructors, so it feels natural to make this assignment.

So far so good - we have instanceof working with power-constructors, but we can do better. The problem now is to do the meta-programming that will handle the 'secret-sharing' behind the scenes.

In this example, we will enhance Object.prototype and Function.prototype. For simplicity I've introduced the constraint that all power-constructor functions should take only one argument [however, I'm convinced this can be generalized to more than one argument].

Note, slightly off topic here...
In either case, I've developed at taste for single-argument functions. Consider:

/** power-constructer for Guru objects 
  *@param conf {Object} a configuration object with properties:
  * name and topic
  * @return a Guru object with name: conf.name and topic: conf.topic.
  */
function Guru(conf){
  var g = object(Person(conf)),
      t = conf.topic || 'none';
  g.getTopic = function(){return t;};
  return g;
}
Guru({name:'Yoda', topic:'JavaScript'});

The disadvantage is that there is slightly more code to write. The advantages are (1) readability: Guru({name:'Yoda', topic:'JavaScript'}) can be read without having to consult the constructor function about which argument is the name and which is the topic; (2) optional/default arguments: you can leave out either of the arguments: Guru({name:'Yoda'}) or Guru({topic:'JavaScript'}) are both valid (in the multiple arg constructor with name as the first parameter, you'd have to write Guru('Yoda') (which is fine), and Guru(undefined,'JavaScript') (which is not).

Back on track
The following is my implementation. I extend Object.prototype and Function.prototype so that we can write:

var OriginalPerson = {
   sayHello: function(){
      return "Hello, my name is "+this.getName();
   },
   getName: function(){return 'Adam';}
};

var Person = OriginalPerson.parasite(function(Host, conf) {
  var p = object(Host()),
      name = conf.name || 'Anonymous';
  p.getName = function() {return name;};
  return p;
});

var Guru = Person.parasite(function(Host, conf) {
  var g = object(Host(conf)),
      topic = conf.topic || 'none';
  g.getTopic = function() {return topic;}
  return g;
});
var h = Guru({
 name: 'Douglas Crockford',
 topic: 'JavaScript'
});
h instanceof Guru;//<-- true
h instanceof Person;//<-- true

I've implemented it as follows (with comments):

Object.prototype.parasite = function(parasite){
    /* This is the function returned as the result
       of this call; it represents a wrapper for the
       function in parameter parasite. wrapper will simply
       call the parasite function, but supplying a Host function
       as the first argument. If wrapper is called with proto === undefined
       then the Host function will create an object with its prototype === this,
       otherwise an object with prototype === proto is created (this lets
       sub-parasites supply the proto parameter).
    */
    function wrapper(conf,proto) {
        var p = proto;//Exercise why is this necessary?
        Array.prototype.splice.call(arguments,0,0,function(){
           return object(p || wrapper.prototype);
        });
        return parasite.apply(this, arguments);
    }
    /* it is important that wrapper.prototype is set to this object, both so that
       o instanceof wrapper works, and so that objects created with
       object(p || wrapper.prototype) above will inherit properties of this */
    wrapper.prototype = this;
    return wrapper;
};
Function.prototype.parasite = function(parasite) {
    var host_cons = this;//the constructor function for the host of parasite

    /* Again, this function is the result of the computation. 
       When called it splices a Host function on the 0'th pos in the arguments array.
       The Host function will call the host_cons and (important!) supplies an 
       additional last argument (proto). If proto === undefined we are in the case
       where client code is calling wrapper, so we call the host_cons function
       supplying wrapper.prototype; if instead proto is provided we call host_cons
       with this object (this is the case where wrapper is called by a sub-parasite).
    */
    function wrapper(conf,proto) {
         var wrapper_this = this,
             p = proto;//exercise: why?
         Array.prototype.splice.call(arguments,0,0, function() {
              Array.prototype.splice.call(arguments,arguments.length,0, 
                                              p || wrapper.prototype);
              return host_cons.apply(wrapper_this,arguments); 
         });
         return parasite.apply(this, arguments);
    }
    /* our prototype is an object which inherits properties from this.prototype,
       e.g., Guru.prototype inherits from Person.prototype.
    */
    wrapper.prototype = object(this.prototype);
    return wrapper;
};

Designing client/server web-applications

This particular entry will be the first in a series concerning some recent thoughts I've had about designing so-called 'rich' web-applications, which I will be thinking of as any distributed client/server application that have the following properties:

• client and server communicate using HTTP
  
• client is developed in JavaScript (GUI is made using CSS+HTML) and runs in an ("A-grade") browser

The series will cover a range of topics which should span all aspects of developing such an application. At present the topics are:

• Patterns for client application design using Ext JS [JavaScript namespacing, module patterns, inheritance in JavaScript, Model-View-Controller in web clients, Observer pattern]
  
• file organization, the build process and proper serving [splitting and building JavaScript programs, static checking, automated unit testing, JS 'compression', building and serving]
  
• the RESTful server [designing RESTful backends to JS clients, Ruby/Rail implementation]

Throughout the series I will be developing a mini application called TriBook. The application is for booking meeting rooms at Trifork; it is developed using the JavaScript library Ext JS and Ruby on Rails for the server.

Part I, Section (i): JavaScript namespacing.

The WHAT:

Everyone knows that variables declared at the top level are global, e.g.,

function trim(str) {
  return str.replace(/^\s+|\s+$/g, "");
}

is globally accessible using the name trim. When a page is including scripts from different sources that the page itself may not have control of, there is a chance of one script overriding the value of another's variables (the value of PI may indeed change!). Namespacing together with naming conventions significantly reduce the probability of such unintended script interactions.

The namespacing conventions I will be following attempt to mimic packages in Java. A package name is a name of the form: x.y.z... with "x" the top level name of an organization, "y" the organization's domain and then one or more subdomains or application identifiers. Package names are lowercase characters. In the example application, I will be defining JavaScript objects that "live" in the following package: com.trifork.tribook.

Now, "hold on!" you may say, continuing: "JavaScript doesn't have namespaces or packages". While the is true, we can achieve something close using just objects. Many JavaScript libraries support some sort of a namespace function. For instance, Ext JS has the Ext.namespace function. The statement

Ext.namespace('com.trifork.tribook');

ensures that there exists a global variable com which references an object that has a property 'trifork', which in turn has a property 'tribook'. So you can write

Ext.namespace('com.trifork.tribook');
com.trifork.tribook.Application = { ... };

However, while many libraries have the 'namespace' function (or something similar), none that I am aware of have any additional support for actually using namespaces in JavaScript programs. (And this should be where this post hopefully gets interesting and new).

Supposing you are structuring your application by a kind of Model-View-Controller pattern [one way to do this will be the topic of a later posting!]. Naturally you are using namespacing, and you want an application structure with model, view and controller in district packages. In our example, we will have a package structure

com.
   trifork.
           tribook.
                  model
                  view
                  controller

For example, the package com.trifork.tribook.model will contain a singleton object Model which contains the domain model of our application. We will develop our own namespace function which lets us define this layout in one statement:

namespace({
   com:{
     trifork:{
        tribook:['model',
                 'view',
                 'controller']
     }
   }
});

Our namespace function is polymorphic in the sense that one can call it with one of several input types:

namespace('com.trifork.tribook');

namespace(['com.trifork.tribook.model','com.trifork.tribook.view',
  'com.trifork.tribook.controller']);

and the form shown above. It is important to note that namespace('x.y') ensures that x.y exists: if it does not exist, it is created, and if it already exists, it is left alone (implying that namespace is idempotent).

The WHY?

We'll get back to the namespace function later. Here we continue with another function: using. This function lets us write code like:

namespace('com.trifork.tribook.model');

using(com.trifork.tribook.model).run(function(m){

    m.Room = function(room_name) {
              this.name = room_name;
              ...
    };
});

The pattern: using(exp).run(function(n){...}); applies the inner function (function(n){...}) to the result of evaluating the expression exp.

In our example above, the code defines a constructor function for the Room domain objects; this function is accessed as com.trifork.tribook.model.Room (similarly to what one would do in a Java packaged world).

Now, as we shall see in the next couple of paragraphs, there are several benefits to structuring code this way:

(i) As with all namespacing: we don't clutter the global object and we reduce probability of unintended collisions.

(ii) using can take several parameters and introduces short names for deep namespaces.

namespace('long.boring.namespace.deep.as.well.controller');
using(long.boring.namespace.deep.as.well.model,
      long.boring.namespace.deep.as.well.view).run(function(model,view) {
         
         ...
});

Not only is it easier to write model than: long.boring.namespace.deep.as.well.model; it is also more efficient.

(iii) If every JavaScript file in your filesystem organization of your application [and this will be a topic of a later posting] has the form:

namespace('xxx.yyy.zzz');

using(xxx.yyy.a,xxx.yyy.zzz).run(function(a,z){...});

Then two things are immediately clear to anyone reading the code (perhaps for the first time): (1) this file defines objects that live in xxx.yyy.zzz, and (2) the objects in this file depend on objects in the packages xxx.yyy.a and xxx.yyy.zzz. While you may not appreciate this immediately, I do believe that as JavaScript applications are getting larger and larger, we need all the help we can get in organizing the application (and I really think this benefit is useful).

(iv) private variables for free. In the statement:

namespace('x.y.controller');

using(x.y.model,x.y.view,x.y.controller).run(function(model,view,ctrl){

     function trim(str) {
          return str.replace(/^\s+|\s+$/g, "");
     }
     var PI = 3.14159;

     ctrl.Controller = {
         init: function(url) {
            model.Model.url = trim(url);

         },
         getPI: function(){return PI;}
     };

});

The function trim is private to the code defined within the function being "run". Hence the global namespace is not cluttered with functions that are intended to be used only locally. Also, no other script code can ever accidentally redefine PI, which sounds like a good thing ;-) (One may say that this structure lets one implement some of Douglas Crockfords patterns in a readable way!)


The HOW?
Ironically, when implementing namespace-using, I've decided not to use namespacing! The reason for this is that while

Trifork.namespace('x.y');

Trifork.using(x.y).run(function(y){...});

reduces probability of collision, the non-namespaced version feels much more like a language extension; in:

namespace('x.y');

using(x.y).run(function(y){...});

It almost feels as though 'namespace' and 'using' are language keywords and not user-defined functions. It is like working in an extended JavaScript language that has packages and imports -- although I would have preferred something like:

namespace x.y.z;

import x.y as y and y.z, y.w in function(y,z,w){
  ...  
}

Implementing using is almost trivial:
using(exp).run(function(v){..}) is (almost) equivalent to (function(v){..})(exp). The full implementation is:

function using() {
  var args = arguments;
  return {run:function(inner){return inner.apply(args[0],args);}};
}

(not that when running the inner function, 'this' is bound to the first argument of using).

The namespace function is more code, but relatively straightforward:

//Update: generalize array case to handle a mix of strings and objects via recursion.
//Update [June 11, 2008] Simplifications noticed by Aaron Gray, thx.

function namespace(spec,context) {
    var validIdentifier = /^(?:[a-zA-Z_]\w*[.])*[a-zA-Z_]\w*$/,
        i,N;
    context = context || window;
    spec = spec.valueOf();
    if (typeof spec === 'object') {
            if (typeof spec.length === 'number') {//assume an array-like object
                for (i=0,N=spec.length;i<N;i++) {
                    namespace(spec[i],context);
                }
            }
            else {//spec is a specification object e.g, {com: {trifork: ['model,view']}}
                for (i in spec) if (spec.hasOwnProperty(i)) {
                    context[i] = context[i] || {};
                    namespace(spec[i], context[i]);//recursively descend tree
                }
            }
    } else if (typeof spec === 'string') {
            (function handleStringCase(){
               var parts;
               if (!validIdentifier.test(spec)) {
                   throw new Error('"'+spec+'" is not a valid name for a package.');
               }
               parts = spec.split('.');
               for (i=0,N=parts.length;i<N;i++) {
                   spec = parts[i];
                   context[spec] = context[spec] || {};
                   context = context[spec];
               }
            })();
    }
    else {
       throw new TypeError();
    }
}