[ZPT] Today's ZPT proposals
Tue, 01 Apr 2003 15:39:13 -0600
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.
<td>&drop;tr<!-- define="rows here/getRows"
repeat="row rows" -->&drop;
&drop;td<!-- content="row/name" -->&drop;
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.
Evan @ 4-am