On Tue, Jul 23, 2002 at 01:17:30PM -0400, Chris McDonough wrote:
To put it another way, DTML does not prevent you from assigning values to variables, but it does nothing to make it easy (like providing syntax). I've always wondered if there was a design decision behind this or just a simple oversight.
It's a design decision, enforced by a "papal edict" (Jim hates REQUEST.set).
Sometimes papal bulls are, in the American slang sense, just bull.
You know, I understand this, to a point. But it does have a very real cost (particularly in DTML), and I think the cost was overlooked because zope.com is so heavily into zope as document management system, rather than an application server. If you are using zope heavily as an application server, you have a very typical pattern of receive form, canonify data (always strip, often take to a particular case), validate data, and store or otherwise process the data. There is no reason to have the canonify/validate steps be part of the processing procedure. Both for reasons of reuse, and general clarity, they really belong in separate methods. But now you have a problem. You have to get the canonified version of the REQUEST data back to the processing method. And I know of (in DTML) no other way than using REQUEST.set. ZPT offers the 'options' namespace, which I try to use exclusively when passing a variable that was not part of the original REQUEST. But, it still feels silly to make a new variable to hold the canonified and validated data, rather than just using REQUEST.set. With hindsight, it might have been nice to have REQUEST be read-only, and something like OPTIONS. OPTIONS would have been a dictionary, initially empty, with a OPTIONS.set method. namespace lookup (in DTML) would always process OPTIONS before REQUEST and before acquisition. This would provide a writeable short-teem dictionary. But, it is too late to think about that now. Jim Penny PS: I have moved pretty much to ZPT these days. I still use DTML, when it is needed, or occasionally when it feels much cleaner. The reason that I moved and stayed is mostly twofold. First, the options namespace is, in fact, a much cleaner solution. Second, path expressions make it relatively easy to use the same form to both accept input and handle errors. This makes it far easier to change things, in that rather than messing with an input form and an error, everything you need is in one place. It feels like zope.com makes a mistake in using the "closing designer to developer loop" as the primary seling point of ZPT. Jim Penny
- C
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )