On Jun 2, 2005, at 8:58 PM, Phillip J. Eby wrote: > At 08:13 AM 6/3/2005 +0530, Sridhar Ratna wrote: > >> On 6/3/05, mike bayer <[EMAIL PROTECTED]> wrote: >> >>> >>> referring to this one: >>> >>> http://freespace.virgin.net/hamish.sanderson/htmltemplate.html >>> >>> it looks very cool and elegant, and clearly produces templates >>> that are >>> super-clean. however, I would wonder how convenient it really is to >>> >> >> I see that as reduced and simplified version of Nevow templates - >> http://www.nevow.com >> > > I'd say more a crippled relative than a simplified version.
From looking through it briefly this was my impression. I think I asked HAS when he created it why he didn't use Nevow, and I think the answer was mostly because he just wanted to create static HTML files (as opposed to web applications). Being the author of Nevow I didn't want to dis HTMLTemplate, but Nevow really can do much, much more. Nevow's templates are, in my opinion, even cleaner. The original goal of both Woven and Nevow templates was to remove all view logic from the template and put logic where logic belongs -- as view logic in Python. This doesn't mean that your "controller" is rendering the views, but it does mean that rather than inventing a new mini- language, Python is used to manipulate an intermediate template format (a DOM). Woven used the W3C DOM, which turned out to be cumbersome and heavyweight, so Nevow uses a custom document object model called "stan". Stan is made up of Python lists, strings, and instances of nevow.stan.Tag (Actually, the stan dom can contain any Python object as long as a flattener function is registered for the type). The view logic consists of manipulating this DOM in pure python code. You do things that you would expect -- perform tests against certain conditions and return one or another node depending on the result, loop over things copying a node and applying one piece of data to that node (that node then gets rendered by trampolining it back up to the main render loop). In practice it works out very well, with ultra-clean templates marked up in strategic places and pure Python code which is very short and easy to read. To address concerns about how convenient it is in the long run, many of the common things one might do, like looping over a list of data and applying a node to each in turn or filling template slots with the values provided in a Python dictionary, are provided as default renderers out of the box. You don't have to write any code to get them. But they are provided as normal renderers, just like you would write. There is no template language which is fixed in stone and you're screwed if it doesn't do what you need it to do. If you find that things don't work quite the way you want them to, write your own renderer. It's easily extensible by design. One non-obvious thing about this approach is that it becomes falling- off-a-log easy to render recursive structures. The frustration that lead to the approach was the experience of trying to render a recursive tree in ZPT -- what was I going to do, repeat the skin for each level of possible depth? What about infinitely deep trees? I ended up rendering that portion of the template using string concatenation in Python, and at that point all the advantages of ZPT had been lost. Nevow avoids this problem by giving the Python code the ability to manipulate the template abstractly, allowing natural expression of recursion (it's expressed as tail-recursion -- a function returns an object which will invoke the same function, with a different node). So. That's what Nevow templates are about. Donovan _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
