[Zope] Re: Java re-invents DTML :-)

[Dylan Reinhardt]

At 10:55 AM 2/24/2003, Max M wrote:
>You would need to create another dtml document just for the purpose of 
>writing the content of this "box"

Which I consider a feature, not a bug.  More on that in a second.

>If you have 5 boxes on a page, that is a LOT of auxillary methods just for 
>rendering one view.

But if you do segment your code at this level, you may have an easier time 
re-using those 5 boxes on other pages in other contexts.  The decision 
hinges not on *if* you re-use code, but on *how* and *where* you re-use it.

My philosophy is that the best way to re-use code is to have a larger 
number of relatively autonomous single-purpose objects that act correctly 
in different contexts.  Each widget is an object.  This philosophy stresses 
polymorphism and encapsulation as primary virtues.

What you're advocating is a more monolithic approach: that a single ZPT 
object should define whatever widgets it uses and that these widgets are 
primarily used within a specific context.  This approach stresses more of a 
project-centered orientation to software design.

>In zpt, on the other hand, you have it all in one easy to read file.

>The advantage being that you can have all the code concerning 1 view/page 
>in the same file, while you still only have to write the code that is 
>unique to that particular view. And you can re-use design elements at the 
>same time.

Monolithic design can work great for individual projects, but when you have 
dozens of clients and at least as many projects, how are you going to 
remember which page of what system for which client you used for defining 
your slashbox macro?  And why should you add new features to *that* file 
when the features are for a different system?  How does *that* make sense?

Conversely, how does it promote code re-use to have several different ZPT 
files making custom changes to some lowest-common-denominator macro?  If 
any number of your objects make use of a common option or feature, you 
should only code that feature once.

By defining each widget as its own object, any changes you make are easily 
tracked and it won't be any harder to find your slashbox code than to look 
in /widgets/slashbox.

You appear to be striving for a higher widget-to-object ratio than *I* 
would find useful.  To me, it's a design goal that each piece of the puzzle 
should be implemented as its own object.  I would find it more confusing 
and duplicative to give each page its own set of context-specific 
widgets.  I'm sure it works great for the kind of work you do and I'm not 
trying to talk you into changing your coding style... just pointing out 
that it may not be the best approach in all situations... particularly not 
those I'm working in.  :-)

>You will need a lot more glue code in dtml to do the same thing as you do 
>"naturally" in zpt.

That's not my experience.  But that may be a function of what each of us is 
trying to do and what our requirements are.

ZPT is a great tool for many (maybe even most) applications... but it 
simply isn't a best-for-all-situations, one-size-fits-all technology (as if 
such a thing ever existed).  DTML is the better tool for some problem 
domains.  I'm not sure how that's controversial.

Dylan