You're using IE. Scroll down.

Delta Template Framework

The Delta Templating Framework is a Javascript templating engine for web pages. It uses the excellent jQuery toolkit. It has a homepage here.

/tech | edited on 2008/12/29 -- permalink, click to comment

Week in Review 52W2008

  • The Economist has posted a per capita computer ownership country breakdown and Portugal is tied with Mongolia for 44th place. Brasil is in 38th, Finland in 20th with one computer for each two fins and Israel is number 1 with a stunning 122% penetration. Coincidentally, Israel’s cell phone penetration is a bit over 120% too so my theory israelis are born with a cell and a laptop.

  • Palm probably does have something to show off at CES as it managed to secure another $100M from Elevation Partners. I still think it’s going to be too little too late but oh well.

  • Those wacky science guys at UtahU are riping off sea worms (urgh) and synthesizing their bioglue to hopefully make bone mending super glue. As opposed of pins and such metal work the glue will (hopefully) be used on shattered bones and joint injuries. With some luck, it will be commonly available when I shatter my hip some 40 years from now!

/wir | edited on 2008/12/29 -- permalink, click to comment

Beyond the MVC

Model-View-Controller (MVC) has become the dominant pattern in user interfacing applications. It’s Object Oriented, fits nearly 100% of business related applications and provides a fair and clear separation between the program functional blocks.

The Model is the application’s idea of the data to be manipulated and is in charge of interfacing with the data stores and manipulating the data so that it is presentable to the user. The View is the module in charge of all the display functions, it pulls data from the Model and feeds user action back into the Controller. The Controller in turn takes the user actions, verifies the business logic and manipulates the Model accordingly.
The MVC pattern neatly circles from Model to View, View to Controller and from Controller back to Model. This makes the contracts between modules fairly simple and the application flow predictable. In the wild things are seldom so clean cut and one finds shortcuts and shortcircuits that don’t belong to the pattern but work around implementation issues that stem from problems in the application architecture.

One of the great strengths of MVC is allowing for a user driven design. The View is sketched up independently and can be prototyped and tested on the user without the rest of the application being there. The Model is then designed for the View’s needs. Meanwhile the Controller can start to implement the hard business logic and then the UI interaction logic.

The MVC pattern was successfully applied to Web based applications and can be found on the popular frameworks like RubyOnRails and Django. But when we start to move into “Web2.0” type applications MVC starts to present some challenges.
On classic style Web1.0 applications the View creates the displays in HTML and the browser as a display canvas not unlike a Postscript or PDF display. The user input is then summarised and reported back to the Controller as POST. This creates a POST/Render cycle pattern with lots of network imposed delay between steps. On the Web2.0 platform we want more interactivity and less delay between operations. To achieve this we moved part of the application into the browser as Javascript code running in the browser VM. This means we introduced contexts into our application, part runs on the client context (the browser VM) and part runs on the server context, the classic context for web based applications. There’s also a third context, the database context. This context consists of the database views and stored procedures running on the database and while extensively used in business applications it’s not very explored on the common web application.

So, reviewing the contexts, we have the database context with very high bandwidth to the data and poor latency to the user. We have the server context which usually sits very near the database and far from the user and finally we have the client (or browser) context which is very close to the user but has latency and limited bandwidth to the server and database contexts. The client context is also totally untrusted while the server and database context are trusted. This is a large departure from the traditional MVC pattern where there were no untrusted contexts.

Having defined the contexts for our new Web2.0 pattern we must now define the program roles to run in them. We can start by trying to map MVC into our contexts.
The Model traditionally resides partially in the database context as database views. With relational databases such as MySQL or Oracle there will be another part of the Model in the server context handling the SQL interface.
We want interactivity so the View should reside completely in client context. That’s commonly not the case though, as a part of the View goes into the server context to serialise the database results into HTML or run sensitive parts of View code we don’t want to trust to the client context.
Finally, the Controller will be in client context for the sake of interactivity. But again, the client context is untrusted so the business logic part of the Controller and the Model update interface must run in server context and for speed some parts of it will even run in database context.

This is definitely not a winning pattern. It’s confusing and breaking out of the single context of old makes it much harder to keep OO straightforwardness. There must be a better way.

First thing we’ll do is throw away OO. I’ve lost half the audience at this point, the rest bear with me please. Instead of Objects we’ll focus on functions. What functions must the program do and in what context do they work best ?

The most obvious function is the datastore. At some point the program must load data from the past and save data for the future. And the obvious context for the datastore function is the database. And to make the datastore function simple we need to do away with the bit of the Model that (de)serialise data into/from SQL. Luckily, there’s a new generation of databases designed specifically for the Web that do away with SQL altogether (and relations in the process) and present a RESTfull JSON interface.

Another obvious function is interacting with the user. We have to show data to the user and get their feedback and hopefully in the process make the user happy. This is what I call the display function and it lives naturally in the client context. Keeping the display function in the context closest to the user ensures the best interactivity but on the other hand the client context is untrusted so there’s a number of interesting and useful operations we can’t do in the client context.

We’re left with the things we haven’t done so far. That’s the things we do in server context, the things that involve input validation and secrets. I’ll call this the policy function.

So, reviewing the functions, we have the datastore function which is roughly overlaped with the Model Object. The display function covers the View and a part of the Controller and finally the policy function covers the rest of the Controller and may do some Model things.

(end of part 1. stay tuned)

/tech | edited on 2008/12/24 -- permalink, click to comment

Week in Review 51W2008

/wir | edited on 2008/12/22 -- permalink, click to comment

Week in Review 50W2008

/wir | edited on 2008/12/15 -- permalink, click to comment

Week In Review 49W2008

/wir | edited on 2008/12/09 -- permalink, click to comment

The Week in Review 48W2008

/wir | edited on 2008/12/01 -- permalink, click to comment
blog comments powered by Disqus