[Zope] Re: What causes the community to stall so often?

[Terry Hancock]

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