[Zope-CMF] Re: [dev] five.localsitemanager: proposal
Charlie Clark wrote: Am 23.06.2007 um 14:53 schrieb yuppie: There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Taking you up on the *any* feedback thing. I have a skin script that uses the portal_catalog traditionally via getToolByName. I don't know how to use getUtility from within a script but getToolByComponentName raises Error Type: ComponentLookupError Error Value: ICatalogTool As I don't like getting deprecation errors I've changed tack and have moved to context.portal_catalog... Please don't do that. For the tools in the list quoted above getToolByName is your best choice, at least for now. I just removed the misleading deprecation warning from the trunk. (This was already done on the 2.1 branch, but never forward ported.) 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: [dev] five.localsitemanager: proposal
Previously yuppie wrote: Charlie Clark wrote: Am 23.06.2007 um 14:53 schrieb yuppie: There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Taking you up on the *any* feedback thing. I have a skin script that uses the portal_catalog traditionally via getToolByName. I don't know how to use getUtility from within a script but getToolByComponentName raises Error Type: ComponentLookupError Error Value: ICatalogTool As I don't like getting deprecation errors I've changed tack and have moved to context.portal_catalog... Please don't do that. For the tools in the list quoted above getToolByName is your best choice, at least for now. And there are situations where getToolByName may work when plain acquisition does not if you have nested acquisition chains. 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: [dev] five.localsitemanager: proposal
Hi! Hanno Schlichting wrote: yuppie wrote: Wichert Akkerman wrote: Previously yuppie wrote: MembershipTool depends on acl_users MemberDataTool, RegistrationTool, DiscussionTool and CachingPolicyManager depend on MembershipTool From what I can see in the Plone tests it won't be possible in any sane way to let the user related tools to be utilities. At least for CMF 2.1 I think an approach trying to distinguish between safe and unsafe methods is too risky and we should move those back to pure tools. Ok. I'll revert the tools-as-utilities changes for these tools as well. Should be finished this evening. So far I tried to decide which tool depends on self.REQUEST and which not. Maybe we need a more fine grained approach: MembershipTool doesn't depend on all methods of acl_users, not all user folder methods depend on self.REQUEST. IStandardUserFolder has not all the methods, but an interface that adds _doAddUser(), getUserById() and userFolderDelUsers() should be sufficient. Maybe that set of methods specified by a user folder utility interface doesn't depend on self.REQUEST. If that doesn't work, we can try the same with the MembershipTool: If not all methods of IMembershipTool work without self.REQUEST, we still can use a subset IMembershipUtility. I would suggest we try this approach on the CMF trunk but revert to tools-only for those tools for CMF 2.1. We can discuss the roadmap for converting tools to utilities later. At the moment I just want to make sure five.lsm can be tested extensively and declared 'ready for production'. 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: [dev] five.localsitemanager: proposal
Am 26.06.2007 um 08:42 schrieb yuppie: Please don't do that. For the tools in the list quoted above getToolByName is your best choice, at least for now. I just removed the misleading deprecation warning from the trunk. (This was already done on the 2.1 branch, but never forward ported.) Thanks for the clarification. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: [dev] five.localsitemanager: proposal
yuppie wrote: Hi Hanno! Hanno Schlichting wrote: Starting any Plone tests will give an AttributeError on self.adapters in the subscribers method of zope.component.registry. The registry is actually the one from five.lsm and is found via the zope.app.component.hooks.SiteInfo container. In there it is available as the sm property, but it indeed at that point lacks the adapters attribute. It looks like _init_registries is never called. But when I overwrite the set method on SiteInfo every time a new sm is set, it has the right adapters. Strange. five.lsm is just messing around with 'utilities', not with 'adapters'. 'adapters' should work exactly the same way as in a pure z3 site manager. Can't see how the latest five.lsm changes could cause that problem. Me neither :( But as said the sitemanager I get back, though it is the one from five.lsm, has neither an adapters nor utilities or name set. I didn't have time to test this properly but maybe this gives somebody else an idea who wants to look at it... What's your testing environment? https://svn.plone.org/svn/plone/bundles/3.0/EXTERNALS.txt uses r76995 of CMF and https://svn.plone.org/svn/plone/bundles/3.0-lib/five/EXTERNALS.txt uses five.localsitemanager/trunk I use https://svn.plone.org/svn/plone/ploneout/trunk and updated CMF to the HEAD revision. Which is pretty much identical to the above bundles. I expect you can get Plone running with CMF 2.1 branch HEAD and the old five.lsm, but not with the five.lsm trunk and r76995 of CMF. Haven't actually tried that. Good point. Are you using a KSS version without monkey patch? I tried with both with and without the KSS monkey but it doesn't seem to have any effect. 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: [dev] five.localsitemanager: proposal
Am 23.06.2007 um 14:53 schrieb yuppie: This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Taking you up on the *any* feedback thing. I have a skin script that uses the portal_catalog traditionally via getToolByName. I don't know how to use getUtility from within a script but getToolByComponentName raises Error Type: ComponentLookupError Error Value: ICatalogTool As I don't like getting deprecation errors I've changed tack and have moved to context.portal_catalog... I've just been through most of the e-mails on this subject and I didn't end up feeling much the wiser except that the idea to move to utilities doesn't seem to be as smooth as initially envisioned. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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: [dev] five.localsitemanager: proposal
Hi. I meanwhile managed to fix the issue that prevented all tests from running and now the Plone 3.0 bundles use the head revision of the CMF 2.1 branch and five.lsm trunk again. I have started to fix all the problems that have shown up now. We have some custom tools for which I needed to remove the utility registrations as those depended on self.REQUEST. yuppie wrote: Wichert Akkerman wrote: Previously yuppie wrote: MembershipTool depends on acl_users MemberDataTool, RegistrationTool, DiscussionTool and CachingPolicyManager depend on MembershipTool From what I can see in the Plone tests it won't be possible in any sane way to let the user related tools to be utilities. At least for CMF 2.1 I think an approach trying to distinguish between safe and unsafe methods is too risky and we should move those back to pure tools. So far I tried to decide which tool depends on self.REQUEST and which not. Maybe we need a more fine grained approach: MembershipTool doesn't depend on all methods of acl_users, not all user folder methods depend on self.REQUEST. IStandardUserFolder has not all the methods, but an interface that adds _doAddUser(), getUserById() and userFolderDelUsers() should be sufficient. Maybe that set of methods specified by a user folder utility interface doesn't depend on self.REQUEST. If that doesn't work, we can try the same with the MembershipTool: If not all methods of IMembershipTool work without self.REQUEST, we still can use a subset IMembershipUtility. I would suggest we try this approach on the CMF trunk but revert to tools-only for those tools for CMF 2.1. I'm optimistic these issues can be resolved one way or the other. But I don't want to spend more time on this before five.localsitemanager is better tested. I hope the current state of the CMF 2.1 branch is sufficient for testing five.localsitemanager with Plone and KSS. Real world testing showed dozens of test failures and an almost unusable live instance. I have meanwhile managed to fix quite a bunch of issues so we you can at least create and view a Plone instance again, but the number of failures showing up on the console due to missing REQUEST variables in various tools prevents us from doing anything useful. 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: [dev] five.localsitemanager: proposal
Hanno Schlichting wrote: ToDo: - - real world testing My testing of Plone 3.0 after the merge so far results in all integration tests failing with that stupid error inside the component registry when it throws an AttributeError on 'adapters'. The error happened a few times already, but I'm too tired to figure out right now why it is failing this time. I looked a bit deeper into this and still cannot figure out what exactly is going wrong. Starting any Plone tests will give an AttributeError on self.adapters in the subscribers method of zope.component.registry. The registry is actually the one from five.lsm and is found via the zope.app.component.hooks.SiteInfo container. In there it is available as the sm property, but it indeed at that point lacks the adapters attribute. It looks like _init_registries is never called. But when I overwrite the set method on SiteInfo every time a new sm is set, it has the right adapters. Now the event that is fired is the EndRequestEvent during the late steps of PloneTestCase's SiteSetup. What I suspect is that the five.lsm is already partially removed at the point the event is fired and thus does not have an adapters argument anymore. But my knowledge of the actual inner workings of the ZODB transaction machinery is very limited. The code in PloneTestCase.setup.SiteSetup looks like this: def run(self): self.app = self._app() try: [... does the setup ...] finally: self._abort() self._close() self._logout() self._placefulTearDown() The event is fired during self._close() and self._abort essentially does transaction.abort(). I didn't have time to test this properly but maybe this gives somebody else an idea who wants to look at it... 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: [dev] five.localsitemanager: proposal
Hi! This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow These 15 CMF tools are registered as utilities, AFAICS only the security machinery uses their acquisition context (except for portal_membership, which uses 'self.acl_users'): Products.CMFActionIcons.interfaces.IActionIconsTool Products.CMFCore.interfaces.ICachingPolicyManager Products.CMFCore.interfaces.IDiscussionTool Products.CMFCore.interfaces.IMemberDataTool Products.CMFCore.interfaces.IMembershipTool Products.CMFCore.interfaces.IMetadataTool Products.CMFCore.interfaces.IPropertiesTool Products.CMFCore.interfaces.IRegistrationTool Products.CMFCore.interfaces.ISiteRoot Products.CMFCore.interfaces.ISyndicationTool Products.CMFCore.interfaces.IUndoTool Products.CMFUid.interfaces.IUniqueIdAnnotationManagement Products.CMFUid.interfaces.IUniqueIdGenerator Products.GenericSetup.interfaces.ISetupTool Products.MailHost.interfaces.IMailHost five.localsitemanager now returns wrapped utilities without RequestContainers. This requires a new LookupClass. ToDo: - - real world testing - backport to the CMF 2.1 branch - write migration code for CMF 2.1 beta sites that replaces the LookupClass and removes some utility registrations - fix the GenericSetup handler - figure out if we can make acl_users an utility - in the long run, modify all tools to make them work as utilities AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. 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: [dev] five.localsitemanager: proposal
yuppie wrote: Hi! This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Thanks ! snip AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Cheers, Yuppie I tried to test your code this evening... This implied starting to fix Archetypes and Plone to work with all the changes made in CFMCore.interfaces I must say I stopped when I found out IExtensibleMetadata is now a Z3 interface where code in Archetypes still awaits it to be a Z2 interface. I am ready to move on if someone can tell me the pattern to migrate calls like if not IExtensibleMetadata.isImplementedByInstancesOf(klass) interface I currently do not know the dance to move from Z2 to Z3 interfaces. However, I wonder if all the changes needed to run Plone 3 above CMF/trunk won't avoid us to actually test the new code... -- Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be ___ 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: [dev] five.localsitemanager: proposal
Hi Yuppie, This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Well done - great work! :) Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Are these registered as utilities as all? Or only available using getToolByName? These 15 CMF tools are registered as utilities, AFAICS only the security machinery uses their acquisition context (except for portal_membership, which uses 'self.acl_users'): Products.CMFActionIcons.interfaces.IActionIconsTool Products.CMFCore.interfaces.ICachingPolicyManager Products.CMFCore.interfaces.IDiscussionTool Products.CMFCore.interfaces.IMemberDataTool Products.CMFCore.interfaces.IMembershipTool Products.CMFCore.interfaces.IMetadataTool Products.CMFCore.interfaces.IPropertiesTool Products.CMFCore.interfaces.IRegistrationTool Products.CMFCore.interfaces.ISiteRoot Products.CMFCore.interfaces.ISyndicationTool Products.CMFCore.interfaces.IUndoTool Products.CMFUid.interfaces.IUniqueIdAnnotationManagement Products.CMFUid.interfaces.IUniqueIdGenerator Products.GenericSetup.interfaces.ISetupTool Products.MailHost.interfaces.IMailHost five.localsitemanager now returns wrapped utilities without RequestContainers. This requires a new LookupClass. Interesting. Do we still get deprecation warnings if these are looked up using getToolByName? My feeling is that we should *not* get deprecating warnings for these. It's rather late in the day for this release to officially deprecate such fundamental parts of CMF, and I fear that people won't be able to remember which tools are now utilities and which ones are tools, since the distinction really comes down to implementation detail. Hopefully, the path forward is that *all* the tools become utilities (your last to-do below). In that case, I think full deprecation of lookup via getToolByName makes sense, since we have a uniform API (getUtility()) for looking up CMF's fundamental components. Until then, I think we should give people the choice on the utilities we still have, but not prod them too hard. ToDo: - - real world testing - backport to the CMF 2.1 branch Is this in the pipeline? i.e. will this code land in Plone 3.0? :-) - write migration code for CMF 2.1 beta sites that replaces the LookupClass and removes some utility registrations Plone will likely need the same migrations. - fix the GenericSetup handler How so? - figure out if we can make acl_users an utility Spooky... - in the long run, modify all tools to make them work as utilities Yes - as per above, I think this needs to be the ultimate goal. AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. Great - this is really wonderful news. Martin -- Acquisition is a jealous mistress ___ 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: [dev] five.localsitemanager: proposal
Hi. Martin Aspeli wrote: Hi Yuppie, This proposal is now implemented on CMF and five.localsitemanager trunk. Everything *seems* to work, but maybe I'm missing something. This might be a good time to review and test the changes - any feedback is welcome. Well done - great work! :) Done: - There are 10 tools in CMF that are not ready for being used as utilities, they have to be used the old way until they are fixed: content_type_registry cookie_authentication portal_actions portal_calendar portal_catalog portal_skins portal_types portal_uidhandler portal_url portal_workflow Are these registered as utilities as all? Or only available using getToolByName? They are not utilities, so they are not registered as ones. Only available through good old getToolByName :) ToDo: - - real world testing My testing of Plone 3.0 after the merge so far results in all integration tests failing with that stupid error inside the component registry when it throws an AttributeError on 'adapters'. The error happened a few times already, but I'm too tired to figure out right now why it is failing this time. - backport to the CMF 2.1 branch Is this in the pipeline? i.e. will this code land in Plone 3.0? :-) I just did the backport. One test fails in pure CMF 2.1. I was so evil and commented it out. The test is in CMFCore/test/test_SkinsTool and is named test_getCurrentSkinName. I marked it with a XXX comment. Yvo could you look at it, I didn't quite understand all the skins related changes? - fix the GenericSetup handler How so? There's not only an open bug report in the CMF collector, but I also still have a mail in my inbox with all the changes we agreed on a while back... once the latest changes have proven to be stable, I'll get right to it. 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: [dev] five.localsitemanager: proposal
Godefroid Chapelle wrote: yuppie wrote: snip AFAICS, KSS will no longer need the monkey patch if it sets the LookupClass to FiveVerifyingAdapterLookup. I tried to test your code this evening... This implied starting to fix Archetypes and Plone to work with all the changes made in CFMCore.interfaces I backported all the changes and adjusted it accordingly, so you can test the code against Plone without adjusting Plone to CMF trunk. Beware that there still seem to be some general issues. As noted on the other mail, all integration tests currently fail :( But help in fixing those is most welcome ;) 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: [dev] five.localsitemanager: proposal
Hi, yuppie wrote: Yesterday I tried to do my homework from the CMF-mini-sprint in Potsdam. I reread the tools-as-utilities discussion and had again a closer look at the code. In Potsdam we decided to wrap persistent utilities with a complete acquisition context. But now I think this would be a mistake, so instead if implementing this I wrote a new proposal. A complete acquisition chain usually contains the REQUEST object. This makes it impossible to cache wrapped utilities across request boundaries and supports the usage of self.REQUEST - something that should not be available in utilities. I believe using self.REQUEST in tools was never a good idea, tools that can't be fixed should not be registered as utilities. I guess you are right. Having all tools registered as utilities turned out to be the false approach, but having those tools available as utilities that are really utilities still seems to be a good idea. The Acquisition wrapping makes sure those can actually be used in a Zope2 security context. five.localsitemanager should remove the REQUEST object from the acquisition chain before re-wrapping tools. AFAICS this makes the wrapped tools no longer request specific, making it possible to cache them. [...] Does that make sense? If there are no objections I'll move on in that direction. This week I have some time to work on the implementation. +1 from me. As far as I can remember we had most of the code needed for that approach already working, so this should get as a solution in a not too distant future :) 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: [dev] five.localsitemanager
Wichert Akkerman wrote: I know I may be a bit pushy, but.. the weekend has come and gone, so I'm wondering if something has happened :) I better should have used dates :( At least in German the term next weekend is ambiguous. I wrote my email on Thursday evening and the last weekend started the next day, so in my view it was this weekend. By next weekend I did mean the weekend *after* this weekend. Sorry. 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
