[TransWarp] Template parsing and XML/HTML processing design

Sun Jul 20 21:19:51 EDT 2003

At 07:53 PM 7/20/03 +0200, Jean Jordaan wrote:

>I really like my Zope Page Templates --- they recently gave me a lot of
>joy customizing Roundup ( http://roundup.sf.net ) which has no Zope
>dependency and bundles ZPT. And TALES also makes writing Zope Formulator
>forms a joy. Is PEAK templates something different entirely? What do you
>think of ZPT?

I think that ZPT still embed code in a web page, and that there's a better 
alternative.  If you've seen PSO (pso.sf.net), Twisted's Woven, or even JSP 
taglibs (though that's a bit of a stretch), you'll have a better idea of 
what PWT (peak.web.templates) looks like.  Here's an example, straight from 
the test suite:

<body>
<h1 model="foo" view="text">Title Goes Here</h1>
<ul model="bar" view="list">
     <li pattern="listItem" view="text"></li>
</ul>
</body>

'view' attributes identify the object factory used to create the tag, 
'model' attributes are a path to the data to be used, and 'pattern' 
attributes identify parameters that are supplied to the nearest containing 
'view', rather like a METAL macro slot (except that views are written in 
Python, rather than being templates, although I intend to make it possible 
to use a template as a view, too).  Views are looked up in a property 
namespace so you can configure access to arbitrary view components that 
your app (or anybody else) supplies.  Views can modify the property 
namespace for their contained tags, so that inside a view the meaning of 
view attributes can change.  For example, view="list" inside a 
view="myApp.form" might have a different meaning.

No code occurs in a PWT, because all you can reference are view names, 
model paths, and pattern names.  (And the paths are just paths, not path 
expressions.)  There's no place to put any other parameters; they have to 
be in the code that defines the views, or in configuration properties 
supplied by the skin.  The nice thing, though, is that code mostly executes 
at "compile time", with full access to its contained parse tree (and its 
parent nodes, for that matter).  Any contiguous portion of the tree that 
contains no dynamic elements is collapsed/coalesced to a single node, thus 
improving rendering speed.

Anyway, PWT is still a work in progress, as I just got them parsing and 
rendering this evening, with two simple views ("text" and "list").  It 
should be possible later to create various kinds of form view components 
and use them in a PWT.  I also look forward to creating "tab" views, 
breadcrumb views, menus, calendars, etc., and being able to use them just 
by naming them in the template.  And, skins can redefine what components 
the view names will map to, and the view components in a template have 
access to the "current" skin at compile time.  (Templates are compiled for 
each skin, even if only defined in one, so that they have compile-time 
access to all skin configuration data.)