[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: Martin Aspeli wrote: Hanno Schlichting wrote: PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Philipp also has some ideas (not too far off completion, I believe) that may remove some of the acquisition intermingling. I'm not sure they'd apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) I still do as I haven't found much time to work on this further. I'm looking for someone to take over my branch (knowledge of Python C API and experience with debugging C code required). I consider this a crucial step in moving forward. Acquisition is really getting in the way now and having the simpler __parent__ API be supported as an alternative in Zope 2 would simplify things a lot -- also in this case. Alas, I'm running out of time and experience with this stuff. :( -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: This is used in getToolByName first and only if the name is not registered it falls back to the old Acquisition-based approach. Then do we even need getToolByInterfaceName()? I guess we do if we want this to be open-ended; essentially, if getToolByInterfaceName() does no checks (like, target provides ICMFTool or something) then this becomes a generic get-and-aq-wrap-any-utility function. That may or may not be a good idea to have. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Philipp von Weitershausen wrote:
> On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
>
> Actually, why dont you keep a simple mapping between existing names and
> interfaces, e.g.:
>
> name2iface = {'portal_catalog': ICatalog,
> 'portal_skins': ISkinTool,
> ...}
>
> and use that in getToolByName? Then *all* of the existing code base
> continues to work, especially if getToolByName does aq wrapping.
> getToolByName('some.dotted.interface.IName') looks silly.
We already have that. It's called _tool_interface_registry and can be
found in CMFCore/utils.py ;)
This is used in getToolByName first and only if the name is not
registered it falls back to the old Acquisition-based approach.
Hanno
___
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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
On 6 Jan 2007, at 23:22 , Martin Aspeli wrote:
Okay, spoke to Philipp on IRC and he asked me to relay his opinions
on some of this:
- CMF tools ought not to depend on acquiring things from 'self' if
at all possible.
- TTW code will need aq contexts for security. However, it makes
sense for getToolBy(Interface)Name() to handle this.
- Non-TTW code probably shouldn't need aq contexts.
- Registering the portal as a utility that can be obtained by
getUtility(IPortalRoot) is pretty good practice; in my estimation,
that should solve all the use cases for utilities where acquisition
is used now and where we're not really after an adapter, view.
- Using component registries would be bad in terms of maintenance;
in my own opinion, aq-wrapping when it may not be needed may lead
to headaches later as well.
Also, in my own opinion, why don't we keep getToolByName() (since
it's so incredibly prevalent) and just let it handle dotted
interface names as well? The chances of a name clash are minute,
and we can at a later stage deprecate the non-dotted names. I say
this because (a) getToolByInterfaceName() is long :) and (b) it's
one more thing to remember and (c) everyone's already using
getToolByName().
Actually, why dont you keep a simple mapping between existing names
and interfaces, e.g.:
name2iface = {'portal_catalog': ICatalog,
'portal_skins': ISkinTool,
...}
and use that in getToolByName? Then *all* of the existing code base
continues to work, especially if getToolByName does aq wrapping.
getToolByName('some.dotted.interface.IName') looks silly.
___
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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Okay, spoke to Philipp on IRC and he asked me to relay his opinions on some of this: - CMF tools ought not to depend on acquiring things from 'self' if at all possible. - TTW code will need aq contexts for security. However, it makes sense for getToolBy(Interface)Name() to handle this. - Non-TTW code probably shouldn't need aq contexts. - Registering the portal as a utility that can be obtained by getUtility(IPortalRoot) is pretty good practice; in my estimation, that should solve all the use cases for utilities where acquisition is used now and where we're not really after an adapter, view. - Using component registries would be bad in terms of maintenance; in my own opinion, aq-wrapping when it may not be needed may lead to headaches later as well. Also, in my own opinion, why don't we keep getToolByName() (since it's so incredibly prevalent) and just let it handle dotted interface names as well? The chances of a name clash are minute, and we can at a later stage deprecate the non-dotted names. I say this because (a) getToolByInterfaceName() is long :) and (b) it's one more thing to remember and (c) everyone's already using getToolByName(). Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: The idea is to use a specialized persistent component registry, that does the needed AQ-wrapping. This will however only give us AQ-wrapped local utilities, whereas those registered with the global component registry wouldn't be wrapped. I think this might be an acceptable trade-off. Are you sure? Does *every* local utility want an aq wrapper? I'm not even sure if tools that are well-written (do not rely on acquiring things from 'self') need to do so except for security when called TTW, in which case getToolBy(Interface)Name will do the trick. Bluntly adding acquisition like this seems like a step in the wrong direction, imho. If we *know* that *every* local utility needs this, then it's a pretty elegant solution. I would like some assurances from Tres, Philipp or others for that, though. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hi Jens, getToolByName on the branch will give you a DeprecationWarning. In light of what we're seeing here, and because there is *so* much third party code using getToolByName(), perhaps a DeprecationWarning (and worse, speedy deprecation) is a bit premature? I don't think we can get rid of getToolByName() for a long time, practically, but new code should be encouraged from using the new utility based lookup. Before that happens, though, this needs to work 100% of the time, without requring client code to play aq tricks. The branch does provide an alternative to getToolByName for untrusted code that I think is close to the whole utility idea. I call it "getToolByInterfaceName" and instead of a tool ID you pass in the interface's dotted name as a string: getToolByName(context, 'portal_actions') would become getToolByInterfaceName(context, 'Products.CMFCore.interfaces.IActionsTool') whereas everything else stays the same, meaning you can pass in a default, and the method will wrap the tool before handing it back. However, instead of AttributeError, this one raises ComponentLookupError, but that decision can always be revisited. So what does this really buy us over, say, a map of tools names to interfaces? Is it (in the short/medium term) really worth spewing warning from tons and tons of code? Now, the main issue is still there, how to deal with tool wrapping when calling getUtility/queryUtility in trusted code. Doing it every time right after the call is stupid. I like Tres' hardline assertion that we must have it wrapped every time, automatically. This needs to be implemented somehow, maybe in Five as he suggests. I'm not quite sure I follow the argument that it must be wrapped every time. I agree that it must for TTW code (page templates, scripts), for security. For other things, we may want instead to rely on the pattern that's been mentioned: use getUtility(ISiteRoot) to get the portal root and don't rely on acquiring attributes (from self in the tool) otherwise. I may not have fully understood the implications of this, though. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: > > Now, the main issue is still there, how to deal with tool wrapping when > calling getUtility/queryUtility in trusted code. Doing it every time > right after the call is stupid. I like Tres' hardline assertion that we > must have it wrapped every time, automatically. This needs to be > implemented somehow, maybe in Five as he suggests. > > How do we proceed? Personally I like Tres idea as well. I had one idea so far that achieves this without monkey-patching the functions in zope.component. The idea is to use a specialized persistent component registry, that does the needed AQ-wrapping. This will however only give us AQ-wrapped local utilities, whereas those registered with the global component registry wouldn't be wrapped. I think this might be an acceptable trade-off. Instead of creating a PersistentComponents registry in setuphandlers.py in CMFDefault (or CMFPlone) we could use the following one: from zope.component.persistentregistry import PersistentComponents from Acquisition import aq_parent, Explicit class Zope2PersistentComponents(Explicit, PersistentComponents): def queryUtility(self, provided, name=u'', default=None): utilities = super(Zope2PersistentComponents, self).queryUtility(provided, name=name, default=default) if utilities is not None: if getattr(utilities, '__of__', None) is not None: return utilities.__of__(aq_parent(self)) return utilities def getUtility(self, provided, name=u''): utility = super(Zope2PersistentComponents, self).getUtility(provided, name=name) if getattr(utility, '__of__', None) is not None: return utility.__of__(aq_parent(self)) return utility I'm not sure about all the implications this has, so treat it with care ;) Also we would probably need to overwrite all the other methods that return utilities like getUtilitiesFor, registeredUtilities, ... and we would need to make a decision about how to handle adapters or subscribers. Thoughts? Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Hanno Schlichting wrote: > >> PhiliKON some time ago suggested that Five should wrap the utilities >> eventually but nobody followed up on that idea. > > Philipp also has some ideas (not too far off completion, I believe) that > may remove some of the acquisition intermingling. I'm not sure they'd > apply here. Yep, he worked on making the Zope 2 security policy aware of the ILocation interface as an alternative to the Acquisition hierarchy IIRC. This is targeted at Zope 2.11 though and last time I asked he still got segfaults ;) >> Ah yep, you are of course right. My main point was probably that it >> shouldn't rely on the request (unless passed in explicitly as a method >> argument). > > And sometimes we have methods that can legitimately take a 'context' > parameter. Quite often, this is because we were really after a view, > though. For example, most of PloneTool.py is a hodge-podge of random > things that were needed in page templates and Script (Python)'s but that > people wanted in filesystem code. That crap has to be refactored completely. The complete Plone tool has to be ripped apart and turned into nice utilities and views... Hanno ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jan 2007, at 21:49, Martin Aspeli wrote: Also, getToolByName remains and is almost certainly the way forward for all TTW code still, because it lets us aq wrap, it removes the need to make all interfaces importable in untrusted code, and it can do any additional security related things. In filesystem code, though, I think the security aspect won't matter in most cases. getToolByName on the branch will give you a DeprecationWarning. The branch does provide an alternative to getToolByName for untrusted code that I think is close to the whole utility idea. I call it "getToolByInterfaceName" and instead of a tool ID you pass in the interface's dotted name as a string: getToolByName(context, 'portal_actions') would become getToolByInterfaceName(context, 'Products.CMFCore.interfaces.IActionsTool') whereas everything else stays the same, meaning you can pass in a default, and the method will wrap the tool before handing it back. However, instead of AttributeError, this one raises ComponentLookupError, but that decision can always be revisited. Now, the main issue is still there, how to deal with tool wrapping when calling getUtility/queryUtility in trusted code. Doing it every time right after the call is stupid. I like Tres' hardline assertion that we must have it wrapped every time, automatically. This needs to be implemented somehow, maybe in Five as he suggests. How do we proceed? jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFoA7bRAx5nvEhZLIRAk0IAJ9FRh3daPcHkEOZknzg0E3DkGdlYQCfQrCt zPpvOs0m2Q/mTMubvknO+Gc= =nsnx -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Hanno Schlichting wrote: > >> Yep, you are wrong ;) > > Fair enough. Out of curiosity, does the object have a __parent__? Nope, not ILocation aware :( > In any case, I think your original suggestion is a good one. Let's take > this opportunity to diagnose the problem and not the symptom: "True" > tools should be singletons and act much like utilities. Stuff like > self.REQUEST is pretty nasty. Maybe some tools will need some internal > cleanup in that respect; my feeling is that in most cases, that cleanup > should be reasonably easy, and where it's not perhaps we wait to put > those methods into the corresponding utility interfaces and think about > using adapters instead. The only question is who does this tool cleanup ;) > As Tres points out, you need aq context for security and in case > something is contained in the tool and needs proper containment > acquisition. portal_factory is such an example. I don't know if > portal_actions would be now as well; portal_types probably too. > > These are not really utilities, though, they are magic singleton > containers for specific things. Whereas a tool that is converted to a > utility may one day be deprecated out of content space, these ones may > not, I don't know. Hhm, ok. So do we expose these tools at utilities now at all? Can we really deprecate getToolByName then? > Also, getToolByName remains and is almost certainly the way forward for > all TTW code still, because it lets us aq wrap, it removes the need to > make all interfaces importable in untrusted code, and it can do any > additional security related things. In filesystem code, though, I think > the security aspect won't matter in most cases. Jens came up with a nice alternative here, which is getToolByInterfaceName. The docstrings reads: """Get a tool by its fully-qualified dotted interface path. This method replaces getToolByName for use in untrusted code. Trusted code should use zope.component.getUtility instead.""" Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Philipp also has some ideas (not too far off completion, I believe) that may remove some of the acquisition intermingling. I'm not sure they'd apply here. Personally I have no clue how Acquisition and security are intermingled in Zope 2, so cannot suggest any reasonable behavior here. Spend some time in AccessControl/ImplPython.py. :) Ah yep, you are of course right. My main point was probably that it shouldn't rely on the request (unless passed in explicitly as a method argument). And sometimes we have methods that can legitimately take a 'context' parameter. Quite often, this is because we were really after a view, though. For example, most of PloneTool.py is a hodge-podge of random things that were needed in page templates and Script (Python)'s but that people wanted in filesystem code. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Hanno Schlichting wrote: Yep, you are wrong ;) Fair enough. Out of curiosity, does the object have a __parent__? In any case, I think your original suggestion is a good one. Let's take this opportunity to diagnose the problem and not the symptom: "True" tools should be singletons and act much like utilities. Stuff like self.REQUEST is pretty nasty. Maybe some tools will need some internal cleanup in that respect; my feeling is that in most cases, that cleanup should be reasonably easy, and where it's not perhaps we wait to put those methods into the corresponding utility interfaces and think about using adapters instead. As Tres points out, you need aq context for security and in case something is contained in the tool and needs proper containment acquisition. portal_factory is such an example. I don't know if portal_actions would be now as well; portal_types probably too. These are not really utilities, though, they are magic singleton containers for specific things. Whereas a tool that is converted to a utility may one day be deprecated out of content space, these ones may not, I don't know. Also, getToolByName remains and is almost certainly the way forward for all TTW code still, because it lets us aq wrap, it removes the need to make all interfaces importable in untrusted code, and it can do any additional security related things. In filesystem code, though, I think the security aspect won't matter in most cases. Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Tres Seaver wrote: > Rocky Burt wrote: >> On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote: >>> Hhm, I'm not sure what the best way is here. Personally I would like to >>> get rid of as much of Acquisition as possible, but obviously we need to >>> be careful here. >> +10 here > > Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and > will remain so for the foreseeable future). Tools-qua-utilities *need* > wrapping in order for Zope2's security machinery to operate. If Five's > "local utility" bits don't arrange to wrap their own registered > utilities (not those gotten by "acquiring" from above), then we need to > change them to do so. Five doesn't do anything special for any utilities for Zope 2. It relies completely on the Zope 3 implementation, which of course doesn't know anything about Acquisition. PhiliKON some time ago suggested that Five should wrap the utilities eventually but nobody followed up on that idea. Personally I have no clue how Acquisition and security are intermingled in Zope 2, so cannot suggest any reasonable behavior here. >>> In the end a utility is defined as something that does not need a >>> context to do it's work. > > You are confusing "context" here -- the utility doesn't need to have an > "adapterish" context, but it *does* need to have "containment" context > -- that is why it is "local" in the first place. Ah yep, you are of course right. My main point was probably that it shouldn't rely on the request (unless passed in explicitly as a method argument). Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Martin Aspeli wrote: > Jens Vagelpohl wrote: > > My concern is just that we need a robust solution that doesn't put too > much onus on the end developer. If I have to do this it's pretty > horrendous: > > >>> mtool = getUtility(IMembershipTool) > >>> mtool = mtool.__of__(context) > >>> # now use mtool > > especially since the errors I get will likely be confusing. I have > learned the hard way that having to understand how acquisition interacts > with your code fully can be painful, and that sometimes the Zope2/Zope3 > divide still forces this on developers. In this case, we need to make it > as hard as possible to make mistakes, or the learning curve will just > shoot up again. > > In fact, I'm not quite sure I understand the full extent of the problem > here, which is why I'm not being more pro-active in offering suggestions. > > Now, I assume we still create the tool objects as > portal['portal_membership'] or whatever, i.e. they are still > SimpleItem's or whatever, so they still have acquisition mixed in. > Presumably, they should also have an aq_parent always, no? > > Then, I assume that on portal setup, we do > registerUtility(provides=IMembershipTool, > component=portal.portal_membership) - that is, we are telling the > persistent local utility registry that we are using the same physical > object (in the ZODB), rather than giving it a factory from which to > create its own object. > > This is what leads to believe there ought to be an aq_parent by > containment, but I guess I may be wrong? Yep, you are wrong ;) A sample session from my local zopectl debug: >>> from Products.CMFPlone.interfaces import ITranslationServiceTool >>> from zope.component import getUtility >>> getUtility(ITranslationServiceTool, context=app.test) >>> getUtility(ITranslationServiceTool, context=app.test).aq_parent Traceback (most recent call last): File "", line 1, in ? AttributeError: aq_parent >>> from Products.CMFCore.utils import getToolByName >>> getToolByName(app.test, 'translation_service') >>> getToolByName(app.test, 'translation_service').aq_chain [, , ] You currently don't get any Acquisition context for utilities if you don't wrap them explicitly: >>> getUtility(ITranslationServiceTool, context=app.test).__of__(app.test).aq_chain [, , ] Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: getToolByName does explicitly wrap, even when using getUtility under the covers where it can. I don't forsee any compatibility problems there. Cool, thanks for clearing that up. The portal as utility is a good idea, I like it. This could be used in many places where a tool itself wants to acquire something, which is usually something else at the portal root. I'm not sure about the user folder implications that you mention. The security machinery may fail if a user originates in a user folder above the portal, which cannot be reached by acquisition anymore. That would of course also be bad; people expect to be able to log in with their root admin username. My concern is just that we need a robust solution that doesn't put too much onus on the end developer. If I have to do this it's pretty horrendous: >>> mtool = getUtility(IMembershipTool) >>> mtool = mtool.__of__(context) >>> # now use mtool especially since the errors I get will likely be confusing. I have learned the hard way that having to understand how acquisition interacts with your code fully can be painful, and that sometimes the Zope2/Zope3 divide still forces this on developers. In this case, we need to make it as hard as possible to make mistakes, or the learning curve will just shoot up again. In fact, I'm not quite sure I understand the full extent of the problem here, which is why I'm not being more pro-active in offering suggestions. Now, I assume we still create the tool objects as portal['portal_membership'] or whatever, i.e. they are still SimpleItem's or whatever, so they still have acquisition mixed in. Presumably, they should also have an aq_parent always, no? Then, I assume that on portal setup, we do registerUtility(provides=IMembershipTool, component=portal.portal_membership) - that is, we are telling the persistent local utility registry that we are using the same physical object (in the ZODB), rather than giving it a factory from which to create its own object. This is what leads to believe there ought to be an aq_parent by containment, but I guess I may be wrong? Martin ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky Burt wrote: > On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote: >> Hhm, I'm not sure what the best way is here. Personally I would like to >> get rid of as much of Acquisition as possible, but obviously we need to >> be careful here. > > +10 here Fuggeddaboudit -- this is Zope2, and acquisition is still crucial (and will remain so for the foreseeable future). Tools-qua-utilities *need* wrapping in order for Zope2's security machinery to operate. If Five's "local utility" bits don't arrange to wrap their own registered utilities (not those gotten by "acquiring" from above), then we need to change them to do so. >> Thinking about it a bit more, I would say, that if you need to aq_wrap a >> tool in order for it to function as expected, you shouldn't really >> register it as a utility in the first place. > > Maybe, maybe not. I would go as far as to say that 75% of the time when > a tool needs an acquisition context, all it really needs it for is to > get to the portal object. From there it can usually do whatever it > wants. Why not clean up the tools a bit so that instead of trying to do > something acquired, it looks up the portal and goes from there instead? > Or maybe that's biting off a bit too much? > > I recently had the problem where in certain circumstances if you're > inside the mutator or accessor of a python property, then aq is not > maintained which prevented me from doing tool lookups that I needed to > do (Plone 2.5 / CMF 1.6). What I ended up doing was calling > getToolByName(zope.app.component.hooks.getSite(), 'sometool'). Of > course if we make getUtility(ISiteRoot) work, we could use that instead > of the zope.app.component.hooks.getSite() rule. Although, I'd love to > see utility lookups from one utility to another just use ISite and note > ISiteRoot as it would make overriding tools in "sub-portals" much > easier. > > >> In the end a utility is defined as something that does not need a >> context to do it's work. You are confusing "context" here -- the utility doesn't need to have an "adapterish" context, but it *does* need to have "containment" context - -- that is why it is "local" in the first place. > Hm... I'm not convinced of this, for me using "local" utilities versus > global utilities is about being able to get to the portal somehow. > Perhaps I'm mis-using local utilities? I don't think so. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFn+/O+gerLs4ltQ4RAm26AKCFWasXbK4htOKfGsQ/N3tZAsSuPACg3KWi LmDHaqjso+cvQVKW93ImZEY= =R+be -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
On Sat, 2007-06-01 at 16:32 +0100, Hanno Schlichting wrote: > Hhm, I'm not sure what the best way is here. Personally I would like to > get rid of as much of Acquisition as possible, but obviously we need to > be careful here. +10 here > Thinking about it a bit more, I would say, that if you need to aq_wrap a > tool in order for it to function as expected, you shouldn't really > register it as a utility in the first place. Maybe, maybe not. I would go as far as to say that 75% of the time when a tool needs an acquisition context, all it really needs it for is to get to the portal object. From there it can usually do whatever it wants. Why not clean up the tools a bit so that instead of trying to do something acquired, it looks up the portal and goes from there instead? Or maybe that's biting off a bit too much? I recently had the problem where in certain circumstances if you're inside the mutator or accessor of a python property, then aq is not maintained which prevented me from doing tool lookups that I needed to do (Plone 2.5 / CMF 1.6). What I ended up doing was calling getToolByName(zope.app.component.hooks.getSite(), 'sometool'). Of course if we make getUtility(ISiteRoot) work, we could use that instead of the zope.app.component.hooks.getSite() rule. Although, I'd love to see utility lookups from one utility to another just use ISite and note ISiteRoot as it would make overriding tools in "sub-portals" much easier. > In the end a utility is defined as something that does not need a > context to do it's work. Hm... I'm not convinced of this, for me using "local" utilities versus global utilities is about being able to get to the portal somehow. Perhaps I'm mis-using local utilities? > Registering tools as utilities that either need > an Acquisition context or even worse the request (think of the evil > self.REQUEST you see sometimes) violates that very definition of what > utilities are. Indeed, using request inside a utility/tool is evil. But > But maybe I'm just in a bit too cautious mood right now ;) It does seem that way ;) Regards, Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jan 2007, at 16:03, Martin Aspeli wrote: I would say it's very bad if we need to train people on when aq- wrapping tools (using __of__() say) is required and when it's not. In fact, I'd say its catastrophic and will break incredible amounts of existing code. If getToolByName() keps aq wrapping, though, then legacy code shouldn't be affected, so it's only new code using getUtility(). getToolByName does explicitly wrap, even when using getUtility under the covers where it can. I don't forsee any compatibility problems there. In this case, we probably need to fix the tools themselves so that they don't depend on being aq-wrapped. Actually, Hanno's suggestion is kind of neat. Let the persistent portal object be a (the only) utility providing ISiteRoot in the local utility registry, and when tools need to get the portal, root, do: portal = getUtility(ISiteRoot) I guess it's rare that we'd want to acquire anything from above the portal in a tool (user folders being the only thing I can think of). The portal as utility is a good idea, I like it. This could be used in many places where a tool itself wants to acquire something, which is usually something else at the portal root. I'm not sure about the user folder implications that you mention. The security machinery may fail if a user originates in a user folder above the portal, which cannot be reached by acquisition anymore. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFn9JfRAx5nvEhZLIRAlZNAJwJPlfjpAGoSi7/xkY4evI05hC8OACfbiiR ihQq3MU3UV0Rg5YstulPJLU= =40oN -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: > > On 6 Jan 2007, at 15:34, Hanno Schlichting wrote: >> I had to change two things in CMF so far though. Here are the patches I >> came up with: > > Thanks Hanno, this is a point I wanted to bring up after getting the > last work done: When using getUtility/queryUtility, I am assuming the > returned utility should always considered to be unwrapped. Because > that's what the unit tests show me. There are several places where CMF > unit tests failed and I ended up manually wrapping the utility where I > retrieved it using __of__, but I'm not sure if I'm expected to do it > that way. It's clear that some tools must be wrapped in order to perform > their function - that's why for example the method I wrote to replace > getToolByName for untrusted code still expects a context to be passed > along and I wrap the utility in it. > > It's just a bit unintuitive that sometimes you must wrap them, sometimes > you don't need to. For a third party coder this could turn into a major > headache and bug bear. Hhm, I'm not sure what the best way is here. Personally I would like to get rid of as much of Acquisition as possible, but obviously we need to be careful here. Thinking about it a bit more, I would say, that if you need to aq_wrap a tool in order for it to function as expected, you shouldn't really register it as a utility in the first place. The forced aq_wrapping is like introducing a new required context argument in a method. You effectively change the methods signature, which shouldn't be done without a deprecation period at least. In the end a utility is defined as something that does not need a context to do it's work. Registering tools as utilities that either need an Acquisition context or even worse the request (think of the evil self.REQUEST you see sometimes) violates that very definition of what utilities are. While I would really love to see getToolByName vanish as fast as possible I'm not sure if we can do this as easily as it first looked. Maybe we could offer those tools as utilities that are real utilities for CMF 2.1 and start rewriting those tools that are really more like adapters as such, removing the tools altogether or splitting them up into utilities and adapter parts. I know this isn't a scenario that would produce major results in the near future considering the number of people that currently contribute to CMF but maybe it's the safer approach. But maybe I'm just in a bit too cautious mood right now ;) Hanno ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote: It's just a bit unintuitive that sometimes you must wrap them, sometimes you don't need to. For a third party coder this could turn into a major headache and bug bear. I would say it's very bad if we need to train people on when aq-wrapping tools (using __of__() say) is required and when it's not. In fact, I'd say its catastrophic and will break incredible amounts of existing code. If getToolByName() keps aq wrapping, though, then legacy code shouldn't be affected, so it's only new code using getUtility(). In this case, we probably need to fix the tools themselves so that they don't depend on being aq-wrapped. Actually, Hanno's suggestion is kind of neat. Let the persistent portal object be a (the only) utility providing ISiteRoot in the local utility registry, and when tools need to get the portal, root, do: portal = getUtility(ISiteRoot) I guess it's rare that we'd want to acquire anything from above the portal in a tool (user folders being the only thing I can think of). We may yet find ourselves in pain in things like Remember or PlonePAS or bits of CMFPlone that override and monkey patch tools, but at least those can be contained. Martin ___ 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
Re: [Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jan 2007, at 15:34, Hanno Schlichting wrote: I had to change two things in CMF so far though. Here are the patches I came up with: Thanks Hanno, this is a point I wanted to bring up after getting the last work done: When using getUtility/queryUtility, I am assuming the returned utility should always considered to be unwrapped. Because that's what the unit tests show me. There are several places where CMF unit tests failed and I ended up manually wrapping the utility where I retrieved it using __of__, but I'm not sure if I'm expected to do it that way. It's clear that some tools must be wrapped in order to perform their function - that's why for example the method I wrote to replace getToolByName for untrusted code still expects a context to be passed along and I wrap the utility in it. It's just a bit unintuitive that sometimes you must wrap them, sometimes you don't need to. For a third party coder this could turn into a major headache and bug bear. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD4DBQFFn7eYRAx5nvEhZLIRAouMAJ4rDlUqxta4tkC0IGIDzk2INNeG5wCVHi6k tGCzE5BwZhM7kJFx5pBB8Q== =t6kR -END PGP SIGNATURE- ___ 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
[Zope-CMF] Re: [CMF 2.1] FSPageTemplate & Unicode
Jens Vagelpohl wrote:
>
> On 6 Jan 2007, at 12:57, Andreas Jung wrote:
>>> On 5 Jan 2007, at 20:51, Andreas Jung wrote:
I finished my work (including some test).
Any objections merging the changes back to the trunk?
>>>
>>> If the tests pass, no. At least from me ;)
>>>
>
>> I merged the changes... hopefully without side-effects :-)
Well see ;) But Plone shouldn't have too many problems with it, as it
monkey-patches the hell out of the Zope3 tal and pagetemplate packages
anyways, as it produces UnicodeDecodeErrors all over the place otherwise.
> Now is the best time, I'm sure Plone 3 testing will give it the best
> workout it can get. I hope to finish my huge checkin (deprecating
> getToolByName and replacing it with utility calls) this weekend.
Regarding your greatly appreciated utilities work, I have tried it with
the current Plone 3 bundle and found various problems. After fixing
various code snippets, I have it in a state where the tests start at
least and we get about 200 errors for the CMFPlone tests.
I had to change two things in CMF so far though. Here are the patches I
came up with:
In DCWorkflow/Expression.py the workflow is not aq-wrapped anymore, so
you cannot call getPhysicalRoot on it anymore. But luckily we can use
the object instead.
The second one is even more important. The URLTool's getPortalObject
method was pretty dumb so far and returned the aq_parent of the tool. As
the tool can get pretty awkward aq_chains now, as getToolByName wraps
the tool inside the callers context, we need a better approach.
The simplest one I came up with is to do an recursive loop and check if
the parent implements ISiteRoot. This should get you the real portal
object. At least with this patch another 300 unit tests pass in CMFPlone
where about 500 failed before.
Another way would potentially be to register the portal object itself as
a utility, so you could query it directly, but that would be a bit of an
extra work...
I'll try to find out what's causing the other test failures in Plone :)
Hanno
Index: Expression.py
===
--- Expression.py (revision 71731)
+++ Expression.py (working copy)
@@ -122,7 +122,7 @@
'container':container,
'folder': container,
'nothing': None,
-'root': wf.getPhysicalRoot(),
+'root': ob.getPhysicalRoot(),
'request': getattr( ob, 'REQUEST', None ),
'modules': SecureModuleImporter,
'user': getSecurityManager().getUser(),
Index: URLTool.py
===
--- URLTool.py (revision 71731)
+++ URLTool.py (working copy)
@@ -24,6 +24,7 @@
from zope.interface import implements
from ActionProviderBase import ActionProviderBase
+from interfaces import ISiteRoot
from interfaces import IURLTool
from interfaces.portal_url import portal_url as z2IURLTool
from permissions import ManagePortal
@@ -74,7 +75,15 @@
def getPortalObject(self):
""" Get the portal object itself.
"""
-return aq_parent( aq_inner(self) )
+portal = aq_inner(self)
+while True:
+portal = getattr(portal, 'aq_parent', None)
+if portal is None:
+break
+if ISiteRoot.providedBy(portal):
+return portal
+# Portal could not be found, log an error or raise one?
+return aq_inner(self)
security.declarePublic('getRelativeContentPath')
def getRelativeContentPath(self, content):
___
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
Re: [Zope-CMF] [CMF 2.1] FSPageTemplate & Unicode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6 Jan 2007, at 12:57, Andreas Jung wrote: On 5 Jan 2007, at 20:51, Andreas Jung wrote: I finished my work (including some test). Any objections merging the changes back to the trunk? If the tests pass, no. At least from me ;) I merged the changes... hopefully without side-effects :-) Now is the best time, I'm sure Plone 3 testing will give it the best workout it can get. I hope to finish my huge checkin (deprecating getToolByName and replacing it with utility calls) this weekend. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFn49VRAx5nvEhZLIRAg1FAJ40sF1m+kXHDB4tlKpeaNpVDTHhtACbB/Pb qSFZBtGB3AWW0931Y3fMVa8= =f/s/ -END PGP SIGNATURE- ___ 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
[Zope-CMF] CMF Tests: 9 OK
Summary of messages to the cmf-tests list. Period Fri Jan 5 12:00:00 2007 UTC to Sat Jan 6 12:00:00 2007 UTC. There were 9 messages: 9 from CMF Unit Tests. Tests passed OK --- Subject: OK : CMF-1.5 Zope-2.7 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:45:52 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003722.html Subject: OK : CMF-1.5 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:47:23 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003723.html Subject: OK : CMF-1.5 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:48:53 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003724.html Subject: OK : CMF-1.6 Zope-2.8 Python-2.3.6 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:50:23 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003725.html Subject: OK : CMF-1.6 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:51:53 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003726.html Subject: OK : CMF-2.0 Zope-2.9 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:53:23 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003727.html Subject: OK : CMF-2.0 Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:54:53 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003728.html Subject: OK : CMF-trunk Zope-2.10 Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:56:23 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003729.html Subject: OK : CMF-trunk Zope-trunk Python-2.4.4 : Linux From: CMF Unit Tests Date: Fri Jan 5 21:57:53 EST 2007 URL: http://mail.zope.org/pipermail/cmf-tests/2007-January/003730.html ___ 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
Re: [Zope-CMF] [CMF 2.1] FSPageTemplate & Unicode
--On 5. Januar 2007 21:22:24 +0100 Jens Vagelpohl <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5 Jan 2007, at 20:51, Andreas Jung wrote: I finished my work (including some test). Any objections merging the changes back to the trunk? If the tests pass, no. At least from me ;) I merged the changes... hopefully without side-effects :-) Andreas pgp0VBlVpAIZs.pgp Description: PGP signature ___ 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
[Zope-CMF] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - "Windows DevelopmentMode penalty in CMFCore.DirectoryView", [Accepted] http://www.zope.org/Collectors/CMF/366 Pending / Deferred Issues - "FSPropertiesObject.py cannot handle multiline input for lines, text attributes", [Deferred] http://www.zope.org/Collectors/CMF/271 - "Can't invalidate skin items in a RAMCacheManager", [Pending] http://www.zope.org/Collectors/CMF/343 - "workflow notify success should be after reindex", [Deferred] http://www.zope.org/Collectors/CMF/389 - "Possible bug when using a BTreeFolder Member folder", [Pending] http://www.zope.org/Collectors/CMF/441 - "Proxy Roles not Working/Applied to Worflow Transition Scripts", [Pending] http://www.zope.org/Collectors/CMF/449 - "safe_html filters some tags which should probably not be filtered", [Pending] http://www.zope.org/Collectors/CMF/452 - "purge_old in runAllImportSteps not working", [Pending] http://www.zope.org/Collectors/CMF/455 - "PUT handling for Events is broken", [Pending] http://www.zope.org/Collectors/CMF/458 - "Danger from Caching Policy Manager", [Pending] http://www.zope.org/Collectors/CMF/460 Pending / Deferred Features - "Favorite.py: queries and anchors in remote_url", [Pending] http://www.zope.org/Collectors/CMF/26 - "DefaultDublinCore should have Creator property", [Pending] http://www.zope.org/Collectors/CMF/61 - "Document.py: universal newlines", [Pending] http://www.zope.org/Collectors/CMF/174 - "portal_type is undefined in initialization code", [Pending] http://www.zope.org/Collectors/CMF/248 - "CMFTopic Does Not Cache", [Deferred] http://www.zope.org/Collectors/CMF/295 - "Wishlist: a flag that tags the selected action.", [Pending] http://www.zope.org/Collectors/CMF/301 - "CMFDefault should make use of allowCreate()", [Pending] http://www.zope.org/Collectors/CMF/340 - "Nested Skins", [Deferred] http://www.zope.org/Collectors/CMF/377 - "CatalogVariableProvider code + tests", [Pending] http://www.zope.org/Collectors/CMF/378 - "manage_doCustomize() : minor additions", [Pending] http://www.zope.org/Collectors/CMF/382 - "CMF needs View-based TypeInformation", [Pending] http://www.zope.org/Collectors/CMF/437 - "Marker attributes should be deprecated", [Pending] http://www.zope.org/Collectors/CMF/440 ___ 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
