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

[Paul Boddie]

Andrew Kuchling <akuchlin at mems-exchange.org> wrote in message news:<3dofpzk3vq.fsf at ute.cnri.reston.va.us>...
> ChuckEsterbrook at yahoo.com (Chuck Esterbrook) writes:
> > The *ML camp uses XML or XML-like tags for all instructions and
> > substitutions. These include ZPT, Ehydra and others. There is a *ML
> > like kit for Webware, but I don't think any serious time was put into
> > it, hence it is hard to recommend (for Webware).

You might be referring to my package, which I would like to develop
further if I only had the time. I get the feeling that it's too
different from what people expect in a template system, though.

> I've become quite fond of PTL's Python-based syntax.  Here's an
> explanation of why (quoting from a not-yet-public article):
> 
>         This syntax is quite different from most HTML templating
>         languages, which usually look like HTML with magical
>         delimiters (e.g. <%...%>, <?...?>, <!--#... -->) sprinkled

Horrible, isn't it? ;-)

>         throughout. After we'd been using the Python-inspired PTL
>         syntax for a while and found we quite liked it, Neil
>         Schemenauer came up with an explanation for why it works so
>         well. Most templating languages assume the content is mostly
>         HTML with just a few small bits of program code here and

I would say that most "small" template languages are like that, but
DTML, JSP and ASP surely support almost any kind of textual document.
Only supporting HTML in a template system is far too limiting in my
view. Enhydra's XMLC seems to be constrained in certain additional
undesirable ways, such as having the need to generate template
"handlers" in advance.

[...]

>         Without its authors ever realizing this while designing it,
>         PTL turns the idea of HTML templating on its head: the default
>         is program code, and there's an escape sequence into HTML,
>         namely Python's notation for string literals, which is compact
>         and easily readable. Functions that actually contain HTML
>         therefore can look a little messy, but that's only in the
>         lowest-level functions; the bulk of our PTL code simply calls
>         other PTL templates.

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.

> Of course, we don't care about people using graphical HTML editors;
> that would be impossible to accommodate with PTL.

What would be interesting is a template environment where one can
visualise the final form of the template and interact with it, without
having to go through stages of rebuilding and refreshing it, along
with the potential of the document "breaking" and requiring low-level
intervention.

I thought that W3C's Amaya might lend itself to such applications, but
that just has to be added to my list of things that I would like to do
if I only had the time.

Paul