Certain objects, such as DTML Methods, use namespaces to look up other objects. A namespace is like a stack of address books. To find someone, you look for their name in the top address book on the stack, then the next, until either you find the name or run out of books. You can write names in a new address book and put it on top of the stack, or take one off the top and throw it away.

When one object that uses namespaces calls another one, it usually passes the namespace along. The callee is a namespace user if it has the attribute "isDocTemp" set to a true value. An example of this magic:

<dtml-var subdoc>

If subdoc has the isDocTemp attribute set, which all DTML methods do, it will be called with two arguments: None and the current namespace. Therefore, the above magic is equivalent to the following:

<dtml-var expr="subdoc(_.None, _)">

This "overloading" of the act of calling a method has two drawbacks:

1. A method cannot detect whether it has been called this way

2. The fixed-parameter namespace call has to share implementation with the explicit call signature of the method.

This can be fixed fairly simply, as follows:

• After checking "isDocTemp", check attribute __render_with_namespace__. If it exists, call it instead of the object, passing the namespace as the single argument.

• Implement __render_with_namespace__ in cDocumentTemplate.c.

This change would add one attribute lookup to methods which already have isDocTemp set, and would optimize the common case of calling DTML Methods from DTML Methods without explicit parameters. We would have further reason, as if we needed any, to deprecate DTML like:

  <dtml-var expr="foo(_.None, _, found_thing=_[_[ 'sequence-item' ]])">

in favor of:

  <dtml-let found_thing-name-name="sequence-item">&dtml.-foo;</dtml-let>

Amos 8/31

This seems reasonable in general. Less magic is good magic. Maybe we should change isDocTemp while were at it. Or better yet having a __render_with_namespcae__ method is enough; if you have that method you don't need isDocTemp. Note, on your example, the second way to do things currently works so this proposal doesn't change much from the perspective of the DMTL programmer.