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-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
