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

[Mark Pawelek]

Yes I agree with all your points. However whatever the final system - I think that
flexibility is key so that one could sometimes delimit server code with tags and also get
a quick idea of what the output from a templated system would look like (but also easily
edit the client-side code).  I often get annoyed when writing a page heavy with ASP where
most of the HTML is output using Response.Write because I need to go through the whole web
site to get to that page - wouldn't it be nice if there was a system that allowed one to
input form, cookie and querystring variables on the fly so that the HTML output could be
viewed immediately?

I like to write the pages first as HTML (to get style sheets, graphics and client-side
javascript DHTML right) and to check these pages using Adobe GoLive 5 HTML checker.) With
SVG and XML output something like this will still be needed - especially with interactive
client-side script with lots of DHTML and interactive SVG. When the HTML is looking pretty
(and correct) it's converted to ASP pages. But I don't like the way in which the server
language forces me to escape all the quotes in the HTML thereby making it impossible to
view (and difficult to edit) the resulting HTML until it appears again in the browser.

Clearly I think that a future Python Server solution should be superior to ASP as it is
and as it will become in ASP.NET


On 2 Aug 2001 02:50:00 -0700, paul at boddie.net (Paul Boddie) wrote:

>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