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