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.