Re: What causes the community to stall so often?
(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 ------------------------------------------------------
Why not just fix DTML so it isn't so ridiculously hard to document and use?
The things that make DTML hard to use are mostly non-fixable. Anothe non-fixable thing is that HTML with DTML dotted around is not editable in a HTML editor. ZPT fixes that. This doesn't mean DTML can't be improved, of course, but I personally don't agree that the improvements you point out make dtml that much easier to document or use. The main "hardship" with dtml is that you end up with two independant language structures, DTML and HTML, where you often are forced to break the HTML structure with DTML structures. It makes the code messy, and it is one of the reasons why you can't use HTML editors to edit DTML-code. ZPT tries to fix that. I don't think DTML is a failure, neither do I think Zope corp claims it is. DTML could be viewed as the Zope equivalent of for ASP, and it is much, much better than ASP will ever be. Is it a failure then? No, but it had non-fixable problems. Problems that any language with the same basic structure will have. But of you preferr thisover ZPT take at the problem, then you can still use DTML.
On Sunday 10 March 2002 9:43 pm, Terry Hancock wrote:
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. ZPT + Python = goodbye and good riddance to dtml, for me at least. Now the only DTML I write (except maintenence of old code) is in file system ZSQL methods, where there is really no alternative (AFAIK).
(e.g. why not represent "sequence" as a Python class with "item", "index" attributes and/or "odd()" "even()" methods).
Hmm, this sounds familiar.... how well did you look at ZPT exactly?
(for example), instead of the ridiculous work-around:
_.getitem('sequence-item').absolute_url()
Not pretty, is it? Glad I don't use DTML any more. ZPT is nice and clean.
Zope is a good thing already. It doesn't need more junk. What it needs is a whole lot of straightening up.
If you ask me (and you didn't but I'm telling you anyway), ZPT *is* a part of straightening it up. I never liked DTML from the moment I started using it, it was too easy to write messy code. I had all the same problems I've had with ASP. I am eternally thankful for the day ZPT was pointed out to me. I know many people out there like to use DTML because it's what they're used to, and some of them don't abuse it and write spaghetti code with it, but then what they're doing could probably be directly ported to ZPT if they're seperating out their presentation and application logic properly. I don't see a reason to use DTML except for familiarity, and it's not exactly hard to get familiar with ZPT. Harry
On Sunday 10 March 2002 9:43 pm, Terry Hancock wrote:
(e.g. why not represent "sequence" as a Python class with "item", "index" attributes and/or "odd()" "even()" methods).
Hmm, this sounds familiar.... how well did you look at ZPT exactly?
(for example), instead of the ridiculous work-around:
_.getitem('sequence-item').absolute_url()
Not pretty, is it? Glad I don't use DTML any more. ZPT is nice and clean.
For the sake of completeness, I would just like to add that the "hyphen problem" has been identified quite a while ago, and "sequence-item" has been kept for comptatibility reasons only. Instead of getting rid of it totally, a "prefix" attribute has been added to the in-tag (and all variables used there), so that you can do stuff like <dtml-in mysequence prefix="loop"> <dtml-if loop_start> <dtml-var "dosomethingwith(loop_item)"> <dtml-else> <dtml-var loop_var_thisisavariableofthecurrentsequenceitem> </dtml-if> </dtml-in> which also allows easy implementation of nested loops (different prefixes). I find it alright to have and keep the choice of two approaches (DTML/ZPT) as long as the mere existence of the one doesn't negatively influence the performance or whatever of the other (which is not the case here). For the same reason I appreciate it that ZClasses still exist: If you don't need'em, don't use'em. I would find it quite a hard task to decide what to keep and what to chuck, and imho ZC did quite a good job up til now. The "big step" incorporating at least most of the prior experiences in the development of Zope is not far away after all (Zope 3). Cheers, Danny
Danny William Adair wrote:
For the sake of completeness, I would just like to add that the "hyphen problem" has been identified quite a while ago, and "sequence-item" has been kept for comptatibility reasons only. Instead of getting rid of it totally, a "prefix" attribute has been added to the in-tag (and all variables used there), so that you can do stuff like
<dtml-in mysequence prefix="loop"> <dtml-if loop_start> <dtml-var "dosomethingwith(loop_item)"> <dtml-else> <dtml-var loop_var_thisisavariableofthecurrentsequenceitem> </dtml-if> </dtml-in>
That is so useful! Thank you for posting it. I only wonder why I never found this out before. ;) I'm going to start using that and convert my old code too. Of course, I agree that I don't object to other people using ZPT, though I personally can't warm up to putting code in HTML attributes. It's probably mostly a visual thing, but to me the ZPT code looks really crudded up and hard to read, whereas DTML seems pretty straightforward. (This is not just a question of familiarity -- both are pretty new to me). And besides, it's obvious that it will only work with HTML (maybe general XML formats?). My impression is that ZPT is being pushed pretty hard though, despite the fact that it's main claim to fame seems to be that it "looks good in Dreamweaver" (or other HTML GUI editor), which is fairly irrelevant to me, since I use gvim and more often than not, the Zope web interface. Even though I plan to release my application as a "Product", the interactive web interface is extremely useful -- it's the equivalent of the Python interpreter, which I also use extensively. It is, after all, the most definitive reference you can get on what actually works in Python! It's generally faster to just try a thing out than to figure out whether it will work from the documentation. I code in tiny bits, unit test, and assemble -- much better to find the bugs as you go. So my GUI is Zope itself, hence it really doesn't matter how it renders in something else (its not as if it costs much to run a separate testing and development server). Maybe the real point is that in our organization (which is just a couple of people strong :)), the "designers" and "programmers" are the same people -- we don't have the kind of divisions that the posts on the this list seem to imply are common to most users. I find this a little odd, since I believe that "form should follow function" -- the visual appearance of a page should naturally relate to its behavior, and also that artistic design should extend to behavior as well as appearance -- a website or webapp is a 4-D object: width, height, render-time, modification-time. Trying to develop from static HTML code is a bit like reconstructing a stage performance from a few still-photos and presents the same problems in interpolation. The fear then, is that DTML will no longer be maintained and will wind up being obsoleted by future changes to Zope. Since there's no real alternative to using Zope for my project (which is projected to last longer than Zope has yet existed), I fear the possibility of getting (1) locked into an out of date system, (2) having to translate everything into ZPT despite my misgivings (and/or whatever new language is invented a year from now because ZPT is then given up on too, and "everyone really ought to use YAPTL"), or else (3) having to fork the code and maintain our own "Rationalized Object Publishing Environment" (as in just enough to hang ourselves), which would be, to put it simply, VERY EXPENSIVE. :D Of course the biggest problem with DTML is the namespaces, and how to keep track of them. I'm actually not sure that the design is bad -- it may be more that it is not well-explained in any of the sources I've been able to find. I've also noticed that a lot of the documentation projects seem to date back to 1999 or 2000 with little or no improvement since then (and I know Zope has evolved significantly during that time). Cheers, Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------
From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Terry Hancock Sent: Tuesday, March 12, 2002 3:15 AM To: danny@adair.net; Zope@zope.org Subject: Re: [Zope] Re: What causes the community to stall so often?
It's probably mostly a visual thing, but to me the ZPT code looks really crudded up and hard to read, whereas DTML seems pretty straightforward. (This is not just a question of familiarity -- both are pretty new to me). And besides, it's obvious that it will only work with HTML (maybe general XML formats?).
Yep. Works with any well-formed XML.
My impression is that ZPT is being pushed pretty hard though, despite the fact that it's main claim to fame seems to be that it "looks good in Dreamweaver" (or other HTML GUI editor), which is fairly irrelevant to me.
Might want to look deeper into ZPT, at least until you understand it's value. Yes, it does work well with GUI editors, but it also provides a clean and predictable interface, whereas there are exceptions to exceptions about how DTML works and DTML, in general, has a screwier syntax once you get into it.
Maybe the real point is that in our organization (which is just a couple of people strong :)), the "designers" and "programmers" are the same people -- we don't have the kind of divisions that the posts on the this list seem to imply are common to most users.
I'm a shop on one: sales, designer, programmer, client therapist, etc. I love ZPT (but also use DTML for non-HTML output, like for ZSQL methods, etc.)
The fear then, is that DTML will no longer be maintained and will wind up being obsoleted by future changes to Zope. Since there's no real alternative to using Zope for my project (which is projected to last longer than Zope has yet existed), I fear the possibility of getting (1) locked into an out of date system, (2) having to translate everything into ZPT despite my misgivings (and/or whatever new language is invented a year from now because ZPT is then given up on too, and "everyone really ought to use YAPTL"), or else (3) having to fork the code and maintain our own "Rationalized Object Publishing Environment" (as in just enough to hang ourselves), which would be, to put it simply, VERY EXPENSIVE. :D
I really wouldn't worry about this. ZC has said many times that DTML is _not_ disappearing; it's a stable part of the Zope system and they have every reason to keep it there.
----- Original Message ----- From: "Harry Wilkinson" <harryw@nipltd.com> To: "Terry Hancock" <hancock@anansispaceworks.com>; <zope@zope.org> Sent: Tuesday, March 12, 2002 1:45 AM Subject: Re: [Zope] Re: What causes the community to stall so often?
ZPT + Python = goodbye and good riddance to dtml, for me at least. Now the only DTML I write (except maintenence of old code) is in file system ZSQL methods, where there is really no alternative (AFAIK).
I must agree with Harry on this point. When ZPT first appeared, I found it difficult to wrap my head around it. DTML did everything I needed. Why learn another language? But when I started to play with CMF/Plone, I needed to learn ZPT and decided to give myself time to find out how it really worked. Reading the ZPT chapters in Zope Book 2.5 really helped me get an understanding of how it all works. Now I think ZPT + Python is a much better way to build applications than with dtml. Ot
participants (6)
-
Danny William Adair -
Harry Wilkinson -
Joel Burton -
Lennart Regebro -
Ot Ratsaphong -
Terry Hancock