[Zope] Defining variables

[Alexander Staubo]

Sounds good to me. Great, in fact. Bring it on!

--
Alexander Staubo             http://www.mop.no/~alex/
"He could open a tin of sardines with his teeth, strike a Swan Vestas
on his chin, rope steers, drive a steam locomotive and hum all the
works of Gilbert and Sullivan without becoming confused or breaking
down in tears."
--Robert Rankin, _The Book of Ultimate Truths_

>-----Original Message-----
>From: Phillip J. Eby [mailto:pje@telecommunity.com]
>Sent: 14. juli 1999 01:54
>To: Alexander Staubo; Zope Mailing List (E-mail); 'Brian Lloyd'
>Subject: RE: [Zope] Defining variables
>
>
>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.
>