[Zope3-dev] Re: DOM manilulators (was Re: <script> - the anti-pattern)

[Phillip J. Eby]

At 05:39 PM 9/10/03 -0400, Jim Fulton wrote:

>We originally wanted something like this for ZPT, and still do. We put 
>this aside
>when figuring out ZPT and never came back to it.  I'd love to see 
>something like
>this added to ZPT.

Note that it is basically equivalent to METAL...  It's just that you'd need 
to be able to write ZPT macros in pure Python.  (And, I suppose you'd also 
need a way to supply all the contained elements to the macro, not just the 
defined slots.)


>P.S. I don't think that this has anything to do with the motivation of the 
>scropt tag. :)

Well, yes, actually, it does...  I was pointing out that the approach taken 
by PSO, Woven, and p.w.t allows you to create a templating "language" that 
forces all the "coding" to be external, in *contrast* to languages like 
DTML and ZPT, that embed programming language constructs in the page.

IOW, I was noting that this approach might be useful for creating a 
restricted *alternative* to ZPT, without the feeping creaturism of <script> 
et al.  Such an approach has other advantages besides the DOM manipulation 
ability, such as providing a very well-defined boundary between templating 
and Python code.

Generally speaking, I'm in agreement with the issues that have been raised 
regarding refactoring, learning curve, etc. in relation to ZPT, which is 
why after looking at PSO and Woven I decided to take that route in 
p.w.t.  I think it's actually easier to show the power of a component 
architecture if you can really use *components* in your pages, instead of 
writing code in one or two languages mixed into the page (e.g. 
TAL+Python).  The code-in-the-page approach leads to people trying to do it 
"like I do in PHP", whereas the components-in-the-page approach looks like 
something "new and different".

Anyway, I know you don't agree with those arguments, as I've read your 
answers to others' posts about them.  However, if the "conscientious 
objectors" to <script> et al want to have an alternative they could promote 
to the users/environments they deal with, they might be interested in 
implementing some kind of components-in-the-page approach, as I think it 
basically does what they're looking for.  That is, a "scripting-free" page 
templating mechanism.

(Ironic that we end up yet again on opposite sides of this fence, but with 
reversed positions.  I remember a few years back you saying that a 
templating language should be locked down so that it contains no scripting, 
while I argued fiercely for the reverse, on the grounds that logic was 
needed to be able to do presentation in HTML.  I hung onto that opinion 
until I saw Woven a few months ago, and realized such "presentation logic" 
could be componentized and factored out of the templating 
language.  Meanwhile, you're adding <script> to ZPT.  Funny world, ain't it?)