Zope style (was: tuning our site (was: help! advocacy resources needed fast))

[Cameron Laird]

In article <mailman.1049323265.22242.python-list at python.org>,
Dylan Reinhardt  <python at dylanreinhardt.com> wrote:
>On Wed, 2003-04-02 at 12:54, Cameron Laird wrote: 
>> I find
>> it really interesting when one technology is unequivocally su-
>> perior to another.  I think we have that with DTML vs. Python
>> scripts.
>
>[ jumping in mid-stream ] 
>
>DTML and Python Scripts are different tools, each best-suited to a
>particular thing.  Determining which is better obscures a more important
>point: they're each good tools for a particular set of problems.
>
>DTML's problem space is quite a bit smaller, but that doesn't make it a
>bad tool... just one that should be applied more selectively than it
>typically is. :-)
>
>> There are a couple of pertinent facts.  First, much of the
>> passion "Web designers" are supposed to have for "templates"
>> comes from the supposition that they want stuff to look like 
>> HTML, so they can use their "HTML editors".  Is *anyone* doing
>> that with Zope, though?  
>
>It's not really about the visual editors.  DTML is largely incompatible
>with HTML editors... or so I hear. :-)
>
>The purpose is more basic than that: one is a presentation tool, one is
>a logic tool.
>
>Templating is appropriate when 80-90% of what you want to do is simply
>write out text.  With templating, there is no need to *say* that text
>should be written out... everything you type is returned unless you
>specify otherwise.
>
>When you're performing logic, the reverse is true... most of what you
>type *produces* your content and nothing is returned aside from that
>which is *explicitly* returned.
>
>Templating provides the least cluttered, most concise way of expressing
>*integrating* static and dynamic content.  Python represents the most
>concise way of expressing logical operations.  Each problem will consist
>of some part logic and some part presentation.  Most of my Zope projects
>use a blend of templating and scripting.
>
>> Finally, while your dtml-let is an effective style, 
>
>I almost never use dtml-let.  In my book, it's one of the first signs
>that you're trying to do something DTML isn't well-suited for.  Another
>is use of nested dtml-ifs more than a couple layers deep.
>
>> projects always, always, 
>> always seem to need more parametrization; managers say, "I want
>> it just like that, except it needs to {apply to a different
>> continent,show the current contents of the order,show the 
>> expanded display when the user has selected that, ...}."
>
>If that requirement is thought of as parameterization, DTML is a less
>worthy tool than Python scripts, no doubt.  But if that same set of
>requirements is thought of as "skinning" DTML is a great tool.
>
>DTML's usefulness depends, to some degree, on your use of Acquisition. 
>Your overall site design strategy might have a lot to do with why one
>seems more powerful than the other for any given task.
>
>Dylan
>
>

You make several propositions.  They partition themselves
into two categories:  those I think are important, and with
which I strongly agree; and several I've said myself in the
past.

Talk about Zope might seem better hosted on the mailing list;
I think there's value in keeping it here in clp, though, as
the real issues are ones faced by all Web and Python developers.

You are absolutely right that acquisition is at the heart of
this.  acquisition is very much like object orientation, in its
calculus of inheritance (although I think I have a theorem that
acquisition is harder to get right--more on that, later), and,
of course, notationally.  acquisition is also at least as dif-
ficult to design correctly.  Part of what I'm saying is that,
while I understand how acquisition boosts DTML's expressive
power quite satisfyingly, the domain of applicability of DTML
is so small that it's always--in my experience--more costly to
set up a rational acquisition structure than to work with Python
scripts (themselves occasionally boosted by acquisition).

Object-orientation has the same problems; OO just has more benefits,
and so it can be a net gain.

The symptom of acquisition's liabilities is complexity.  It appears
to me simply to take too much discipline to keep DTML-oriented
acquisition hierarchies from becoming incomprehensible.

Understand, I'm skeptical about the fine divisions of labor that
appear to prevail on some projects:  a Web application designer,
a Web architect, a Web security administrator, several Web visual
designers, and so on.  Yes, if there is that much complexity in the
workflow, acquisition and DTML match the work rather well.  I'm un-
impressed by what I know of such teams, though.

You write aptly of templating as presentation vs. algorithm.  Maybe
a more moderate expression of my views is this:  whereas I began
Zoping with the anticipation that some large portion--80%?  50%
20%--of site content would appear in DTMLs, I find the best balance
is shockingly low, perhaps no more than 5%.  This seems to be true
even for "brochureware" sites.  

Maybe the real issue is just the asymmetry I feel; I much prefer to
add """-coded presentation to a script, than <dtml-ish algorithms
to DTML.
-- 

Cameron Laird <Cameron at Lairds.com>
Business:  http://www.Phaseit.net
Personal:  http://phaseit.net/claird/home.html