[Zope-CMF] Re: backporting GenericSetup to CMF-1.5
Raphael Ritz wrote: Rob Miller wrote: [..] to be fair, AT's (un)indexing code is a mess... i tried to change the BaseFolderMixin manage_(after|before)* methods so they explicitly call the PortalFolder implementations and was still ending up w/ subobject orphans left in the catalog after container deletions. ideally, this would provide us an opportunity to push the CatalogMultiplex functionality down into the CMF core and clean up the indexing mess on the Plone side a bit. and in a perfect world, we'd defer the actual (un)indexing until the end of the transaction. those changes might be too much to try to get into CMF 1.6, however... Isn't that a perfect reason to throw this away entirely and to move to (container) event based indexing? Isn't that what Florent is proposing as well? http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2005_11_08_events-in-zope-2-9 yes, but i already have my hands full w/ trying to get the GenericSetup stuff (which is also important, if we're to keep up w/ all of the other new developments) working well enough for consideration in the next Plone release. i was planning on bringing this to the plone-devel list tomorrow (it's 1:20am for me now, time for bed) to try to drum up support, to see if someone else will step forward and run with it. if it's going to land, we need to have a proof-of-concept bundle working for review no later than december 1st. you're more than welcome to either pitch this to plone-devel or to grab it by the horns and start working on it yourself. :-). -r ___ 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: backporting GenericSetup to CMF-1.5
Rob Miller wrote: [..] you're more than welcome to either pitch this to plone-devel or to grab it by the horns and start working on it yourself. :-). Hi Rob and all other CMF developers, I know I'm getting myself in danger now as I know too little yet about Zope 3 and I have no practical experience whatsoever using the new event system or not even the slightes idea to what extend the work for CMF-2.0 already achieved progress here. So, before I start digging deeper into this I have some fundamental (and hopefully trivial!) questions: This is about using events for catalog awareness If it's already there, please tell me and you can stop reading. If not: What would it need to get there? I consider support for container events as given (Zope 2.9 or Zope 2.8 and Five 1.2). - Does that mean these events are there now when content is added/changed/removed in a CMF site or is there anything to be done first (like declaring Portal[Folder|Content] to provide some interface and making them generate these events?; add or change some base classes?) - Is there anything like a ZCatalog in Zope 3 including event handlers for IObject[Added|Removed|Changed|...]Event triggering [index|unindex|reindex] etc? If not: providing such handlers for the current catalog should be straight-forward. Something like getToolByName(obj, 'portal_catalog').[un|re]indexObject(obj) or am I missing something? (how to deal with multiple catalogs? wouldn't this be the wrong place for handling this anyway? but where then?) - Glueing it together needs some interface on the content side. E.g., say there is a marker interface 'ICatalogAware' declared for portal content and portal folder. Then we could configure subscribers like ... subscriber for=Products.CMFCore.interfaces.ICatalogAware zope.app.container.interfaces.IObjectAddedEvent handler=Products.CMFCore.CatalogTool.addedContent / ... where - again - the handler could be as easy as def addedContent(obj, event): getToolByName(obj, 'portal_catalog').indexObject(obj) (BTW: where are those handlers typically defined? Should it be a method of the specific tool or a more general utility? If defined on the tool itself, how would one deal with several instances - either different CMF sites in one Zope instance or several catalogs in one portal site) Now my questions: is the outline given above correct? At least w.r.t. the big picute? If so: Having this in place shouldn't this allow for easy extension to multiple catalogs (like the uid or reference catalogs from AT) by simply registering them as further subscribers to the respective events? How to do that? (RTFM manual pointers welcome; maybe I just need to read Philipp's chapter on sites and local utilies again but as of now I don't see how you get this together with the TTW generation of arbirary many CMF and/or Plone sites in one Zope instance). If this would be all true, is it correct to infer then that this is something Plone shouldn't have to deal with at all (except for configuration)? Feedback welcome! Raphael -r ___ 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 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: backporting GenericSetup to CMF-1.5
On 15 Nov 2005, at 02:56, Rob Miller wrote: to be fair, AT's (un)indexing code is a mess... i tried to change the BaseFolderMixin manage_(after|before)* methods so they explicitly call the PortalFolder implementations and was still ending up w/ subobject orphans left in the catalog after container deletions. ideally, this would provide us an opportunity to push the CatalogMultiplex functionality down into the CMF core and clean up the indexing mess on the Plone side a bit. and in a perfect world, we'd defer the actual (un)indexing until the end of the transaction. those changes might be too much to try to get into CMF 1.6, however... A big -1 on just pushing the Plone mess into CMF. As Raphael suggests, it would be much better to go directly to event- based cataloging. However, that sounds like too big of a chunk for the given timeframe... jens ___ 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: backporting GenericSetup to CMF-1.5
On Tuesday 15 November 2005 10:43 am, Rob Miller wrote: Florent Guillaume wrote: Rob Miller wrote: CatalogMultiplex is a subclass of CMFCatalogAware which overrides the (un/re)indexObject methods to perform operations in multiple catalogs, if necessary. your patch changes CMFCatalogAware's manage_before* and manage_after* methods so that it delegates to 'super' in order to handle recursion w.r.t. containers, but in this case 'super' ends up being BaseObject, and so the manage_(after|before)* methods in ObjectManager (inherited via PortalFolder) never get called. Can't BaseObject's manage_afterAdd co use super() too? The goal is that everyone uses super() because if one piece of code doesn't, everything may break. yes... i'll play around with this this evening. The problem is that everyone subclasses BaseObject/BaseContent/BaseFolder and explicitly delegates to some of its methods. There's a good chance that many many AT projects will break if BaseObject starts using super. 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
Re: [Zope-CMF] Re: backporting GenericSetup to CMF-1.5
On 12 Nov 2005, at 09:04, yuppie wrote: A CMF 1.6 release that requires Zope 2.8 and essentially bundles CMF 1.5 with GenericSetup 2.0 (and compatible CMF setup handlers) might be a good idea. Yes, that's a good idea. It certainly can't go directly in the strictly-maintenance 1.5 branch. +1 from me for 1.6 then. Rob, without wanting to open a Pandora's box, is Generic Setup the only thing you're really craving or are there other low-hanging fruit that could be dealt with *without* moving too far off the 1.5 code base? And what is the timeframe for Plone 2.2 (I assume that's the release you want this for)? GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized. Stabilized meaning moved from alpha to beta or the final? I'm trying to see how far the different schedules (Plone 2.2 and a stabilized GenericSetup) can be made to match up. jens ___ 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: backporting GenericSetup to CMF-1.5
yuppie wrote: Hi Rob! Rob Miller wrote: those of us planning out the next Plone releases are in a bit of a bind. we really want to make use of GenericSetup's newer Z3-interface-based means of defining import and export handlers, so that we can start work on rewriting our migration engine to use XML import and export, and so we can keep up w/ CMF 2.0 as it moves forward. [...] to this end, it would be very useful for us to have a 1.5-compatible version of CMF that makes use of the newer Generic/CMFSetup semantics. this would allow us to use the new site creation code (which we've nearly completed) in our next release without breaking backwards compatibility with the existing add-on products. this would also make it easier to keep up w/ CMF trunk development w/o having to maintain two radically different branches of Plone. CMF 2.X would be required, of course, with the subsequent release. how do folks feel about this? (note that we, i.e. the plone developers, are willing to do the work.) would you be willing to have an additional 1.5 release, or perhaps a 1.6 release, which includes these changes? our current tentative release schedule has a Plone alpha in late december, beta in february, release some time in march. CMF 1.5 is Zope 2.7 compatible. A Zope 2.7 compatible version of GenericSetup would be a lot of work and it would loose the new semantics because they depend on Five features. But if Plone 2.2 requires Zope 2.8 it should be easy to use CMF 1.5 with GenericSetup 2.0 instead of CMFSetup 1.5. Except for the CMF specific handlers that should work out of the box. A CMF 1.6 release that requires Zope 2.8 and essentially bundles CMF 1.5 with GenericSetup 2.0 (and compatible CMF setup handlers) might be a good idea. Hm seen in that light, I also have a need for a CMF 1.6 that drops support for Zope 2.7. The reason are the recent changes I proposed to support Five 1.2, which need super() to work properly. So it needs Zope 2.8. GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized. +1 on branching CMF 1.6 soon, with the goal of: - dropping support for Zope 2.7 - allowing Five 1.2 events activated to work, even if it doesn't *require* Five 1.2 events - be closer to CMF 2.0 w.r.t. setup. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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: backporting GenericSetup to CMF-1.5
Jens Vagelpohl wrote: On 12 Nov 2005, at 09:04, yuppie wrote: A CMF 1.6 release that requires Zope 2.8 and essentially bundles CMF 1.5 with GenericSetup 2.0 (and compatible CMF setup handlers) might be a good idea. Yes, that's a good idea. It certainly can't go directly in the strictly-maintenance 1.5 branch. +1 from me for 1.6 then. great... it seems we're all in consensus for a 1.6. Rob, without wanting to open a Pandora's box, is Generic Setup the only thing you're really craving or are there other low-hanging fruit that could be dealt with *without* moving too far off the 1.5 code base? GenericSetup is the important one. i could come up w/ more, sure, but since Plone is moving to a time-based release schedule, and the proposal and feature freeze is coming very soon (dec 1) i don't think there's really time for us to tackle anything else. And what is the timeframe for Plone 2.2 (I assume that's the release you want this for)? Plone may change its numbering convention soon, but yes, i'm talking about the next non-2.1-maintenance release, which we'll call 2.2 for now. the time frame is that there is a proposal/feature freeze scheduled for dec 1; by that time, any new features that are going to land have to be implemented in review bundle so the framework team can assess whether or not it's gonna work. actual release dates are still tentative, but we're looking at an initial alpha around dec 20, a beta in mid-feb, and release candidates leading to a release in mid march. GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized. unfortunately i need to move rather quickly to be able to produce a proof-of-concept for the framework team to review. i may need to cut a branch and then just accept that i'll have to keep up w/ GenericSetup for a bit. do we know how much change is likely to happen, and in what areas? Stabilized meaning moved from alpha to beta or the final? I'm trying to see how far the different schedules (Plone 2.2 and a stabilized GenericSetup) can be made to match up. that would be great! hope the info i gave helps. -r ___ 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: backporting GenericSetup to CMF-1.5
Florent Guillaume wrote: +1 on branching CMF 1.6 soon, with the goal of: - dropping support for Zope 2.7 - allowing Five 1.2 events activated to work, even if it doesn't *require* Five 1.2 events - be closer to CMF 2.0 w.r.t. setup. this is perfect for us. there doesn't really need to be any work done to allow the Five 1.2 event support, right? this comes just by virtue of dropping 2.7 support? want to make sure we don't drift too far from tres's proposed scope, to ease maintenance. -r ___ 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: backporting GenericSetup to CMF-1.5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Miller wrote: those of us planning out the next Plone releases are in a bit of a bind. we really want to make use of GenericSetup's newer Z3-interface-based means of defining import and export handlers, so that we can start work on rewriting our migration engine to use XML import and export, and so we can keep up w/ CMF 2.0 as it moves forward. however, we just had a release that broke all of the add-on products, and it's not really an option for us to break everything again by depending on CMF 2.0, which has removed a bunch of deprecated spellings that are still in common use throughout many Plone add-on products. we realize, of course, that this is in part a result of us having fallen so far behind CMF's development cycle, but we are now earnestly trying to play catch-up, and to continue to keep up, without forcing all of our product authors to rewrite their products twice in 6 months just to keep them working. to this end, it would be very useful for us to have a 1.5-compatible version of CMF that makes use of the newer Generic/CMFSetup semantics. this would allow us to use the new site creation code (which we've nearly completed) in our next release without breaking backwards compatibility with the existing add-on products. this would also make it easier to keep up w/ CMF trunk development w/o having to maintain two radically different branches of Plone. CMF 2.X would be required, of course, with the subsequent release. Thanks for explaining the rationale so clearly. how do folks feel about this? (note that we, i.e. the plone developers, are willing to do the work.) would you be willing to have an additional 1.5 release, or perhaps a 1.6 release, which includes these changes? I would be happier with this as a 1.6, because it adds features (and therefore risk of instability) into a mature release / support line. +1 to that, assuming we can scope it as current 1.5 branch except CMFSeup / GenericSetup from some labeled tag of current trunk. Note that I would expect to continue critical / security bugfix support for the 1.5 line, and would want the 1.6 line to stay as close to 1.5 as possible (with the exception of the setup code) to reduce the maintenance burden. our current tentative release schedule has a Plone alpha in late december, beta in february, release some time in march. Just for the record: CMF 2.0 should be in alpha by the end of this month, with a beta in mid December and a release in early January. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDdUxm+gerLs4ltQ4RAnrcAJ934YyNQlS8zMb1ufS6gXXjpv8vQwCgsjsk VTlqYM03fJtDBNtH7MGnqHo= =ZnK6 -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
