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:
  http://www.stringtemplate.org/about.html
  http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
  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:
  PyMeld
  http://entrian.com/PyMeld/
  HTMLTemplate
  http://freespace.virgin.net/hamish.sanderson/htmltemplate.html
  Meld3
  http://www.plope.com/software/meld3
  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
  http://ajax-pages.sourceforge.net/
  Javascript Templates
  http://www.fishwasher.com/jst/
  Trimpath Junction Javascript Templates
  http://code.google.com/p/trimpath/
  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.
  http://johannburkard.de/blog/programming/javascript/inc-a-super-tiny-client-side-include-javascript-jquery-plugin.html
  — MV