RE: DTML<->Python confusion (RE: [Zope] How to make a script return rendered dtml)
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
Bjorn Stabell wrote:
Is it possible to append an object to the namespace? Isn't that what dtml-with does?
It does, but there's some magic involved (non-mapping objects have to be wrapped in an adaptor first) and it uses an interface that isn't available in a restricted code environment such as Scripts.
But the other way around, calling Python functions from DTML (via <dtml-var func>) the positional arguments are gotten from the namespace, right?
Not for just any Python functions, no. For Scripts, yes, *if* you use the Bindings tab of the Script to give a name to the caller's namespace. The reasoning here is that a Script won't do anything with the caller's namespace unless you tell it to. Otherwise you have to use <dtml-var expr="func(x,y,z)"> type notation.
So why do so many DTML methods / documents have REQUEST as an explicit argument? It looks like a convention that has to mean something.
That's just the generic call signature of DTML. If the callee is to have implicit access to the REQUEST, you have to either pass the REQUEST itself or a proper namespace as the second parameter. DTML was never really designed to be called with explicit parameters.
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?
Correct. Acquisition is a complex subject, and a lot has been written about it on Zope.org. When you write "/A/B", "B" could be contained in either "A" or "/" (the root), but its acquisition parent is "A".
Is the namespace stack basically the same as the acquisition path?
Nope. Each Zope object on the namespace stack has its own acquisition wrapper. Fortunately, there usually aren't very many Zope objects on the stack. Cheers, Evan @ digicool
On Thu, 14 Jun 2001, Evan Simpson wrote:
So why do so many DTML methods / documents have REQUEST as an explicit argument? It looks like a convention that has to mean something.
That's just the generic call signature of DTML. If the callee is to have implicit access to the REQUEST, you have to either pass the REQUEST itself or a proper namespace as the second parameter. DTML was never really designed to be called with explicit parameters.
You may know this already, but just in case: there are also a lot of *python* methods that take REQUEST as an explicit argument even though they could get it out of self. In that case it *is* a convention with meaning: if REQUEST is passed, assume you are being called through the web (and possibly return a web page or redirect), otherwise assume a program call and just return. --RDM
participants (3)
-
Bjorn Stabell -
Evan Simpson -
R. David Murray