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

[Graham Dumpleton]

Andrew Kuchling <akuchlin at mems-exchange.org> wrote in message news:<3dd76bk8ik.fsf at ute.cnri.reston.va.us>...
> paul at boddie.net (Paul Boddie) writes:
> > >         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
> 
> 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.

One might say that which is better in a particular circumstance depends
more on what infrastructure exists behind that web page, if any.

Take for example if one was using mod_python. This is just a souped up
version of CGI without any real infrastructure behind it. At the other
end of the scale their is ZOPE which has a sizeable infrastructure behind
it.

Where such an infrastructure exists, there is more opportunity for
factoring out functionality related to the model separate from the view
represented by the page. In this case, it possibly makes more sense to
make use of the infrastructure to create reusable functional objects and
have the template mechanism be HTML oriented rather than code oriented.

In a CGI type system, there isn't necessarily any means for reuse in
the same way of persistent functional objects. Instead, the script needs
to more or less contain everything it needs and thus may be better to
be code oriented rather than HTML oriented.

Perhaps you could explain more as to what sort of infrastructure you have
supporting your web pages. Is it just in the form of code functions, or
active functional objects that may actually be able to do independent
processing outside of any actual HTTP request? This may help to show why
the approach you are taking works well in your circumstance.