[ZPT] Today's ZPT proposals

[Evan Simpson]

It's time to think about the next step in the evolution of ZPTs.  Now 
that they have been in use for a year or so, a number of shortcomings 
have become clear, and I have a pair of proposals to address these.

The first issue is the fact that quite a bit of the dynamicism in many 
ZPTs is actually meta-templating.  For example, you may want to build a 
navigation bar/menu from your site's structure automatically, and TAL 
allows you to do this, but you hardly want to build it *all the time*. 
You really only want to rebuild it when a major feature of your site 
changes, and would probably be content to have it remain unchanged 
unless you manually kicked it.

Meta-programming is bad for the brain, and breaking your templates into 
chunks just so that you can cache them is a pain.  To address this, I 
propose the Simple Programmatic Rendering and Expansion (SPRAE) 
extension.  This would allow you to mark sections of a template that you 
want executed at compile time.

Next is the problem of hidden code.  While XML folks and many coders are 
comfortable wading through source text in order to see dynamic 
statements, TAL is *too* successful in getting out of the way in WYSWIG 
editors.  A designer is often unable to tell which parts of a template 
have TAL attached to them, what is dummy/example text and what isn't, 
and what scope variables have been defined in.

If we could attach TAL to visible, obviously TAL-related text in a page, 
then designers could operate on templates with more confidence.  This 
can be accomplished to an extent by using "<tal:block>"-style 
constructs, but not all WYSIWYG packages can handle this format.  I 
suggest that we add the ability to place "drops" of markup that will 
appear plainly in the text and anchor the presentation markup -- what I 
call the Simple Presentation-in-Text Template Language (SPiTTL).  Each 
drop consists of a pair of character entities ("&drop;") surrounding one 
or more HTML comments.  Each comment can contain any number of TAL 
pseudo-attributes.  In these comments, order matters, and multiple 
instances of the same TAL statement are allowed!  The leading entity may 
optionally be followed by a tag name.  If no such tag name is provided, 
the TAL code is applied to the first HTML tag that follows the drop, 
otherwise it is applied to the closest containing tag of the named type. 
  Example:

<table>
   <tr>
     <td>&drop;tr<!-- define="rows here/getRows"
repeat="row rows" -->&drop;
&drop;td<!-- content="row/name" -->&drop;
     </td>
   </tr>
</table>

Between them, these proposals will bring ZPT development to an end. 
Believe me, once you SPRAE drops of SPiTTL over all of your templates, 
neither you nor your co-workers will ever want to touch them again.

Cheers,

Evan @ 4-am