[Zope] change variable

[Chris McDonough]

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

I agree.  Luckily, Zope is extensible to that point that someone can
create their own tags to do this.
http://www.zope.org/Members/ivo/SetTag

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

Errr.. well, we do lots of jobs.  Very few of them are document
management systems; mostly we build content management applications.
I'm not sure what the difference would be, though.  Zope is an
appserver and we use it as such to build apps.

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

You can pass arguments to DTML methods & documents from both Python
Scripts and other DTML methods/documents (as well as ZPT).  (re:
http://www.zopelabs.com/cookbook/992031125) It's not pretty, but it
does work.  I think the awful DTML object call signature is at the
root of the issue you talk about, otherwise we'd just say "pass it
in as an argument" and this issue would disappear.

As you say, ZPT offers namespaces for this kind of thing.  We'd like
to do the same thing for DTML (see
http://dev.zope.org/Wikis/DevSite/Proposals/DTMLplusTALES) but the
call semantics are so "baked-in" that it would be terribly difficult
(maybe impossible) to do so in a backwards-compatible way.

> It feels like zope.com makes a mistake in using the "closing
designer to
> developer loop" as the primary seling point of ZPT.

It is a cleaner system, no doubt about that.

- C