Wow, thanks Evan. I should've asked these questions a long time ago... From: Evan Simpson [mailto:evan@digicool.com]
From: "Bjorn Stabell" <bjorn@exoweb.net>
How do you do dtml-with and dtml-let in a Python script? (I.e. put something on the namespace)
You can't. Scripts can use the DTML namespace in the same way that Python expressions in DTML can, but that's it.
On the other hand, you can create (and pass along) all the local variables you want.
Is it possible to append an object to the namespace? Isn't that what dtml-with does?
How do you give positional (not keyword) arguments to a DTML method; is there any difference?
Keyword arguments are put on top of the namespace. You can't use positional arguments, except the standard (None, _) idiom. DTML was never meant to pass arguments around, that's what the namespace is for, for what that's worth :-P
But the other way around, calling Python functions from DTML (via <dtml-var func>) the positional arguments are gotten from the namespace, right? [... good andswer to __call__ et al deleted :) ... ]
When does RESPONSE need to be passed; it can always be gotten from the REQUEST, right?
Right.
So why do so many DTML methods / documents have REQUEST as an explicit argument? It looks like a convention that has to mean something.
Are namespace, _, REQUEST, and context just different names for the same thing?
Not quite. The namespace, accessible in DTML as "_", is a pile of objects. The REQUEST is a particular object created by ZPublisher to hold information about the request, such as form variables and URL information. The context (or client, for DTML) is the object on which the method was called. If the DTML Method is the target of the request, or if you pass a client as the first argument when calling it, the Method pushes it onto the namespace. Also, the context (like any other Zope object) is acquisition wrapped. The ultimate acquisition parent of any publsihed object is a special wrapper for REQUEST. All this means that when you ask the namespace for the name "foo", it will end up looking for it in the context, in the context's containers all the way to the root, and the REQUEST.
I am a little bit confused about the fact that the acquisition path is related to how the document was called, not just to the containment relationships it is involved in. Or is it? myobj.aq_parent isn't necessarily the object that contains myobj? Is the namespace stack basically the same as the acquisition path? Bye, -- Bjorn