[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