[Zope] Defining variables

[Phillip J. Eby]

At 11:54 PM 7/13/99 +0200, Alexander Staubo wrote:
>> Syntacticly, each argument to be evalulated in the head of the let
>> tag must be seperated by a newline.  Enclosing an argument in double
>> quotes causes it to be evaluated by the DTML expression machinery.
>> Un-quoted arguments are referenced by name.
>
>Is it just me, or is this newline-separation syntax really crazy? How
>does the "let" tag handle multiline expressions? Why not just use
>commas? It would mean alienating those suckers who actually use commas
>in object ids, but that's not a huge loss. ;-)

Um, the documentation quoted above is incorrect.  I submitted a patch for
the doc file the other day, but it has not been applied.  Newlines are not
required in order to seperate "let" arguments.  The normal argument parsing
of DocumentTemplate tags applies, except that "let" allows arguments to be
repeated.  I think the person writing the docs just assumed that newlines
were required because all my examples used newlines and whitespace for
clarity.


>Indenting is just part of the reason I think the "let" tag is
>inappropriate here. With the closing tag, that's just seven characters
>less than the REQUEST.set() alternative! Plus line break, that's
>actually five characters gained. Not much typing saved there.
>
><!--#call "REQUEST.set('f', 1)"-->
><!--#let f=1--><!--#/let-->
>
>I essentially want something like
>
><!--#set foo=1-->
><!--#set foo=3-->
><!--#set foo=4-->

I'm planning to write a "set" tag that does exactly this.  The tricky part
is, it'll only be able to be used within the body of a "let" block, because
it'll need to know what level of the namespace stack it can safely write
to.  It will do exactly what you want as long as there is at least *one*
containing "let" block somewhere in the DTML namespace stack.  It doesn't
have to be in the same document or method, so long as the document or
method is called from inside a let block somewhere.

The only other way I see to handle it, is to have DocumentTemplates add an
extra dictionary to the namespace stack at every level of calling stack -
which is a heavy overhead to pay for such a feature, especially for those
who don't use it!  The "let" tag has to add a dictionary to the namespace
stack anyway, and it also has the additional benefit of precisely scoping
the applicability of the variable assignment.  So "set" would never set
anything globally, it would be strictly local to some precisely defined
block.  REQUEST.set would still be available for anything that really
needed to be global.  To give an example:

<!--#let-->
code...
<!--#set foo="1"-->
more code...
<!--#set foo="3"-->
still more code..
<!--#set foo="4"-->
etc.
<!--#/let-->

As you can see, actually defining the variables in the let tag itself would
be unnecessary.  Although I've also thought it might be cool to require any
variables you "set" to be defined by the "let", thus allowing a bit more
safety.

You see, one of the other tricky things about allowing "set" (in the
general case), is that it breaks the "untrusted code" model of Zope.  If
method 1, written by user A, calls method 2, written by user B, and method
2 is sneaky and resets a variable used by method 1, then method 2 can
potentially make method 1 do something it ain't supposed to.  (Notice that
setting things in the REQUEST object doesn't have this problem, because
REQUEST is so far down in the namespace stack, AND if you're trying to be
secure, you'll be wary of anything coming from the REQUEST object to begin
with.)  To make a safe "set" tag that deals with this situation requires
more internal Zope Zen than I care to learn at this stage of things,
because the stuff I use DocumentTemplates for doesn't use the Zope's
"untrusted code" model.

But, making "set" only valid inside a "let" block eliminates that problem,
because you can always wrap a call to untrusted code in another let block
so any changes it makes will be thrown away.  Anyway, that's what I have in
mind to implement, I'm open to suggestions as to how it might be done better.