[Zope] Re: Java re-invents DTML :-)

[Terry Hancock]

[Okay, I've taken my deep breath, counted to ten, slept on it, and can now 
post on this subject, without flaming too much, hopefully ;-D]

On Wednesday 19 February 2003 09:00 am,  sean.upton@uniontrib.com wrote:
> This is well put.  I think this argument is also true of designers who don't
> use WYSIWYG tools as well, for the same reason, I think: round-trip design
> involves iterations of programmers messing with the behavioral and
> integration aspects of templates while the designers want to keep changing
> the design over time.  As each of these steps happens, DTML makes the two
> have to communicate more and correct for missteps more, while ZPT allows for
> each to operate more independently and still modify the code somewhat
> independently, without the need to reverse-engineer and reintegrate.  This
> is the case even when the designers use tools like Homesite or a text-editor
> instead of GoLive or Dreamweaver.

I actually agree with you on the effect of ZPT: It does prevent designers and 
programmers from having to communicate effectively. In fact, it makes it 
nearly impossible! That's the problem.

Because to a designer "trained to think XML-ish" as another poster put it, 
ZPT looks like this:

<span/><span/><span/><span/>

Or to express it in Python:

pass
pass
pass
pass

(I know this, because it looks that way to me, too).

ZPT's actual program structure is buried in attributes where it is nearly 
invisible, and certainly incomprehensible to the designer.  It also contains 
a lot of annoying and distracting boilerplate.  Nearly every ZPT example on 
the "DTML to ZPT" page is *longer* and *harder to understand* than the 
original DTML. This should be telling you something!

If the designer is just making a pretty layout, that's all well and good, but 
that describes my application about the way that "text file" describes a 
Python script.

DTML, on the other hand, is *understandable* to the designer, as it provides 
a good novice-level of understanding of programming tasks. And it allows the 
designer to control the behavior as well as the appearance of the 
presentation layer.  Yes, this means designers have to learn DTML. Well, they 
should -- it'll be a good deal easier than teaching them ZPT.

Clearly there is a potential problem if the presentation layer code becomes 
too complex -- usually this means that you have something that shouldn't 
really be considered presentation anymore.  I've run into that *once* in my 
design.

The truth is, programmers and designers *can't* communicate unless they have 
a common language -- and HTML is not rich enough to be that language.

"Ausum Studio" <ausum_studio@hotmail.com>  said:
> That's all true, but I think we're kind of missing a point in the whole
> discussion. Not everyone says let's all code in one single language and
> trash the other.

In fact, that's precisely what I'm arguing against! Chris Withers suggested 
trashing DTML in Zope 3 -- and I would be awfully annoyed by that. I realize 
that ZPT is his baby, and I respect that -- but DTML is what I use, and I 
plan to keep using it.  I just don't want everyone to go nuts over ZPT and 
throw DTML away, when it is still a very useful language. I also don't want 
to see DTML frozen or abandoned -- I think it can and should be improved. 
Some of the recent ideas (like the path indirection method "x/y/z"  to 
represent variations on x[y].z and z.y[z] and so on) are very nice, and I'd 
like to see them used.

ausum_studio@hotmail.com:
> The other thing that in my opinion we
> might be missing, is that a dynamic portal is not necesarily made out of
> logic and whole page templates.

Indeed, I find that to be a very trivial case which misses much of Zope's 
potential.

ausum_studio@hotmail.com:
> I'm convinced that there is at least one more stage in-between
> made out of page fragments that can be handled as a real
> object (pagelets). Think of a search results page, or a folder
> contents one. Don't you think there's something that can be
> automated there that could save valueable developers'
> time, by means of an object whose mission was to take over
> the repetitive coding (across different sites) and to deliver the
> page fragment (the rendered columns and rows in a table) we
> just need in that particular page?

This is precisely the approach I use.  In my product, I am moving to a mode 
of design, where python objects return views of themselves when referred to 
from DTML -- the views may render as whole pages or (more often) as 
"pagelets" as you call them. This allows for several different layers of 
views of object collections or single objects.  This occurs so often in my 
product, you might think of it as the central design paradigm.  These 
pagelets, of course, are defined in DTML methods within the product. The 
containing page may also alter how these pagelets are composed into a page -- 
that is also a designer's decision.

ausum_studio@hotmail.com:
> Something like dtml-tree already does, but movable, reusable
> and highly configurable in a dedicated UI, and completely
> independent of macros of any flavor?. Well, that's the kind of
> stuff I'm working at for what I believe DTML and PythonScripts
> are just better suited than ZPT.

Same here, and I agree!

While I'm willing to acknowledge that for other people, with vastly different 
needs than mine, ZPT is great, it does not help me very much, and I don't 
think this is just because I haven't given it enough of a chance.

It *is* partly because I already have significant assets in DTML that I do 
not want to have to replace just to get newer Zope capabilities (far better 
to spend my time adding additional capabilities than to constantly have to 
rework the old).  I would feel deeply betrayed by the Zope development team 
if they just decided to declare DTML (and therefore a large chunk of my work 
that depends on it) obsolete.

Therefore, I think it is perfectly reasonable to want DTML to *stay* in Zope. 
Failing that -- "the last duty of a maintainer" is to pass the package on to 
someone else. DTML could become a separate Zope Component in Zope 3, if 
necessary -- but the core team should at least provide the effort to excise 
it into a separable component so that it can *realistically* be maintained by 
third parties.  The current code is rather deeply intertwined with Zope's 
main sources, AFAIK.  I believe that the idea of component-izing Zope is 
central to the v3 plan, right?

Well, that's my two cents, anyway. ;-D

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com