[Zope-dev] Re: DTML<->Python confusion (RE: [Zope] How to make a script return rendered dtml)

[Evan Simpson]

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