[Zope-CMF] Re: Five's local sitemanager, CMF, etc
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26 Feb 2007, at 17:03, Martin Aspeli wrote: To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. +1 - in fact, we already have Products.CMFCore.interfaces.ISiteRoot. I use it all the time. :) This is now completed on the branch. I did not try to locate every single place in the code where the site is looked up, though. I patched a couple specific places pointed out by Yuppie, and the main URLTool.getPortalObject method to use the utility. Fantastic :) Thanks! 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: Five's local sitemanager, CMF, etc
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). - Rocky ___ 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: Five's local sitemanager, CMF, etc
Rocky wrote:
On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote:
yuppie wrote:
Maybe I'm missing something. But wasn't a major goal of
five.localsitemanager to return acquisition wrapped tools?
That was my understanding, too. I thought this would just mean
aq_base'ing the utility and aq-wrapping it back into the context (the
portal root). Without this, we start requiring users of the interface to
know when aq wrapping is needed and do it explicitly with __of__() which
I think we agreed was unacceptably detailed and ugly. :)
Alright, I've gone ahead and put code in place for this (albeit a bit
naively) with r72810. The next question is whether we should be doing
the same with adapters and subscribers as well (even though this
doesn't affect the whole tools-getting-acquired-properly issue).
I'm a bit uneasy about the implementation. With
Acquisition.ImplicitAcquisitionWrapper(base, parent) it seems you're
wrapping all utilities, even those that don't inherit from acquisition
and potentially don't want acquisition. Even worse, you give them an
*implicit* acquisition wrapper.
I think _wrap() should be changed to:
def _wrap(self, comp):
Return an aq wrapped component with the site as the parent.
if Acquisition.interfaces.IAcquirer.providedBy(comp)
parent = Acquisition.aq_parent(self)
if parent is None:
raise ValueError('Not enough context to acquire parent')
base = Acquisition.aq_base(comp)
comp = base.__of__(parent)
return comp
This way, only objects that inherit from one of the Acquisition base
classes will be wrapped at all.
--
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5
___
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: Five's local sitemanager, CMF, etc
Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF4zvU+gerLs4ltQ4RAtZ0AJ9kK/GThZW9eTI1CXuFWHVnQRVDyQCfaTl+ OAZgpfhWGQmWU2rxT5l9pKg= =pW21 -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: Five's local sitemanager, CMF, etc
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Rocky wrote: On Feb 23, 3:50 pm, Martin Aspeli [EMAIL PROTECTED] wrote: yuppie wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) Alright, I've gone ahead and put code in place for this (albeit a bit naively) with r72810. The next question is whether we should be doing the same with adapters and subscribers as well (even though this doesn't affect the whole tools-getting-acquired-properly issue). One more thing: This acquisition wrapping should clearly be marked (with comments) as something that's done to for BBB because some tools happen to want acquisition. I think in the future, it should be discouraged to expect acquisition in CMF tools. - -1. This is not *yet* BBB, until we require a version of Zope which no longer uses acquisition for anything crucial. Premature deprecation is crying wolf, IMNSHO. I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the Zope2 is evil, Zope3 is wonderful fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a subscription adapter. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF42Ot+gerLs4ltQ4RAqPLAJ9vnHfe6tO7paPMhs8bPnmYxx4SqQCfciUd IUgd7g+CHTxhNXufTCbKKqk= =+R0J -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: Five's local sitemanager, CMF, etc
On 26 Feb 2007, at 23:48 , Tres Seaver wrote: I nowhere said anything about deprecation. All meant was to discourage relying on acquisition when developing new tools. I think that deserves a comment (I suggested nothing more). No deprecation warning or anything necessary;. OK. I do think we need to have some resistance to the Zope2 is evil, Zope3 is wonderful fundamentalism which sometimes shows up around here. Frankly, Zope3 *is* a cool library, but it does not address a number of the scenarios Zope2 does, and maybe never will. Yes. Zope 3 is can be seen as a set of libraries -- and a number of approaches. As far as acquisition (the concept) is concerned, I think the common perception is that Acquisition (the Zope 2 package) introduces pains, magic and unpredictability, whereas the way acquisition is implemented in Zope 3 (discrete places called sites from which you can acquire things after registering things explicitly) is a cleaner and more predictable concept. I see this whole effort (making CMF tools available as utilities, etc.) a way to move from Acquisition (the Zope 2 package) to a better form of acquisition (using the Zope 3 Component Architecture). Such a process needs to be accompanied by clear statements what's encouraged and what's discouraged. That doesn't mean that the old way is evil, but we can certainly give a clear recommandation as to what's better (not necessarily wonderful but better). To get to the portal root / CMF site, I suggest a pattern that is sometimes used in Zope3: We register the CMF site object as a utility providing ICMFSite (or whatever). Then whichever code that's executed below the portal (and that includes CMF tools) can do getUtility(ICMFSite) to get to the site. Adapters and subscription adapters should not be acquisition wrapped. They darn well better be able to get a wrapped context (which means that the event *must* have a wrapped attribute) or they will be less than useless. That's something else. Adapters and subscription adapters will get whatever they are looked up with. If that's wrapped, fine. E.g. if you do IWhatever(obj) and you got obj thru acquisition, then the IWhatever adapter will see obj with all its acquisition glory. But The adapter objects themselves shouldn't be wrapped. It would break, say, views which happen to be adapters. I'll note that five views are already required to be acquisition wrapped if they use any objects protected by Zope2 security machinery. Yes, but their wrapping is a detail of the traversal and security machinery. Hence it happens during traversal, not during component lookup. Note that subscription adapters != subscribers. Subscribers don't return objects upon lookup, they're just executed. Subscription adapters are more like adapters. I don't know of such a distinction. Please explain how one registers a subscription adapter. registry.registerSubscriptionAdapter() More on subscribers vs. subscription adapters: * Subscribers are the event subscribers we know: simple callables. They don't return anything (well, they return None :)), hence there's nothing to wrap or anything. * Subscription adapters are like regular adapters (and they are implemented exactly like a regular adapter). The difference is in the lookup. Instead of getting exactly 0 or 1 adapter in the adaption, you get n adapters (where n=0,1,2,3...) with subscription adapters. Basically, instead of finding the most specific adapter, subscription adapters will return *all* applicable adapters. So their lookup is a bit like the one of subscribers, hence the name. ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF3qP7RAx5nvEhZLIRAmoZAKC1YARJYy39L/KoC1L7Q9JARD7ysQCgtYol WN9eLctJ2nhMsgHscQdY/3s= =ZUUX -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: Five's local sitemanager, CMF, etc
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. Does CMF core not have any kind of migration infrastructure? 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: Five's local sitemanager, CMF, etc
Hi! Jens Vagelpohl wrote: On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Jens Vagelpohl wrote: On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. Hmm, I won't quibble about migration code. +1. For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. If the code which *used* to work using 'getToolByName' now breaks beofre that step is done, then we have a problem. If there is a clear, simple step to perform after upgrade, then we should be OK. E.g., we might tell folks to do something like: $ cd $INSTANCE_HOME $ ./bin/zopectl run Products/CMFCore/scripts/updateSites foo bar/baz To upgrade the 'foo', and 'bar/baz' site objects. I see no benefit to trying to do any migration from within the ZMI here. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3tWL+gerLs4ltQ4RAnW4AJ4haOZFzRT0bnqN4aNlyIEyiBlbkwCgy5id IHBEGs1wqUie0S2j9hd57Kc= =tvPd -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
Re: [Zope-CMF] Re: Five's local sitemanager, CMF, etc
Jens Vagelpohl wrote: After reading Phillip's book I really like Zope 3 generations, but I have no idea if that mechanism could be used at all. I had a look at it and started thinking about a CMFish version. The main challenge is that generates just get the app root as a handle, so you can't do migrations per-site, and you have to traverse the ZODB looking for CMF sites to migrate. For Plone, the portal_migrations tool manages migrations. They are explicitly invoked by the user. Martin -- View this message in context: http://www.nabble.com/Five%27s-local-sitemanager%2C-CMF%2C-etc-tf3219557.html#a9117904 Sent from the Zope - CMF list2 mailing list archive at Nabble.com. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: Five's local sitemanager, CMF, etc
Am 23.02.2007 um 12:52 schrieb Tres Seaver: Hmm, I won't quibble about migration code. +1. +1 me neither For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. If the code which *used* to work using 'getToolByName' now breaks beofre that step is done, then we have a problem. If there is a clear, simple step to perform after upgrade, then we should be OK. I thought Jens had written it so nothing breaks? E.g., we might tell folks to do something like: $ cd $INSTANCE_HOME $ ./bin/zopectl run Products/CMFCore/scripts/updateSites foo bar/baz To upgrade the 'foo', and 'bar/baz' site objects. I see no benefit to trying to do any migration from within the ZMI here. Me neither. I guess that CMF users can be expected to work in the file system. It is probably just me on this list but I would appreciate a list of the changes in the architecture with particular reference to what is likely to break or will need changing. So far I've picked up on yuppie's stuff to support views and Jens' work on utilities. Off hand I wouldn't expect those changes to break existing sites. I'm planning to do some work on the CMF next week, even using the svn version, which as Jens noted, is not what many people are likely to do. And now that I've got Phil's book I'll start working in a more Zope 3 kind of way. 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: Five's local sitemanager, CMF, etc
Hi! Tres Seaver wrote: yuppie wrote: Jens Vagelpohl wrote: On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. Hmm, I won't quibble about migration code. +1. Ok. I can have a closer look at this part. For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. If the code which *used* to work using 'getToolByName' now breaks beofre that step is done, then we have a problem. If there is a clear, simple step to perform after upgrade, then we should be OK. E.g., we might tell folks to do something like: $ cd $INSTANCE_HOME $ ./bin/zopectl run Products/CMFCore/scripts/updateSites foo bar/baz To upgrade the 'foo', and 'bar/baz' site objects. I see no benefit to trying to do any migration from within the ZMI here. I'll leave that part to someone else. 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: Five's local sitemanager, CMF, etc
On Feb 23, 8:10 am, yuppie [EMAIL PROTECTED] wrote: I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. While I'm typically against what is obviously an accessor method doing any sort of writing to the zodb I would let it slide here for the sake of avoiding a migration step. But while this will ensure the cmf site is an ISite, there is still a step missing. There is no zpublisher hook registered to fire traversal events when the site is traversed (which lets zope.component.getUtility be aware of the closest site even when not specifying a context). See Products.Five.component.enableSite for an example of what needs to be done here. The five.localsitemanager.make_objectmanager_site call invokes enableSite under the hood to setup this zpublisher hook. Maybe someone has a neat idea for setting this up too? (I don't, other then by a migration step) Or maybe there is something GenericSetup could do to setup a bit of migration? - Rocky ___ 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: Five's local sitemanager, CMF, etc
Rocky wrote: On Feb 23, 8:10 am, yuppie y.20...-E2EsyBC0hj3+aS/[EMAIL PROTECTED] wrote: I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. While I'm typically against what is obviously an accessor method doing any sort of writing to the zodb I would let it slide here for the sake of avoiding a migration step. But while this will ensure the cmf site is an ISite, there is still a step missing. There is no zpublisher hook registered to fire traversal events when the site is traversed (which lets zope.component.getUtility be aware of the closest site even when not specifying a context). See Products.Five.component.enableSite for an example of what needs to be done here. The five.localsitemanager.make_objectmanager_site call invokes enableSite under the hood to setup this zpublisher hook. Maybe someone has a neat idea for setting this up too? (I don't, other then by a migration step) Or maybe there is something GenericSetup could do to setup a bit of migration? http://svn.zope.org/?rev=72782view=rev I just added notify(BeforeTraverseEvent(self, REQUEST)) to DynamicType's __before_publishing_traverse__. 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: Five's local sitemanager, CMF, etc
On Feb 23, 10:15 am, yuppie [EMAIL PROTECTED] wrote: Rocky wrote: http://svn.zope.org/?rev=72782view=rev I just added notify(BeforeTraverseEvent(self, REQUEST)) to DynamicType's __before_publishing_traverse__. Hmm... ok, which sounds like we've done away with the need to call make_objectmanager_site(). And as long as the cmf site provides IObjectManagerSite (and we decided that it would always provide this right?) then make_objectmanager_site being accidentally called on it would be harmless. make_objectmanager_site will still of course be useful for turning regular zope folders into sites. - Rocky ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Hi! Tres Seaver wrote: yuppie wrote: Jens Vagelpohl wrote: On 23 Feb 2007, at 00:39, Rocky wrote: So... what's next? Figuring out how to deal with existing sites that need to be modified on the fly somehow so they don't break completely. I propose to hardcode PortalObjectBase as IObjectManagerSite. AFAICS getSiteManager() could create a component registry on the fly if necessary. So for that part we would neither need the new code in importVarious nor migration code. Hmm, I won't quibble about migration code. +1. Ok. I can have a closer look at this part. I just meant that creating a component registry on th fly sounded suspiciously like migration code to me. For registering the tools as utilities you still need to run the componentregistry import step. I would not use on-the-fly magic for that part, I think people should do that explicitly. If the code which *used* to work using 'getToolByName' now breaks beofre that step is done, then we have a problem. If there is a clear, simple step to perform after upgrade, then we should be OK. E.g., we might tell folks to do something like: $ cd $INSTANCE_HOME $ ./bin/zopectl run Products/CMFCore/scripts/updateSites foo bar/baz To upgrade the 'foo', and 'bar/baz' site objects. I see no benefit to trying to do any migration from within the ZMI here. I'll leave that part to someone else. The script would something like the attached file: I'm not up on the details of what would need to be done, but I have used the skeleton a fair bit. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF3vRq+gerLs4ltQ4RApYUAJ4hdjzP+nQVjq1cOsavmXx5OrgPygCgwr4g BnTSC9HAwaw+Idyo1mhGAHw= =GyfV -END PGP SIGNATURE- sample_script.py Description: application/httpd-cgi ___ 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: Five's local sitemanager, CMF, etc
Hi Rocky! Rocky wrote: Done. five.localsitemanager is now included with CMFCore on the jens branch. There aren't any CMF specific tests in place for any of this, but the CMFCore tests all run fine with sys.path stuff setup (they failed when I misconfigured things). So... what's next? Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? I can't find any code in five.localsitemanager that deals with that issue. So we now have support for nested sites, but still no support for utilities that need acquisition wrapping? 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: Five's local sitemanager, CMF, etc
On Feb 23, 1:52 pm, yuppie [EMAIL PROTECTED] wrote: Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? I can't find any code in five.localsitemanager that deals with that issue. So we now have support for nested sites, but still no support for utilities that need acquisition wrapping? You're absolutely right. An oversight on my part. I'm on my way out of town for the weekend, perhaps you could consider adding to five.localsitemanager yourself? Then you could retag the release-0.1 tag (it's a floating tag atm for me as there is no official release yet -- it was really just created for something CMFCore to anchor onto) so CMFCore gets the change(s). Regards, Rocky ___ 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: Five's local sitemanager, CMF, etc
yuppie wrote: Hi Rocky! Rocky wrote: Done. five.localsitemanager is now included with CMFCore on the jens branch. There aren't any CMF specific tests in place for any of this, but the CMFCore tests all run fine with sys.path stuff setup (they failed when I misconfigured things). So... what's next? Maybe I'm missing something. But wasn't a major goal of five.localsitemanager to return acquisition wrapped tools? That was my understanding, too. I thought this would just mean aq_base'ing the utility and aq-wrapping it back into the context (the portal root). Without this, we start requiring users of the interface to know when aq wrapping is needed and do it explicitly with __of__() which I think we agreed was unacceptably detailed and ugly. :) I can't find any code in five.localsitemanager that deals with that issue. So we now have support for nested sites, but still no support for utilities that need acquisition wrapping? Hopefully, doing so would be pretty easy. :) 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: Five's local sitemanager, CMF, etc
Jens Vagelpohl wrote: On 22 Feb 2007, at 09:03, Wichert Akkerman wrote: Hey Rocky, any progress? Haven't heard and loud yelling from Wichert yet, but I think he's getting close to the Plone 3.0 beta by now... I'm hoping for upcoming monday.. Merging the branch into the trunk is going to be a bit of work. I'm volunteering to do it, but I really need something from Rocky today or tomorrow to meet your Monday deadline. IIRC existing CMF sites stop working with that branch. That has to be resolved before releasing a beta. In general I'm no fan of last minute merges. There should be several days between merging a big branch like that and releasing a beta. 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: Five's local sitemanager, CMF, etc
On Feb 22, 8:30 am, Martin Aspeli [EMAIL PROTECTED] wrote: In my opinion only: I'm sure we can release a Plone beta 1 that depends on a CMF alpha if that needs to be. It's not ideal, but we can synchronise a little later if it's impractical for everyone involved. So, Rocky - progress? Working on it right now. - Rocky ___ 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: Five's local sitemanager, CMF, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22 Feb 2007, at 11:27, yuppie wrote: Jens Vagelpohl wrote: On 22 Feb 2007, at 09:03, Wichert Akkerman wrote: Hey Rocky, any progress? Haven't heard and loud yelling from Wichert yet, but I think he's getting close to the Plone 3.0 beta by now... I'm hoping for upcoming monday.. Merging the branch into the trunk is going to be a bit of work. I'm volunteering to do it, but I really need something from Rocky today or tomorrow to meet your Monday deadline. IIRC existing CMF sites stop working with that branch. That has to be resolved before releasing a beta. Right, my oversight. I believe the issue can be boiled down to the existing CMF site needs to be turned into a Zope 3 'site' and have a site manager? Or are there more issues? In general I'm no fan of last minute merges. There should be several days between merging a big branch like that and releasing a beta. I don't think I agree. We're only talking about a beta, the first beta. Very few people will test it when it's just in SVN. One huge advantage of being in lockstep with Plone is the fact that you get a whole bunch of beta testers for free which you would never have for a CMF release that is not distributed with a Plone release. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF3Zr9RAx5nvEhZLIRAm4RAJ9zt2mSFQSYDeVDY/RN8vua5UblowCfeGiZ kAs8p2brd/pc+DOZYJr9Vdw= =pgVA -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: Five's local sitemanager, CMF, etc
Jens Vagelpohl wrote: On 22 Feb 2007, at 11:27, yuppie wrote: IIRC existing CMF sites stop working with that branch. That has to be resolved before releasing a beta. Right, my oversight. I believe the issue can be boiled down to the existing CMF site needs to be turned into a Zope 3 'site' and have a site manager? Or are there more issues? None I'm aware of. In general I'm no fan of last minute merges. There should be several days between merging a big branch like that and releasing a beta. I don't think I agree. We're only talking about a beta, the first beta. Very few people will test it when it's just in SVN. One huge advantage of being in lockstep with Plone is the fact that you get a whole bunch of beta testers for free which you would never have for a CMF release that is not distributed with a Plone release. I'm not against a new release that can be shipped with the next Plone 3.0 milestone. I just feel uncomfortable with the label 'beta'. The last time I checked the utility branch didn't feel like 'beta'. 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: Five's local sitemanager, CMF, etc
On Feb 22, 11:06 am, yuppie [EMAIL PROTECTED] wrote: Jens Vagelpohl wrote: Right, my oversight. I believe the issue can be boiled down to the existing CMF site needs to be turned into a Zope 3 'site' and have a site manager? Or are there more issues? None I'm aware of. There will be a convenient api call for this... something like in five.localsitemanager.make_objectmanager_site. If all that needs to happen is to make a cmf site an ISite that five.localsitemanager likes. Of course @@components.html's makeSite will do the equivalent. In general I'm no fan of last minute merges. There should be several days between merging a big branch like that and releasing a beta. I don't think I agree. We're only talking about a beta, the first beta. Very few people will test it when it's just in SVN. One huge advantage of being in lockstep with Plone is the fact that you get a whole bunch of beta testers for free which you would never have for a CMF release that is not distributed with a Plone release. I'm not against a new release that can be shipped with the next Plone 3.0 milestone. I just feel uncomfortable with the label 'beta'. The last time I checked the utility branch didn't feel like 'beta'. For me a beta doesn't have to be more or less stable than an alpha. The important bit for me is that a beta should be feature complete whereas an alpha does not. So if the branch is feature complete (within reason, I understand if very small features are required to fix an as-yet-unidentified bug), I say it's good enough for beta. On a different note ... which branch/trunk should I integrate the five.localsitemanager changes? Keeping in mind that on my part it's *mostly* just an svn:externals change. - Rocky ___ 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
