[Zope-dev] Re: [Zope-CMF] Re: RestrictedPython, TALES Expressions and CMF

[Sidnei da Silva]

On Tue, Oct 11, 2005 at 08:58:08AM -0400, Tres Seaver wrote:
| '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.

That is correct.

| > 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.

Bingo.

| > 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
| needs it.
| 
| 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
|     Zope).
| 
|   - It should be willing to supply 'None' if the 'context'/'here' keys
|     are not present in the namespace.

>From glancing at the code it looks like this is the right thing to
do. I wonder who's the person that gets the last word on that dark
corner of Zope. Would that be Fred?

| > As a reminder, 'actions' as defined by 'portal_actions' tool and
| > anything that derives from 'ActionProviderBase' suffer from the same
| > issue.
| 
| 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.

Yeah, I would like to avoid that one, but considering all Zope
versions out there have the issue, we might need to provide the
temporary fix for a while, to be deprecated in a couple versions.

-- 
Sidnei da Silva
Enfold Systems, LLC.
http://enfoldsystems.com