From: mvale…@ruido-visual.pt (Mario Valente)
Subject: A Future Web Development Framework – UI Controller
Date: Sat, 03 Nov 07 21:03:21 GMT
There is even less to say about the controller part of
the framework. We dont even have to deal with religious
and nothing else. Anyone thinking “what about Java” or “what
about Flash” (and current iterarions, Air, JavaFX, etc) will
have to explain what is the justification to have a VM/interpreter
available (the browser) and to start yet another VM/interpreter
(JRE or Flash plugin).
Nonetheless there are a couple of points that should be made.
A future web framework would have to guarantee that the controller
particular inline code)
The right way to do it would be to make declarative the use of
the UI behaviour the same way that, using CSS, we did away with
An obvious candidate would be, of course, Behaviour
But there are other options. One is event:Selectors
(although its based on Prototype.js and much prefer JQuery.js)
it (ie. not having to depend on the browser implementing the
Here though we start getting into a lot more than the UI
behaviour, namely we start getting into template/view stuff
and I want to deal with this in a separate post.
Its not always easy to define where the UI/controller part
is different from the UI/view/template part. I have a button
that takes 2 fields and computes some function. Should that
be done in the controller or in the template? I have a button
on a menu that takes me to another application screen. Where
should that be done, in the controller or in the template?
(just for the record, the first one is template level since
it has to do with data processing, data binding and business
logic, and the second one is controller level since it has to
do with application flow)
But it is difficult to define and decide and it is one of the
major problems with current web frameworks since it leads to
spaghetti code mixing controller stuff and model stuff. A new
web framework should be able to stop or minimize this problem.