[Zope-dev] Re: [Zope] DTML Syntax contd. + rant
Phillip J. Eby
pje@telecommunity.com
Thu, 11 Nov 1999 13:30:24 -0500
At 01:13 PM 11/11/99 +1100, Evan Gibson wrote:
>
>I _shouldn't_ be doing things like this in DTML. It shouldn't even let me.
>The whole _.getattr(blah) sections are far beyond the reality of a
>reporting language, and they don't go properly with an Object Oriented
>paradigm either.
>I should instead have an object made and be going:
>
><dtml-with "currentuser.get_skin()">
>
>But the existing framework doesn't encourage this. If you banned _ access
>in anything but python methods and made it so python methods can only be
>used in Products, then you'd have the proper divide.
I've got to say I disagree on a fundamental level with the whole, "DTML
shouldn't let you do stuff" idea. Having to have two different languages
to program one application is really pretty ridiculous to me. If it made
sense, then why *aren't* we all "doing the right thing" and making objects
and using DTML only to format HTML?
Well, for one thing, it breaks the flow of development. It's like saying
you should use Python only for scripting and anything that's "real
programming" you should immediately drop down to C or C++ and implement
something you can call from Python. Doesn't that seem rather silly?
But there's a second, and far more significant reason why trying to make
DTML "just a reporting language" doesn't work in reality. It's this:
*generating HTML is a programming task*. The reason you need programming
capability in DTML is because you need to program the bloody HTML, URL's,
query strings, and all the other overhead of making an interactive
application. If you start pushing the hard bits into Python, then sure,
you don't "pollute your presentation with programming", but then, you start
polluting your programming with presentation, which is equally bad, if not
worse.
Should people use good style? Sure. Should you make products that
implement all the data/business rules stuff and provide a clean interface?
Absolutely! But doing this won't keep the need for programming out of
DTML, because there will always be the need to perform transformations and
compositions of arbitrary kinds on those data objects, precisely *because*
they encapsulate data and ignore presentation!
That's the dirty little secret of why none of us can kick the
programming-in-DTML habit.