-----BEGIN PGP SIGNED MESSAGE-----
Sidnei da Silva wrote:
> (sorry for the cross-post)
> I'm currently facing an issue that seems to be a result of a bad
> interaction between CMF, TALES and Restricted Python.
> The issue currently happens when:
> 1. A TALES 'Path Expression' in 'Caching Policy Manager' is evaluated
> 2. The result of evaluating a sub-expression is a Python Script (eg:
> object/modified where 'modified' is a Python Script)
> 3. The context as built by CMF doessn't define 'here'
> What happens in this case is that the call will end up in
> PageTemplates/ZRPythonExpr.py:call_with_ns, which is reproduced here
> for your pleasure:
> def call_with_ns(f, ns, arg=1):
> td = Rtd()
> td.this = ns['here']
> td._push(InstanceDict(td.this, td))
> if arg==2:
> return f(None, td)
> return f(td)
'call_with_ns' should be invoked only for objects with either a
'__render_with_namespace__' attribute (PythonScripts fit here) or those
with 'isDocTemp' true. Its only real purpose is to set up the namespace
before calling a DTMLMethod; I don't even understand why PythonScripts
have such a method.
I'm guessing that you get to this point via CMFCore.Expression's
__call__ method, which calls a compiled path expression.
> Now, given that there has been a decision of deprecating 'here' in
> favor of 'context', I'm not exactly sure about the fix.
> CMF seems to create expression contexts in two places off the top of
> my head: In 'CMFCore/Expression.py' and
> 'CMFCore/CachingPolicyManager.py'. None of those define 'here' or
> 'context' but instead just 'object'.
> In 'Products/PageTemplates/TALES.py', in the 'translate' function,
> 'here' is also hardcoded, but that should be less of an issue as code
> reaching into that function *should* have a proper expression context.
'here' is *never* the proper key to expect; I would class that a bug.
> The question then is, which code is wrong? PageTemplates for relying
> on 'here' being defined, or CMF for not defining 'here'? I volunteer
> to provide a fix with tests as soon as someone clarifies which one
> needs to be fixed.
The 'call_with_ns' bit is *definitely* the wrong code path for
PythonScripts, which should be simple callables (I think). I think
PythonScripts get their '__render_with_namespace__' attribute by way of
'Shared.DC.Script.Bindings', which is only in order to support a really
*goofy* use case (being able to get at the DTML '_' namespace when it is
bound). I would be willing to bet that *nobody* does this who actually
If we *must* go through that path, then the 'call_with_ns' code needs
to be hardened two ways:
- It should prefer 'context' to 'here' ('here' is deprectated in
- It should be willing to supply 'None' if the 'context'/'here' keys
are not present in the namespace.
> As a reminder, 'actions' as defined by 'portal_actions' tool and
> anything that derives from 'ActionProviderBase' suffer from the same
We could work around the issue in the CMF by supplying a (temporary,
deprecated) 'here' key in the context we create. The problem with Zope
assuming that 'here' or 'context' are mandatory namespace keys is that,
in our case, we have multiple candidates for the role, and therefore
wish to use unambiguous name.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests