A Future Web Development Framework – Template View

Path: mv.asterisco.pt!mvalente
From: mvale…@ruido-visual.pt (Mario Valente)
Newsgroups: mv
Subject: A Future Web Development Framework – Template View
Date: Wed, 13 Feb 07 18:43:21 GMT

I should start this post (hopefully the last detail before
going into a synthesis post) by remembering some words from
my initial post in this series:

“Meanwhile, lots of stuff has come up: Django, Pylons,
TurboGears, Ruby on Rails, you name it… I dont want to
go over extensively why I dont like any of them, but let
me just state this: if the “framework” allows for the
mixing of layout/design/HTML with code/programming, for
me is enough of a disqualifier.”

The problem, as I stated before, is that current frameworks
stuff a lot of power into the templating languague. And that
is not only unnecessary but its a bad, bad thing.

If you dont understand why 1) embedding Python/PHP/Ruby/etc
in HTML is bad or 2) outputting HTML from Python/PHP/Ruby/etc
is worse, I’m not even going to try and explain. Not only
because that means you are clueless but also because someone
else has done it better that me:


Now the problem is that although I agree with this paper and
the rules set forth in it, I disagree with the implementation.
Allowing for “$var” statements in the templates is still, in
my view, some form of entanglement and breakup of the MVC pattern.

What would be the best way to do it? Well look no further than
some already existent template engines:




They allow for the insertion of values (data binding) through
the use of HTML element attributes. Both HTMLTemplate and Meld3
create new attributes (“node” and “meld:id” respectively) but
PyMeld does it better: it simply uses the “id” attribute to do
value replacement. This is, in my opinion, the best way to do
a templating system. And there’s no need to make it “powerful”
through the introduction of loop control and other stuff like
Genshi or Zope Page Templates.

Does this mean that I have found my perfect templating engine?
No. You see, these are serverside templating engines and the
template/view should be implemented at the client level, if you
want to adhere to the MVC pattern.

What I would like is something like these templating engines:

Ajax Pages

Javascript Templates

Trimpath Junction Javascript Templates

Unfortunately all of these engines make the usual mistake of
introducing new syntax to HTML (the “$var” problem or variants
thereof instead of relying on the existing HTML markup, namely
the “id” element markup.

To sum it up, what I would rely like is a Javascript implementation
of Meld.

Aditional templating functionalities that might not be provided
through the use of the “id” attribute (although I think that it
would be all that is needed) could be added through the use of
aditional semantic potential to existing HTML markup with Javascript.
See for example Inc, for JS code include (although I would prefer
for this to be done through the implementation of the “src=” attribute
for DIVs.


— MV

Comments are closed.