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

[Terry Hancock]

Since my only reason for jumping into this conversation was to make the case 
that DTML still has a place in the world, I'm going to drop the ZPT vs DTML 
argument.  While I have no doubt that some people will continue to crow over 
ZPT's virtues, I am pleased to see that I am not the only one who wants DTML 
for keeps.

On Monday 24 February 2003 04:10 pm, Dylan Reinhardt wrote:
> 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.

Indeed, as regards thru-the-web code, I consider one object per "file" to be 
the norm and the best practice.  Indeed, I don't call them "files" I call 
them objects -- or to be more precise "Zope objects", and I view the ZMI as 
an object-browsing interface.  From this POV, 1:1 is exactly the right 
"widget-to-file" ratio.

It's perhaps relevant that I actually do use the Zope HTML interface for 
working on thru-the-web stuff.  I'm satisfied with the level of function this 
provides, and I really like the location-, OS-, and browser-independence. I 
do in fact maintain my website from more than one computer -- and not all of 
them are set up with a development environment!

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

Actually in my code, each widget is a view on a zope object -- an object 
typically has a number of such views which can be called.  In other words, 
they are parallel to methods and attributes (of course they are also objects, 
in a broader definition).

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

And here we're getting to the meat of the matter. In my project, you'll find 
most of those DTML views defined inside the product, in (for example):

&dtml-zope_instance_directory;/Products/MyProduct/dtml/ObjectFoo/

where ObjectFoo is the Zope object being defined.  The really cool thing is 
that in that DTML I can reference a whole bunch of images, colors, styles, 
etc. by variable name, and let the site-admin overload them with their own 
code if they like.  In all probability the admin could use ZPT to do this, if 
they so choose.

I use Python to define how objects behave, and DTML to define how they look.  
With CSS and variable substitutions this is trivial to customize by the end 
user. To make things even simpler, I just provide control panels so you can 
pick your resources.

This is all very incomplete, though -- I've only had about 0.15 FTE for 12 mo 
on this.  Hopefully by this Summer, I'll be able to "show not tell" -- that 
0.15 is at least going to go up to about 0.50 by then. ;-D

Then you guys can tell me how badly conceived my code is after actually 
seeing it yourselves (somebody's going to remember I said this, I just know 
it ;-D).

In any case -- it's getting pretty clear that I should spend more time coding 
and less chatting about it, even if I do hate ceding the last word. ;-)

Cheers,
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com