PSP, Cheetah, PTL, ZOPE, etc ...

Paul Boddie paul at boddie.net
Mon Aug 6 05:35:01 EDT 2001


Andrew Kuchling <akuchlin at mems-exchange.org> wrote in message news:<3dd76bk8ik.fsf at ute.cnri.reston.va.us>...
> 
> The assumption I'm talking about isn't that the output is assumed to
> be HTML or text, but that templates are assumed to be mostly plain
> HTML with only occasional escapes into program code or variable
> expansions.  That assumption may have once been true, and still is if
> all you're doing is inserting the current date or picking a random
> quotation; one <!--#thingy--> and you're done, but for most modern,
> heavily dynamic Web sites I expect the density of program code is much
> higher.

It depends on your architecture, I suppose. Whilst it's possible that
the user interface of your application might employ a fair amount of
code to access and manipulate different generic components (eg.
business/application objects), and that code might be incorporated
into resources residing in your templates, I think there are
advantages in having another layer to do all this, with the templates
doing a very simple "translation" of the components in that new layer
to the "display".

My reasoning is that, especially when considering many different types
of user interface, there are likely to be activities and components
which support user interfaces in general. Once you're resigned to
dedicating a layer for these activities and components, what else is
left for the template system to do?

> > But doesn't this help to obscure the form of the final document? I was
> > once an advocate of building pages up from well-defined, "trusted"
> > components which represent a particular concept, but there are some
> > situations where logical components of a document don't just fit into
> > a self-contained part of a document; for example, attributes of
> > objects that one is trying to represent may be mixed together into
> > adjacent cells in an HTML table.
> 
> I'm not clear on what you mean; can you give a clearer example?
> Surely the code to generate the entire table can be rolled up into a
> single function, which answers much the same purpose.

Well, in the PTL architecture, I presume you can treat groups of
objects differently to individual objects. For example, in a
collection of order lines (the classic example), where each line
contains a product, some details, and perhaps a delivery address, you
would want to create a specific representation of the order line which
mixes together attributes from the components inside it, rather than
rely on whatever representations you might previously have chosen for
those components.

So, a product may have its own inate representation such as:

<p>Product code: <strong>product code</strong> (product
description)</p>

And a delivery address may have its own representation as:

<p>Address: first lines<br>Town: town<br>Postcode: postcode</p>

But in an order line, you would want to mix them in a previously
unforeseen way:

<tr>
  <td>product code</td>
  <td>product description</td>
  <td>first lines<br>town<br>postcode</td>
</tr>

In an over-simplistic, self-contained, "this object gets put here in
the document" system, you wouldn't be able to change the "context of
representation" so easily. Am I still making sense at this point? ;-)

> Incidentally, it strikes me that Quixote might be easier to use with
> Jython than Zope is.  The hardest part would be translating the PTL
> template generator because that uses the compiler module to generate
> Python bytecodes; perhaps it could be changed to generate straight
> Python output which could then be run through Jython's compiler.  I
> see no way to give that acceptable performance, though.

I'm also not entirely convinced by the preprocessing phase of certain
template systems. Although a well-managed development environment can
always provide the means for templates to get rebuilt when they
change, it seems like another thing to remember and another thing to
go wrong when you least expect. ;-)

For me, a good template system should support operation anywhere (not
just in some strange application server environment) so that I can
always test my templates in advance, but I'm not convinced that it
should require preprocessing. But then, I'm clearly not into the kind
of templates that would benefit so much from preprocessing...

Paul



More information about the Python-list mailing list