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] CMF Collector: Open Issues
The following supporters have open issues assigned to them in this collector (http://www.zope.org/Collectors/CMF). Assigned and Open mhammond - Windows DevelopmentMode penalty in CMFCore.DirectoryView, [Accepted] http://www.zope.org/Collectors/CMF/366 yuppie - support directory views outside Products, [Accepted] http://www.zope.org/Collectors/CMF/467 Pending / Deferred Issues - FSPropertiesObject.py cannot handle multiline input for lines, text attributes, [Deferred] http://www.zope.org/Collectors/CMF/271 - Can't invalidate skin items in a RAMCacheManager, [Pending] http://www.zope.org/Collectors/CMF/343 - workflow notify success should be after reindex, [Deferred] http://www.zope.org/Collectors/CMF/389 - Possible bug when using a BTreeFolder Member folder, [Pending] http://www.zope.org/Collectors/CMF/441 - Proxy Roles not Working/Applied to Worflow Transition Scripts, [Pending] http://www.zope.org/Collectors/CMF/449 - safe_html filters some tags which should probably not be filtered, [Pending] http://www.zope.org/Collectors/CMF/452 - purge_old in runAllImportSteps not working, [Pending] http://www.zope.org/Collectors/CMF/455 - Danger from Caching Policy Manager, [Pending] http://www.zope.org/Collectors/CMF/460 - properties setup handler: support for non-ascii strings, [Pending] http://www.zope.org/Collectors/CMF/468 - CMFUid reindexes all fields unnecessarily, [Pending] http://www.zope.org/Collectors/CMF/469 - GenericSetup snapshot redirect does not work, [Pending] http://www.zope.org/Collectors/CMF/470 Pending / Deferred Features - Favorite.py: queries and anchors in remote_url, [Pending] http://www.zope.org/Collectors/CMF/26 - DefaultDublinCore should have Creator property, [Pending] http://www.zope.org/Collectors/CMF/61 - Document.py: universal newlines, [Pending] http://www.zope.org/Collectors/CMF/174 - portal_type is undefined in initialization code, [Pending] http://www.zope.org/Collectors/CMF/248 - CMFTopic Does Not Cache, [Deferred] http://www.zope.org/Collectors/CMF/295 - Wishlist: a flag that tags the selected action., [Pending] http://www.zope.org/Collectors/CMF/301 - CMFDefault should make use of allowCreate(), [Pending] http://www.zope.org/Collectors/CMF/340 - Nested Skins, [Deferred] http://www.zope.org/Collectors/CMF/377 - CatalogVariableProvider code + tests, [Pending] http://www.zope.org/Collectors/CMF/378 - manage_doCustomize() : minor additions, [Pending] http://www.zope.org/Collectors/CMF/382 - CMF needs View-based TypeInformation, [Pending] http://www.zope.org/Collectors/CMF/437 - Marker attributes should be deprecated, [Pending] http://www.zope.org/Collectors/CMF/440 - New getNextEvent Method, [Pending] http://www.zope.org/Collectors/CMF/462 ___ 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
