Definition of MVC
Here is a definition, wikipedia, of what MVC is:
Model-view-controller (MVC) is both a design pattern and an architectural
pattern used in software engineering. Successful use of the pattern isolates
business logic from user interface considerations, resulting in an
where it is easier to modify either the visual appearance of the application
or the underlying business rules without affecting the other. In MVC, the
model represents the information (the data) of the application and the
business rules used to manipulate the data; the view corresponds to elements
of the user interface such as text, checkbox items, and so forth; and the
controller manages details involving the communication to the model of user
actions such as keystrokes and mouse movements.
This article will take a look at the different approaches to MVC web
application development. The approaches range from, at the one extreme end,
the definitive "thin client", and at the other extreme end, the definitive
Then, a number of frameworks and programming languages will be examined:
a comparison given of some of the best and some of the worst. Whilst,
ordinarily, such a comparison would look like a total bitch-fest, in the
context of this article it can be highlighted with abundant clarity why
it is becoming so wildly inappropriate to use certain programming languages
for Web development, and why the use of frameworks - even if written in
inappropriate programming languages - is so vitally important.
HTML as a "display" mechanism: Thin Client
Taking a traditional HTML-only approach to MVC is very very simple, and easy
to do. There are dozens if not several hundred Web frameworks that can be
- The Web Server will be responsible for interacting with the Data in
- The Web Server will be responsible for enforcing the Model's business
- The Web Server will be responsible for creating the View that will be
displayed on the Web Client.
- The Web client takes care of keystrokes and mouse movements: the Web
browser application itself is the Controller, and the "standard" web
behaviour - HTTP GET triggered by Hyperlinks, and HTTP POST on Forms -
communication mechanism between the Web client and the Web Server.
In this "Thin Client" type of MVC approach, much is taken for granted.
It is often so simple that people wishing to create quick web applications
will ignore the MVC concept entirely, and thus also ignore of some of
the basic rules of Web security and robustness. SQL Injection attacks
become commonplace; data is not translated into HTML correctly; Unicode
and UTF-8 character set incompatibilities cause massive headaches.
The more experienced Web developers utilise MVC frameworks that not only
take care of these issues but also go one step further, regarding Data
handling. Typically, the best frameworks will abstract out access to
the underlying database, providing a flexible and powerful but still
relational way to manipulate data.
Once people become familiar with the basic HTML-based MVC approach,
the default behaviour of the Web browser quickly becomes tiresome,
lacklustre and time-consuming. As the "basic" HTML approach is
at the extreme end of the "Thin Client" approach, all incorrect or
even empty data fields must involve a round-trip to the
server in order to validate the input against a Model's business rules.
Having to submit data to the server each and every time, resulting in
a new View being generated, into which any errors are inserted advising
the user on how to correct their input, is not only tiresome but also
started to come to the rescue.
Model business rules. Here are some examples which are quite commonplace:
- "this field may not be empty"
- "this field must be alpha-numeric and longer than 6 characters"
a pretty widget (instead of three listboxes which would allow 31st February
as a valid date, or a text-entry field that could result in US/Non-US
day-month ordering ambiguity)
- switch the "Submit" button on-or-off, depending on whether other
fields have been successfully filled in to some "basic" degree of
- List-boxes that are enabled, or their contents modified, depending on
whether a checkbox or a radio button is selected.
- Enabling or disabling of entire areas of the View, depending on prior
All these, and many more like it, are examples of the application of basic
Model "business" rules. The application of such simple rules at the client
end does not remove the need for duplicate-checking of the
rules on the Web Server - however, the useability of the application
is greatly enhanced due to the reduction of the time delay between users
entering data and them finding out some of the basic mistakes; and
the Web Server's load is reduced.
It's worth emphasising that an incredibly common mistake that novice
that the implementation of Model "business" rules client-side somehow
means that the same business rule validation does not need to be
executed server-side. The worst possible offence of this kind is the one
involving checking of passwords. Experienced developers may laugh at
this kind of mistake, but a search through forums showing people extolling
mechanisms are despairingly common.
Also, at no time does any developer in their right mind even
contemplate duplicating the entire set of the Model's "business" rules. The
program in (its syntax is too obtuse, despite it being incredibly powerful).
Even if it were an easy language, it would still be a nightmare to
implement a dual set of Model "business" rules - one set for execution on
the Web browser and another for execution on the server.
So, typically, a web developer will make a half-hearted attempt to
satisfy some of the more basic business rules (non-empty fields) and
communicate the required corrections to the user, or simply provide
an enhanced View that cannot allow an "invalid" data entry.
Then, on the Server-side, given that the Web browser is now responsible
for ensuring that the business rules have been enforced already, a
quick double-check can be made purely for security and data integrity
reasons, and a very sparse error message returned by the Web Server.
In this way, some of the Model "business" logic that was the sole
and exclusive domain of the Web Server now moves onto the Web "Client".
The lines are already becoming blurred...
HTML and the AJAX approach
Some of the more innovative Web developers had noticed the potential uses
for XMLHttpRequest as far back as 1996 - however it has taken the rest of
the Web development community some considerable time to catch up.
programmatic control on the Web client - additional HTTP content can
be retrieved from the Web Server.
The significance of this feature cannot be underestimated, as the
level of interaction with the Web Server is suddenly no longer limited
to when the user presses "click". in MVC controller terms, in
communication between the View (displayed in the browser) and the
Model (implemented on the Web Server) was restricted to when the user
pressed a key or pressed a button.
to activate the "submit" button - on a timer, or after certain of
the "basic" business logic rules were fulfilled. but nothing in
the Web Server can be contacted independently of the View -
behind the scenes of the current "View". By using the AJAX
approach, a whole range of new possibilities are opened up:
- Partial Views can be loaded: a Web Site can be loaded in sections;
HTML fragments downloaded independently, and assembled into the Web browser,
"iframes", without the disadvantages that iframes brings.
- User-input can be validated continuously or on-demand, without having
to submit the entire "Form". Partially-complete or completed fields can be
individually submitted, using an AJAX POST, to the Web Server, to be
validated against the Model's business rules.
- New menu options or list-box values can be loaded, dynamically,
depending on user-input in other areas of the View, using AJAX, instead of
having to load the entire set of options in one View.
All of these techniques save considerable amounts of time, and enhance
the speed of the application. The latter option mentioned above is one
which deserves further attention. Imagine a large menu tree or series
of hierarchical list-boxes, comprising some 20,000 options in total,
each option requiring 100 characters of HTML text to be displayed. It
is inconceivable that a web page of some 2 megabytes in size would be
tolerated by either the users or the Web administrators, as its generation
could take potentially minutes of Server time to create, as would
its rendering. By using AJAX to load only the tree-content that the
user is interested in, the amount of data loaded from the server is
kept to a minimum, and the response time comes up to a more acceptable
The implications for the MVC framework are, however, that suddenly, a
lot more of the Model's "business rules" fall into the AJAX-solvable
realm; also, the creation of the "View" is suddenly considerably more
complex. Suddenly, the "View" is no longer being generated as a single
chunk of Server-side-generated HTML; the "View" is "constructed" from
a multitude of HTML fragments or, in some cases, raw data.
At this point, it's worthwhile specifically going over one possibility which
AJAX opens up: that of separating the "View" mechanism from the actual
data to be displayed in that view. In the case of the AJAX-driven
menu options, list-boxes and tree-views, there are two ways in which
a programmer could implement such systems. The first is by asking the
Web Server to generate HTML fragments, which are retrieved by an AJAX
query; on receipt of the response, the new listbox, menu option or new
tree-view HTML content is substituted into the Web browser "View". The
second technique is to retrieve the data as a text file, an XML document
the Web Browser's "View" is manipulated; a new List-box created where its
options are programmatically filled in by manipulating the DOM model
of the Web browser.
Suddenly, Pandora's box has been opened, where the server is no longer
even responsible for creating the View - that now becomes partly the realm
it was conveniently possible to perform some of the Model's
begins to allow for the supposedly-convenient possibility of creating
Views in the Web Browser, as well!
Faced with this additional burden of complexity, many Web developers
quake and quail at the tasks that they are asked to consider, with the
threat of being "left behind", with the "Web 2.0 revolution" closing in.
With "all sticks and no carrot", the age-old simple MVC approach that
they were comfortable with has been turned into a minefield involving
complex multi-layered application interactions and a language that
they really don't want to get involved with is forced upon them:
Many Web MVC-based frameworks try to help the developer out of this
blurred-Model, blurred-View quagmire by providing integrated AJAX
libraries: the problem with such "help" is that the burden of writing
developer, with no obvious benefit to either, and several down-sides
Many developers try to plump for a fully-grown all-singing,
What these libraries do for such developers, as far as the MVC model
is concerned, is get them deeper into the mess, as they not only
introduce a monstrous additional dependency with which they will never
fully become familiar or confident with, should it go horribly wrong
or not be up to the task (thus forcing the Business to adapt to the
technology - the absolute Cardinal Sin of I.T. development), but also
the split between the programming language used by the Web Server, and
that of the Web Client deepens yet further. On top of that,
such as extjs, adds an intolerably-high load-time to each and every
single page on which a particular widget is utilised.
As a result, it's no wonder then that many developers abandon AJAX
and "traditional" web development, and go for Adobe Flash and Silverlight,
both of which are proprietary and have significant disadvantages,
or they go for a Java browser plugin, which is just as dodgy.
The options, therefore, are pretty limited... or are they?
the idea of handing complete responsibility for "View" generation and
near-complete responsibility for Model "business rules" validation to
the Web Browser would make perfect sense.
Here's what the ideal scenario would be:
- The Web Server would be responsible for interacting with the Data in
the Model, and providing the data on-demand via AJAX.
- The Web Server would be responsible for enforcing the Model's
rules at a basic level, doing security checks, double-checking data
submission integrity checks, and providing sparse error messages. The Web
Server's job does not have to involve generation of or
the "View", but it does at least have to communicate the error messages to
- The Web Client would be responsible for enforcing the Model's
business rules, where literally all of the business rules are written in and
security checks will be performed server-side).
- The Web Client would be (mostly) responsible for creating the
View that will be displayed on the Web Client, to the user, which will
include the display of user-friendly error messages and advice, should the
Model's business rules be broken.
- The Web Client would still the Controller - albeit a much
enhanced and augmented one, as a full level of user-interaction, thanks to
would now be possible.
In other words, not only is the MVC roles of the Web Server and the Web
Client almost totally reversed, but also, the Web Client itself is beginning
to sound far more like a full-blown Desktop Application than a
Google Web Toolkit and
Pyjamas come into play.
These two fully-functioning development frameworks are, in the light of
the present AJAX mess, absolute god-sends. They allow the developer
to program in Java or Python, respectively - where the Java can even be
developed using the standard "Eclipse" interface - and then "compile" their
Nearly 100% of the language features of each of the respective source
languages, Java and Python, are available to each of the development
environments (Pyjamas at present cannot compile Exceptions, for example).
GWT is impressive for its size and its userbase; Pyjamas is impressive for
how little code is needed to do the same job. A ten times
reduction in code provides almost exactly the same features as
GWT: 8,000 lines of python instead of well over 80,000 for the GWT
user-interface library, alone.
The one thing that developers who have never heard of GWT or Pyjamas
cannot quite get their heads round is the fact that the Java
code or the Python code is NOT running natively in the web browser:
that's only possible with technology such as
PyXPComExt with the PyDOM
extension added as well.
Pyjamas and GWT are COMPILERS. The output from these
Included with each of the two toolkits is a respective library suitable
for manipulating the DOM model of a Web Browser, and, then, on top of
those is an additional library that provides a Widget Set that
is incredibly similar to a Desktop Widget set. Thanks to these widget
sets, the traditional HTML-only Web browser, which was very much
a "Thin Client" affair, is fast becoming a proper "Applications
albeit one which has restricted Internet access (XMLHTTPRequest
is the only gateway to the rest of the world).
So how do GWT and Pyjamas interact with Web Servers? The answer is:
ordinary HTML+Ajax application - by using HTTP Get, HTTP Post, or AJAX.
The fact that the developer can coincidentally write their application in
the same language as the one they are writing the back-end Web
Server in lifts a massive burden from their shoulders. The fact
that they can write the front-end code in Python or Java does not
force them to write the back-end Web Server in Python or Java:
it's just a nice convenience.
However, the tantalising possibility now exists to have both the client-side
source code and the server-side source code in a single file. Even a
simple perl or awk script, and a syntax similar to or simpler than
that of yacc or boost would suffice, and make the development process
that much easier to get back to the MVC roots.
Here is the "ideal" world scenario, which does actually exist, in the form
of a very simple but currently proprietary project called "Unity":
- A developer writes front-end "View" code in classes and modules,
in python code, in specially-marked sections.
- The Model "business logic" rules are also written in python, in
separate classes and functions, again in specially-marked sections.
- Functions whose purpose is to submit data, after it has been
by Model "business logic" rules, are similarly marked.
- The Model "data-driven" code are separated out into classes and
functions, in specially-marked sections of the same source code file.
- a "compiler" pre-analyses the source code file, looking for the
- "Views" and "Model Business Logic" are split out into one file,
execution in the Web Browser). The "data submission" functions are turned
- "Model data-driven" code is separated out into another file, and
stub templates are added which turn the data functions into a
fully-operational cherrypy JSONRPC-enabled Web Server application.
- On execution in the user's Web browser, the application performs
AJAX-based JSONRPC client calls to the cherrypy Web Server to load the
application "Model Data" into the "View".
Several steps in this process have been missed out, but it should be
abundantly clear that the traditional "MVC" is back with a vengeance:
the blurred lines between which bits of code are responsible for
"Model business logic" validation are gone, and the blurred lines
regarding which bits of code are responsible for generation of the
"View" are also gone - but not completely. It's up to the developer
to decide how far they want to deviate from the traditional 'HTML'
style of display / information rendering. Not everybody is comfortable
such as mochikit, extjs or prototype), and fortunately, both the GWT and
the Pyjamas frameworks do an extremely good job of supporting and
interacting with straight HTML (investigate the HTMLPanel widget, for
example, for details).
All in all, as the Unity Project shows, writing in a single programming
language is a far saner approach to Web programming than the present
half-way-house double-languaged nightmare that is so prevalent at the
Finally, against this background, it's worthwhile re-emphasising just how
piss-poor some web development languages and approaches are, compared to
the Unity Project's approach.
php is the "language of choice" for the majority of web development,
and it can be described as "The Visual Basic of Free Software" for very
good reasons. Visual Basic gets a poor rap, because it is so easy to
write bad code with. It takes years to become properly familiar
with and proficient in Visual Basic, and php is no different. By the
time a developer is familiar with php's rich and wonderful methods for
self-mutilation, their lives have become so degraded that they wish they
had never become programmers.
php was developed at a time when there really weren't any frameworks:
the choices for Web development were drastically limited. Python
was still unheard-of; Perl was about the only major programming language,
other than ASP, that could remotely be contemplated; CGI-bin programming
was the "norm".
php provided the incredible and exciting feature of being able to embed
a scripting language into the HTML source code - HTML being considered
to be an actual programming language, when in fact it is a markup mechanism.
In MVC terms, and, very importantly, in the traditional HTML-only
well known, php was a welcome breath of fresh air.
However, php was developed with very little foresight for the potential
for abuse; its syntax is arcane; the fact that it can be mixed in with
HTML quickly became abused - badly. Unfortunately in particular, the
fact that the PHP code could be embedded into HTML led non-programmers to
believe that it was easy to program a comprehensive web site.
Thus, unskilled and untrained people started to develop web sites with
blatant disregard for the complexities and subtleties of web development,
which had led more experienced programmers to come up with things like
As the number of php programmers has increased, so has the amount of bad
and the "legacy" of the poor design of php has burdened the designers of
the php language with some quite serious problems. The most notable of
these is the fact that many php programmers are blissfully unaware of the
importance of transforming data into the proper HTML text. So, the data,
as extracted from a database, could be in Unicode or ISO-8859-1, and the
browser is configured to display UTF-8 - but worse than that, the data
could contain a "&" character, which should be displayed as "&",
or a double-quote which should be turned into """ in order to
stop the HTML page from being corrupted.
In order to avoid this particular problem, php invented the concept
of automatic quoting - Magic Strings - which are applied NOT ONLY
to HTTP Post, HTTP Get and also in Cookie-generation, BUT ALSO
there is an automatic quoting system that can be applied to Database data
entry, as well, to deal with the equally bad situation where data entered
into the Web browser - the View - could pass all of the Model "business
logic" rules, but still contain valid SQL syntax, such as "terminate
current SQL statement and begin a new one, please". Thus you get SQL
injection attacks, and entire Web Servers are compromised.
The insanity of these piss-poor hacks - as a built-in feature of a major
programming language that runs a significant chunk of the Web Services
on the internet - should be abundantly clear.
Unfortunately, writing good code - writing a good framework - in php is
simply not practical. The structure, look and feel of the language, and
the means to be "mixed in" to HTML, and that's not a good sign.
When you take away the means for foot-shooting, by not taking
advantage of this "feature" of php (mixing), and you follow the much
more sensible MVC-driven approach of separating out the programming code
for the Model (php) from the View (HTML), then what you are left with is
a programming language that looks extremely poor by comparison to the
alternatives in which proper MVC-driven Web programming can be properly
So, if there is no choice but to use php, at the very least it is
imperative that a framework is chosen that at least takes care of many
of the mistakes that the novice programmer encounters. Given a choice,
however, avoid php entirely.
The Django Project are both
examples of extremely sophisticated MVC-led frameworks. Both of them
take care of the usual tricks that trip up the novice programmer: both
of them have SQL abstraction layers, through which SQL injection attacks
are not possible; both of them take care to inform the developer that
HTML is automatically escape-sequenced, and how to switch that off if
desired; both of them take care in the conversion of data between different
Web2Py even has some integrated AJAX libraries that the developer
can take advantage of, as does Django, to some extent.
Neither of the frameworks has the kind of functionality that the
Unity framework offers - yet, Unity is a completely different beast
from Web2Py and Django: it goes that little bit "further" in a way in
which Web2Py, Django, and other python web frameworks cannot do, on their
own, without the Pyjamas compiler Technology. Unity is under one
thousand lines of code, and has more in common with flex or yacc and
with automake than it does with a "Web Framework".
Unity could be adapted so that, alongside CherryPy, the Server-side
output could be made Web-Server-Framework-agnostic, through the
addition of extra stub code, and thus could be used to auto-generate
Django Framework Server-side code, Web2Py server-side code and much more.
The tantalising possibility also exists for Web2py to integrate the
features of the Unity Framework - to use the complete Pyjamas
compiler. In this way, Web2Py's web Interface could
for execution on the Web browser, instead of having hard-coded,
hand-crafted and extremely limited AJAX libraries to rely on.
... and there's nothing to stop other frameworks from following web2py's
lead... [web2py is unique amongst python web frameworks, in that
the source code of the framework - and the developer's applications -
can all be managed and edited through the web interface
that is provided by the framework itself! Whilst many SCHEME
development environments have had this kind of self-developing
feature for decades, web2py is perhaps the first to bring it
prominently to python and to the web]
Interesting related side-note
There are some startling implications of the Unity approach; the
Pyjamas + web2py combination; the fact that the application can be
programmed in a single language, and the fact that Web browsers
look similar - enough to be made similar - to Desktop
First it's worth emphasising that the Pyjamas API is so similar to
PyGtk2 and PyQt4 that a sister-project,
Pyjamas-Desktop actually makes
the Pyjamas API a Desktop-based Widget set. The underlying
technology that makes this possible is
Webkit, but an extensive search
for comparable Gecko / XUL technology eventually turned up with
could also be used. The importance of mentioning Pyjamas-Desktop will
be come clear, momentarily.
If web2py (or other suitable MVC-based framework) were to be enhanced
so that sections of Python code could be marked or identified as
"View" code, then those sections could be handed to Pyjamas, compiled,
and executed client-side on the user's web browser. Alternatively,
the same code could be executed server-side, as is presently
done, and the application would feel no different - to the user.
Not only that, but the Model "business rules", written in Python,
browser, but also the same code could be executed server-side!
But the most interesting possibility of all is that of combining
web2py with Pyjamas-Desktop. In this scenario, web2py farms out the
directly into Pyjamas-Desktop. The glue logic between that code and
the "Model" code would result in the code that ordinarily would be
executed on the Web Server being executed by the user's desktop
machine. Or result in an AJAX call to a Server, resulting in the
same code being executed server-side, depending on either
user preferences or on an application-dependent decision.
It's almost bewildering, idyllic, "Holy Grail" but very real, and
Old-school MVC-driven Web programming started off as being relatively easy,
as long as a decent framework was used that helped the developer to avoid
some of the inane gotchas, such as SQL statement escape-sequencing on
data entry into the Model, and HTML entity transformation and character
set compatibility on data display in the View.
However, as the limitations of the default "Controller" behaviour of
complicated the picture, blurring the lines of responsibility for "View"
creation and Model "business rules" enforcement. Languages and frameworks
that have been designed with (or in some cases without) Old-school MVC
approaches in mind are being left far behind. Some developers
abandon HTML entirely and develop Java plugins, Flash and, more recently,
AJAX has improved user-responsiveness, but, overall, AJAX has just made the
situation worse, not better, despite the promises and the possibilities,
implement the "View" and the "Business rules" has increased but not
fully taken over from the Web Server, and
so the developer is forced to create multi-layered hybrids, where Views
and Model "business rules" are fractured not only across multiple
programming languages but also across multiple components: the worst-case
nightmare for any developer wishing to stick to MVC principles.
Technology such as GWT and Pyjamas (and more specifically Unity) that allows
both the Web Server and the Web Client to be
programmed in exactly the same language - can the MVC approach be properly
implemented and the user's expectations be satisfied, and thus
both the developers' and the user's lives made easier. Gmail is
can be achieved successfully.