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 ------------------------------------------------------