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

[Dylan Reinhardt]

On Thu, 2003-04-03 at 06:25, Cameron Laird wrote:
> 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.  

The comparison is an apt one, and it's clear what inspired acquisition. 
It's a bit like composition by context.

But there is a bit of a conceptual dead end you're going to hit by
defining acquisition in terms of inheritance.  Acquisition can just as
easily be thought of as a way of providing abstraction and polymorphism.

Thinking of acquisition that way, the expressive power of templates
becomes greater.  Instead of thinking about what logical operations
should be performed, it is possible to think in terms of contextual
behavior.  This can shift the balance between logic and presentation
enough that templating is sufficient for a greater range of tasks.

Say my_method uses some markup we've saved seperately as my_widget. 
It's pretty straightforward to set up my_method such that it checks for
an overriding my_widget and uses the standard my_widget if no other is
found.  It is now trivially easy to implement custom changes for
clients, as each change requires only that the differing code be stored
in a client-specific Folder.  One glance at each client's root folder is
sufficient to display what customizations have been made on their behalf
and hardly any logical operations are used at all.

If you get more that a handful of clients on one box, this can be a huge
improvement over burying the implementation details in the code of each
method.  Being able to view customizations *by client* instead of *by
method* can be very helpful.

Of course, you can do the same thing with Python scripts... but I find
aggressive use of acquisition tipping the scales towards DTML more often
than not.


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

It's been my experience that acquisition structures are often needlessly
complex.  Then again, I make heavy use of custom products, which makes
it quite a bit easier to simplify your folder hierarchy.

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

Well... clarity and strength of design are issues with software in
general.  It takes a lot of discipline to come up with a good design and
manage the changes that are made to it during implementation.  You can
make spaghetti sites with DTML quite easily.  On the other hand, design
discipline pays off in most software tasks... why shouldn't it in Zope?

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

As with most group software projects, design control and revision
control are critical.  It's slightly more difficult to do revision
control on Zope objects than it is on source files... but not so
difficult that it isn't worth doing.


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

For me, it depends on what's being done.  I find inserting multiple
values into a page of markup is more readable in DTML.  Some HTML --
particularly form controls -- seem better suited for Python.

Examples:

--------

Hello, <dtml-var fname>.  This is demonstration of MySoft version
<dtml-var software-version>.  Just think, <dtml-var fname>, now 
you can shift paradigms and think outside the box at 
<dtml-var company> without leaving your office.

vs.

my_output = """Hello, %s.  This is demonstration of MySoft
         version %s.  Just think, %s, now you can shift 
         paradigms and think outside the box at %s without 
         leaving your office.""" % (fname, version, fname, company)
return my_output

--------

I find the former to be far more readable and more easily maintained...
particularly as the size of the sample increases.  Inserting additional
variables or moving around existing ones is easy in the first sample and
must be done carefully in the second.

On the other hand:

--------
<select name="<dtml-var select_name>">
<dtml-in my_key_value_pairs prefix=my>
    <option value="<dtml-var my_key>"
    <dtml-if "my_key==my_selected_option"> selected</dtml-if>
    ><dtml-var my_value></option>
</dtml-in>
</select>

vs.

output = ['<select name=%s>' % select_name]
selected = {1:' selected', 0: ''}
option_tag = '<option value=%s%s>%s</option>'
for kv_pair in key_value_pairs:
    output.append(option_tag % (kv_pair[0], 
                                selected[kv_pair[0]==selcted_key], 
                                kv_pair[1]))
output.append('</select>')
return ''.join(output)

- or -

<input type=text name=foo value="<dtml-var "my_method('argument')">">

vs.

return '<input type=text name=foo value="%s">' % my_method('argument')

-------

I often go with Python for form controls since Python handles logic and
quoting with more grace. But many times it's a toss-up which is better
for a given situation.  Really, they're *both* good tools to have at
your disposal.

Dylan