[Zope3-dev] Inline code

[Shane Hathaway]

On Tue, 10 Feb 2004, Casey Duncan wrote:

> I find ZPT has a "sweet spot" that you have to be careful to stay in. If
> you can tilt the world correctly it usually just plunks in. It takes
> some zen to get the tilt right, though, and sometimes you can't.

I know what you're saying.  The first revision of the "page design" idea
had templates with more dynamic code than static XML.  I did everything I
could to move computation into Python scripts, but the problem space was
simply too complex to allow the templates to be readable.

Eventually, I the logic into CSS and Javascript.  This strategy made the
subsystem far easier to maintain and expand.  CompositePage now uses CSS 
for basic transformation and Javascript for deeper transformation.  I 
essentially used your strategy of transforming the page after rendering.

I tend to believe that this level of complexity is rare, though.  Most
people just want to write a guest book, web log, or shopping cart.  For
them, a little block of code in a template makes them happy quickly.

> The three main places it breaks down for me is:
> 
> - Trying to read templates with huge define blocks, python expressions
> and <tal:block> tags (which are never written by moi, heavens no ;^).
> Regardless of whether they are "right" or not, ZPT makes it easy to do
> it so people do.

Perhaps we should look at the ways that people use tal:block and suggest
alternatives.  I know I've used tal:block to iterative over row groups in
tables, but it turns out I could have used "tbody" just as effectively
instead.

> - Modularizing things for maintainability or reuse though macros. This
> quickly defeats many of its benefits and makes it hard to follow.
> Especially where macros are parameterized or variable. Sometimes I feel
> like I'm programming in BASIC (x = 1: y = 2: gosub 10250)

Parameterized macros are known to be a problem.  Ken and I have discussed
a replacement.

> - Highly dynamic pages where the structure varies on multiple axis.
> These quickly turn to mush in ZPT. The worst example I ever contrived
> was an XML template where some element names were dynamic. It was
> clearly outside of the range intented for ZPT and it smelled real bad.
> Most are much less evil then that, but still mushy.

Another time I reached this point is when I made it possible to not only
sort a table by different columns, but to also select which columns to
display.  The ZPT became an incredible mess.  In this case, I solved the
problem by representing the presentation of the table as an object.  I
still used ZPT, but the work it had to do was simple.  It even renders
more quickly.

But the more common case is a template with just one or two spots of ugly 
logic.  We need a better way to refactor those parts.  Unfortunately, 
since I realized my suggestion has a namespace problem, I don't have a 
solution.

Shane