Re: [Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Previously yuppie wrote: > But the way lookups are delegated to other site managers seems to be > highly optimized and making use of internal apis of five.lsm. So it > might not be possible to fix this in five.lsm, in which case Hanno's > proposal would provide a solution. That is exactly the case. At the moment plone.azax.kss carries a nasty monkeypatch to get things working for us. You can see it at http://dev.plone.org/plone/browser/plone.app.kss/trunk/plone/app/kss/five_lsm_patch.py Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: getToolByName depreciation, getUtility, and five.lsm
Hi! Alec Mitchell wrote: On 4/3/07, yuppie wrote: AFAICS all CMF tool interfaces are valid utility interfaces. The fact they are currently implemented as content space tools is just an implementation detail. Using the utility I don't care how it is implemented. Why should I? All issues reported so far (KSS, GenericSetup) have nothing to do with getUtility not being explicit enough. AFAICS they have to do with the fact that some five.lsm methods return unwrapped tools. Something that has to be fixed. I'm pretty sure this is incorrect. My understanding is that KSS uses a non-five.lsm site manager which is perfectly valid and works in both Zope 2 and 3, but when it needs to delegate utility lookup to a site manager earilier in the traversal chain which is a five.lsm, that delegation breaks. It would be possible to fix this in Zope 3 itself, or as Hanno suggests by essentially monkey-patching Zope 3 so that it was more accepting of unexpected behaviors from 3rd-party site-manager implementations like five.lsm. However, IMO, the better solution is to make five.lsm play nicely with non-five.lsm site managers, which means removing its acquisition magic. I did not debug this, I just did have a quick look at the code. I would be surprised if the KSS site manager removes acquisition wrappers, so the problem is that KSS gets the tools unwrapped. The tools are registered in the five.lsm, therefore five.lsm should be responsible for wrapping them. But the way lookups are delegated to other site managers seems to be highly optimized and making use of internal apis of five.lsm. So it might not be possible to fix this in five.lsm, in which case Hanno's proposal would provide a solution. Of course I might be wrong. A detailed bug report would make it easier to identify the exact problem. Using getUtility instead of getToolByName made life easier. You no longer have to care about which utility is implemented z2-style and which z3-style. And you can write less complex code if you don't have to pass in the context. Right, it's easier because, IMO you are hiding the fact that the tools you are using are context dependent and therefore not properly implemented utilities. Components which require a context to function should be adapters, The term 'context' is used in many different ways. The context required by getToolByName is different from the context required by adapters. It is just used to get the site root by acquisition. Zope 3 utilities also behave different depending on their site 'context'. components which additionally require a request should be views, those that require neither should be utilities. Usually REQUEST is an argument of tool methods and not looked up by acquisition. Cheers, Yuppie ___ 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: getToolByName depreciation, getUtility, and five.lsm
On 4/3/07, yuppie <[EMAIL PROTECTED]> wrote: Hi! Alec Mitchell wrote: > On 4/1/07, yuppie wrote: >> Philipp von Weitershausen wrote: >> > You're suggesting to introduce yet another package that's destined >> to go >> > a way at some point, while the same functionality is already available, >> > it only needs to be un-deprecated... >> >> I don't agree. CMF 2.0's getToolByName() requires context object and >> tool name as arguments, the tool has to be a content space object. >> That's quite different to five.lsm's getUtility(): > > Well you already have a mapping of name to interface that you use for > BBB, and a context is required for acquisition wrapping, even it it's > done implicitly. You can pass a context to a getUtility call too, > that doesn't make the utility live in content space. In this case > using a secondary api for doing the wrapping makes it clear that we > aren't dealing with real utilities here but context-dependent tools, > which the CMF tools still are no matter how we look them up. AFAICS all CMF tool interfaces are valid utility interfaces. The fact they are currently implemented as content space tools is just an implementation detail. Using the utility I don't care how it is implemented. Why should I? All issues reported so far (KSS, GenericSetup) have nothing to do with getUtility not being explicit enough. AFAICS they have to do with the fact that some five.lsm methods return unwrapped tools. Something that has to be fixed. I'm pretty sure this is incorrect. My understanding is that KSS uses a non-five.lsm site manager which is perfectly valid and works in both Zope 2 and 3, but when it needs to delegate utility lookup to a site manager earilier in the traversal chain which is a five.lsm, that delegation breaks. It would be possible to fix this in Zope 3 itself, or as Hanno suggests by essentially monkey-patching Zope 3 so that it was more accepting of unexpected behaviors from 3rd-party site-manager implementations like five.lsm. However, IMO, the better solution is to make five.lsm play nicely with non-five.lsm site managers, which means removing its acquisition magic. ... Using getUtility instead of getToolByName made life easier. You no longer have to care about which utility is implemented z2-style and which z3-style. And you can write less complex code if you don't have to pass in the context. Right, it's easier because, IMO you are hiding the fact that the tools you are using are context dependent and therefore not properly implemented utilities. Components which require a context to function should be adapters, components which additionally require a request should be views, those that require neither should be utilities. ... Alec ___ 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: getToolByName depreciation, getUtility, and five.lsm
Hi! Alec Mitchell wrote: On 4/1/07, yuppie wrote: Philipp von Weitershausen wrote: > You're suggesting to introduce yet another package that's destined to go > a way at some point, while the same functionality is already available, > it only needs to be un-deprecated... I don't agree. CMF 2.0's getToolByName() requires context object and tool name as arguments, the tool has to be a content space object. That's quite different to five.lsm's getUtility(): Well you already have a mapping of name to interface that you use for BBB, and a context is required for acquisition wrapping, even it it's done implicitly. You can pass a context to a getUtility call too, that doesn't make the utility live in content space. In this case using a secondary api for doing the wrapping makes it clear that we aren't dealing with real utilities here but context-dependent tools, which the CMF tools still are no matter how we look them up. AFAICS all CMF tool interfaces are valid utility interfaces. The fact they are currently implemented as content space tools is just an implementation detail. Using the utility I don't care how it is implemented. Why should I? All issues reported so far (KSS, GenericSetup) have nothing to do with getUtility not being explicit enough. AFAICS they have to do with the fact that some five.lsm methods return unwrapped tools. Something that has to be fixed. - You can easily replace z2-style tools by z3-style utilities. getUtility doesn't care about the implementation, just about the interface. We're talking about making getToolByName use getUtility but perform acquisition wrapping using the passed in context so that the tools work and can still be used from restricted code. This benefit is not lost. - You don't have to provide a context object. This makes it easier to write new z3-style code. You still need one, you just get it via implicit magic. The tools all require it still, once they don't there will be no problem with using getUtility for them. It's now possible to write real context-independent z3 code (which is what the KSS stuff was doing when lsm broke it), this implicit context just makes doing so more painful, IMO. Are there other examples besides KSS? The solution Hanno proposed doesn't sound very painful. Using getUtility instead of getToolByName made life easier. You no longer have to care about which utility is implemented z2-style and which z3-style. And you can write less complex code if you don't have to pass in the context. I didn't push for releasing a beta. But I consider a beta release a commitment that we make big changes on the CMF 2.1 branch only if really necessary. Cheers, Yuppie ___ 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: getToolByName depreciation, getUtility, and five.lsm
On 4/1/07, yuppie <[EMAIL PROTECTED]> wrote: Hi! Philipp von Weitershausen wrote: > Hanno Schlichting wrote: >> I would say that all of Acquisition is dark implicit magic and something >> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 >> I also expect the need to make the Zope 3 code Acquisition aware. One >> prime example are browser views, which I need to mix in Acquisition in >> order for them to work. > > But Products.Five.BrowserView hides that particular detail from you, as > much as getToolByName could hide the acquisition detail when looking up > tools. > > You're suggesting to introduce yet another package that's destined to go > a way at some point, while the same functionality is already available, > it only needs to be un-deprecated... I don't agree. CMF 2.0's getToolByName() requires context object and tool name as arguments, the tool has to be a content space object. That's quite different to five.lsm's getUtility(): Well you already have a mapping of name to interface that you use for BBB, and a context is required for acquisition wrapping, even it it's done implicitly. You can pass a context to a getUtility call too, that doesn't make the utility live in content space. In this case using a secondary api for doing the wrapping makes it clear that we aren't dealing with real utilities here but context-dependent tools, which the CMF tools still are no matter how we look them up. - You can easily replace z2-style tools by z3-style utilities. getUtility doesn't care about the implementation, just about the interface. We're talking about making getToolByName use getUtility but perform acquisition wrapping using the passed in context so that the tools work and can still be used from restricted code. This benefit is not lost. - You don't have to provide a context object. This makes it easier to write new z3-style code. You still need one, you just get it via implicit magic. The tools all require it still, once they don't there will be no problem with using getUtility for them. It's now possible to write real context-independent z3 code (which is what the KSS stuff was doing when lsm broke it), this implicit context just makes doing so more painful, IMO. ... Alec ___ 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: getToolByName depreciation, getUtility, and five.lsm
Hi! Philipp von Weitershausen wrote: Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... I don't agree. CMF 2.0's getToolByName() requires context object and tool name as arguments, the tool has to be a content space object. That's quite different to five.lsm's getUtility(): - You can easily replace z2-style tools by z3-style utilities. getUtility doesn't care about the implementation, just about the interface. - You don't have to provide a context object. This makes it easier to write new z3-style code. I prefer the solution proposed by Hanno. Cheers, Yuppie ___ 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: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. I would only be comfortable doing that if we had unit tests for those tools that aren't acquisition-dependent. And by unit test, I mean real unit tests and not a ZopeTestCase. That's the only way we can really be sure that that a tool can function as a utility, an independent component, w/o acquisition. Not knowing the codebase, I suspect that this isn't the case and suggest using getToolByName for all right now and adding such tests to the TODO list for the next CMF release. -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: getToolByName depreciation, getUtility, and five.lsm
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. and if understand correctly, this is an artefact of views needing to abide by traversal and security. Any tool that does not expressly need security can probably do without acquisition(unless it has code depending on using aquisition for look ups). But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... +1 for removing the "across-the-board" deprecation of 'getToolByName'; I find Kapil's argument convincing here. I think leaving the deprecation for the case where the API has to fall back to raw acquisition to find the tool is pretty reasonable, as it shows the user where the missing registrations are in her site. I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. +1 to undeprecating and slimming lsm. but to echo tres, only the roll back the calls you really have to. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - "If you don't know where you are, you don't know anything at all" Dr. Edgar Spencer, Ph.D., 1995 ___ 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: getToolByName depreciation, getUtility, and five.lsm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: > Hanno Schlichting wrote: >> I would say that all of Acquisition is dark implicit magic and something >> I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 >> I also expect the need to make the Zope 3 code Acquisition aware. One >> prime example are browser views, which I need to mix in Acquisition in >> order for them to work. > > But Products.Five.BrowserView hides that particular detail from you, as > much as getToolByName could hide the acquisition detail when looking up > tools. > > You're suggesting to introduce yet another package that's destined to go > a way at some point, while the same functionality is already available, > it only needs to be un-deprecated... +1 for removing the "across-the-board" deprecation of 'getToolByName'; I find Kapil's argument convincing here. I think leaving the deprecation for the case where the API has to fall back to raw acquisition to find the tool is pretty reasonable, as it shows the user where the missing registrations are in her site. I'm not sure what impact that would have for the already-converted code which used to use the API. I can see value both in leaving it converted, as showing the Zope3-ish way, as well as in reverting some or all of it. For instance, perhaps we should consider reverting just those changes which look up acquisition-dependent tools, since the call site has now become required to manage the wrapper itself. 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 iD8DBQFGC9TO+gerLs4ltQ4RAjNNAJ9UsTpKulDZqns+yrjyDHuslsqaqACfR8El RcwOrIOhyedU+O90JjOgl84= =bCSl -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: getToolByName depreciation, getUtility, and five.lsm
Hanno Schlichting wrote: I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. But Products.Five.BrowserView hides that particular detail from you, as much as getToolByName could hide the acquisition detail when looking up tools. You're suggesting to introduce yet another package that's destined to go a way at some point, while the same functionality is already available, it only needs to be un-deprecated... -- http://worldcookery.com -- Professional Zope documentation and training ___ 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: getToolByName depreciation, getUtility, and five.lsm
Hi, I'll just offer one alternative solution for disussion, which could avoid reverting all the changes we made. Kapil Thangavelu wrote: > We believe that these recent changes have introduced implicit magic into > a standard Zope3 api to fit Zope2 acquisition. There should be an > explicit separate api if we want acquisition wrapped context-aware > utilities. As an example of a symptom caused by the implicit > implementation, KSS (which was developed as a pure zope 3 component) > breaks when used with Plone, even though it is a perfectly valid z3 > component. Once we return to using getToolByName for tool lookup, the > KSS/Plone3 issue disappears, because the magic wrapping of things stops. > This KSS/Plone3 issue arises because the five.lsm acquisition breaks > down when you add in non five.lsm component registries. If you need > Zope2 acquisition, you should use an accessor api to get things wrapped. I would say that all of Acquisition is dark implicit magic and something I expect when developing in Zope 2. When using Zope 3 concepts in Zope 2 I also expect the need to make the Zope 3 code Acquisition aware. One prime example are browser views, which I need to mix in Acquisition in order for them to work. From my perspective the same could apply to site managers / component registries. As we already need to make a specialized subclass for local site managers to make them work in Zope 2 I think it would be another possibility to enforce the same for non-persistent site managers. This could lead us to a second package five.sitemanager that is aware of the same kind of Acquistion wrapping that five.lsm implies right now. The monkey patches we need right now could go away and KSS could do a conditional import of the site manager from zope.component or five.sitemanager if it is found. > In addition, getToolByName is the most fundamental and widely used api > in all of CMF, and we're going to be issuing hundreds of deprecating > warnings for every single cmf application extant. Yes, and I think in order to move forward and someday be able to remove tools from content space, not to mention not to enforce beginners to learn about yet another CMF-ism named tools, we need to be prepared to make some more intrusive changes sometimes. > As a solution, we propose > > * The five.localsitemanager code should *NOT* be dealing with > acquisition, it should be restricted to setting up a bases chain for > persistent components that does parent lookup. > > * getToolByName deprecation should be reverted. Its internal mechanisms > should be kept the same as in the current CMF 2.1 release, using > getUtility, *AND* it should be the one doing acquisition wrapping. > > So instead of doing implicit magic in the getUtility call stack, let's > be explicit, while still allowing the flexibility that registered > components provide. Which in turn results in an untouched zope3 > getUtility execution path for looking up utilities. > > getToolByName should return acquisition wrapped utilities via name > mapping, and become un-deprecated. Context for wrapping would be the > context passed as an argument to getToolByName, as it always has been. > It would issue deprecation warnings when it has to lookup a tool via > aq_get instead of getUtility. The mechanism for registering tool names > would raise an error when anyone tries to register a component which > does not support Acquisition. > > The getToolByInterfaceName method would no longer be necessary as > getToolByName can be called from restricted code. However if needed it > could remain and use the result of getSite() as the context for wrapping > the tool resulting from the utility lookup. In my alternative we would just need to add a little new package which is mostly a copy/paste job, change KSS to do an conditional import (so it still works in pure Zope 3) and document the change. Looking at Zope 2.11 we will potentially get Acquisition through __parent__ pointers which would allow us to make the implementation of five.sitemanger a lot saner and ultimately allow us to remove it again altogether. > We don't mean to belittle the hard work that anyone has put into this so > far, and we hope this is received in the spirit that it is intended. We > are willing to implement this if we can reach some consensus that this > is the right thing to do. All I'm interested in is a proper solution. Should that imply reverting lots of things I have done it would be unfortunate but obviously the right thing to do :) 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: getToolByName depreciation, getUtility, and five.lsm
Martin Aspeli wrote: We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. +1 The one thing I don't see here explicitly is the forward migration path. Make tools not depend on acquisition and you get can start looking them up using getUtility. This will take time, so I'd be ok if for now we can't use getUtility right away (unless you're willing to do manual __of__ing) I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. At least new stuff can be Zope 3-style already. I suspect that all context-less tools today could be rewritten to be regular global utilities, Absolutely. and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). Well, ideally we'll be able to model containment relationships using __parent__ in Zope 2 as well... However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). I can say from personal experience that deprecating less in more time is easier on the people and on yourself :). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: >>> from Products.CMFCore.interfaces import IWorkflowTool >>> from zope.component import getUtility >>> wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. (Welcome to Acquisition!) Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. getToolByName sounds like a sensible abstraction, don't you think? We don't mean to belittle the hard work that anyone has put into this so far, and we hope this is received in the spirit that it is intended. We are willing to implement this if we can reach some consensus that this is the right thing to do. This is the part of the email I like the most :) It's a bit scary to have to revert the hundreds of changes that have been made to the Plone 3.0 codebase and probably hundreds more to the CMF codebase to move to getUtility, th
[Zope-CMF] Re: getToolByName depreciation, getUtility, and five.lsm
Kapil Thangavelu wrote: A few of us (Alec Mitchell, Godefroid Chapelle, Balazs Ree, Rocky Burt, Daniel Nouri, Rob Miller, Vincenzo Di Somma, and myself) have been discussing this in depth at the Sorrento Sprint. We've reached consensus on how we hope to resolve the issues arising from the recent introduction of five.localsitemanager and the deprecation of getToolByName. We believe that these recent changes have introduced implicit magic into a standard Zope3 api to fit Zope2 acquisition. There should be an explicit separate api if we want acquisition wrapped context-aware utilities. As an example of a symptom caused by the implicit implementation, KSS (which was developed as a pure zope 3 component) breaks when used with Plone, even though it is a perfectly valid z3 component. Once we return to using getToolByName for tool lookup, the KSS/Plone3 issue disappears, because the magic wrapping of things stops. This KSS/Plone3 issue arises because the five.lsm acquisition breaks down when you add in non five.lsm component registries. If you need Zope2 acquisition, you should use an accessor api to get things wrapped. In addition, getToolByName is the most fundamental and widely used api in all of CMF, and we're going to be issuing hundreds of deprecating warnings for every single cmf application extant. As a solution, we propose * The five.localsitemanager code should *NOT* be dealing with acquisition, it should be restricted to setting up a bases chain for persistent components that does parent lookup. * getToolByName deprecation should be reverted. Its internal mechanisms should be kept the same as in the current CMF 2.1 release, using getUtility, *AND* it should be the one doing acquisition wrapping. So instead of doing implicit magic in the getUtility call stack, let's be explicit, while still allowing the flexibility that registered components provide. Which in turn results in an untouched zope3 getUtility execution path for looking up utilities. getToolByName should return acquisition wrapped utilities via name mapping, and become un-deprecated. Context for wrapping would be the context passed as an argument to getToolByName, as it always has been. It would issue deprecation warnings when it has to lookup a tool via aq_get instead of getUtility. The mechanism for registering tool names would raise an error when anyone tries to register a component which does not support Acquisition. The getToolByInterfaceName method would no longer be necessary as getToolByName can be called from restricted code. However if needed it could remain and use the result of getSite() as the context for wrapping the tool resulting from the utility lookup. These are good arguments, I think. I'm not sure anyone quite could've predicted the trouble we had with five.lsm (is it even needed anymore if all of this is acted upon?), so it's good to get some fresh thinking on this. The one thing I don't see here explicitly is the forward migration path. I think it would be worthwhile to work towards a future where we have no tools or other programmer-support-mechanisms in content space. I suspect that all context-less tools today could be rewritten to be regular global utilities, and all persitence-needing tools could be changed to be standard local utilities that if needed did getUtility(ISiteRoot) to get hold of the site root and acquire things from there (except, how does the site root then get an acquisition context? Maybe it doesn't need to?). However, if we still promote and use getToolByName() then people will not start using getUtility() and importing interfaces and we will find it more difficult to deprecate (eventually) and then move to a world where we can have real utilities (where possible/sensible). Going back to square one, the reason why we (and I'm very guilty in this) pushed for something at the framework level (spawning five.lsm) was that originally we ended up with calling code needing to do: >>> from Products.CMFCore.interfaces import IWorkflowTool >>> from zope.component import getUtility >>> wftool = getUtility(IWorkflowTool).__of__(context) Such explicit wrapping is black magic voodoo to most people and would probably lead to lots of hard-to-debug errors. Requiring people to know *when* to wrap and when it's not necessary is tantamount to requiring them to know the implementation details of each tool. I would agree, though, that it's not worth "breaking" the way local component registries work in Zope 3 by imposing arbitrary acquisition on them if that is indeed what we're doing. I don't think it was anyone's intention to do so, and the five.lsm implementation was never 100% finished was it? One thing I'd like to ask, is that someone asks Philipp (I've CC'd him, since I know he's not reading lists in detail right now) for comment, since he as usual had various useful insights into the origina
