(I can't believe this thread is still going, but what the hey ... here's my 2 cents, I can hope it'll have some impact) I think the reason that Zope documentation is poor, and in particular why Zope developers don't write much is because they would much rather add features than fix bugs and oversights in their earlier work (or even think about them). Take ZPT. *Another* language? Zope already maintains one and depends heavily on another. They themselves declare DTML a failure, but they've got it all right this time? "Fool me once, shame on you. Fool me twice, shame on me!" ;) And ZPT is completely different, doesn't work in all the same places, and is (IMHO) ridiculously cumbersome and non-intuitive. Maybe I haven't given it a fair review yet, but the reality is, I just don't have time for it. Certainly it is not a natural extension to DTML, nor a replacement for it. Why not just fix DTML so it isn't so ridiculously hard to document and use? Consider just a couple of really obvious problems (dozens of more subtle problems can no doubt be unearthed): GET RID OF THE STUPID DASHES! "sequence-item" -- Oh come on! Where'd that come from? Other languages (including Python), use a "." for this kind of purpose (e.g. why not represent "sequence" as a Python class with "item", "index" attributes and/or "odd()" "even()" methods). That would probably make the most sense. Barring that, why not simply substitute "_" for "-". Then at least, we could use: sequence_item.absolute_url() (for example), instead of the ridiculous work-around: _.getitem('sequence-item').absolute_url() "_." -- Why do we have this? In a Python script we use builtins as builtins, now they're all methods of this mysterious object. Why? And is it REALLY that hard to fix? Actually namespaces in Zope are altogether a mess. I'm not sure I even understand them now, but it seems to me that some simplification may be in order. DTML would be SOOOO much easier to understand (and explain) if it only made sense to begin with. (It's also notable that the above criticisms are actually of the Python API which exists inside DTML expressions. The worst criticism of this is that it is inconsistent with the Python API in Python Scripts). And I emphasize that DTML is actually a very good concept -- DTML is like a rough sketch of a good idea. The problem is that it needs to be redrafted to capture that idea better. I did recently discover a rationalization which I applaud: Previously, the filesize of Image and File types was acquired from the "getSize()" method, while DTML Documents and Methods used "get_size()". In Zope 2.4.3, both methods are available for both sets of classes, though I haven't figured out which is preferred (the rationalization is not reported in the Zope 2.5 API online at www.zope.org). Zope is a good thing already. It doesn't need more junk. What it needs is a whole lot of straightening up. And if it were straightened up, it'd be a whole lot easier for people like me, who *like* to write, to write documentation for it. Right now I wouldn't touch it with a ten-foot pole! In short, the documentation is poor, because even the people who would write it can't figure Zope out. Contrast with how carefully the Python syntax options are reviewed (not just by Python developers, but by Python programmers worldwide) before they allow additions. That kind of conservativism can be frustrating, but it also keeps the API pretty clear of debris, and makes the way a lot easier for experienced and new developers alike. Zope developers obviously appreciate this, or they wouldn't have developed in Python to begin with, so why not apply it to Zope? What I'm waiting for is the day when *www.zope.org* will print this message that www.python.org has had (e.g. on the 2.1.2 release page) for some time: "we've been very careful to fix only bugs and not add new features." That is such a warm feeling! I wish I could feel that way about Zope. IMHO, of course, Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------