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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests