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
[Zope-CMF] Re: backporting GenericSetup to CMF-1.5
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. 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... I've been using this kind of changes for a while in CPS so I know they're worthwile. They introduce semantic changes though (the updated catalog is not visible until the next request), which may be too much for some apps. good point. thx for the warning. -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
Raphael Ritz wrote: <--SNIP--> Now my questions: is the outline given above correct? At least w.r.t. the big picute? in a general sense, i think yes. 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)? i think this is mostly correct. in the CatalogMultiplex scenario, however, you have multiple catalogs, and different content types registered with one or more of them. in this case we'd still need to preserve somewhere this catalog:type registry mapping. also, while it would be possible to have each catalog as an event listener, checking the registry to see if (un)indexing is appropriate, it would be more efficient to have the registry itself being the listener, delegating only to the appropriate catalogs based on the type of object being manipulated. -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
Jens Vagelpohl wrote: 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. I don't think that was the plan. 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... Indeed and that's why the transition phase allows to keep using manage_afterAdd, provided a minimum level of cooperation from the frameworks. The minimum level of cooperations is to use super() properly. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +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
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
[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 ... ... 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
[Zope-CMF] Re: backporting GenericSetup to CMF-1.5
Rob Miller wrote: Florent Guillaume wrote: To repost an earlier mail: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. It *has* to be tested for Plone, as I have no idea what Plone does w.r.t CMFCatalogAware monkey-patching. i've taken a look at this, the patch definitely introduces some problems w/ Plone. the issue is that AT's BaseFolderMixin class, which is the underlying class for all of Plone's folderish content, has a declaration that looks like this: class BaseFolderMixin(CatalogMultiplex, BaseObject, PortalFolder, ): 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. 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... I've been using this kind of changes for a while in CPS so I know they're worthwile. They introduce semantic changes though (the updated catalog is not visible until the next request), which may be too much for some apps. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +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
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: [..] 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 Raphael in any event, i'll see if i can get some help on the plone side straightening out the indexing spaghetti. we can't just start using the new code, however, w/o serious breakage. :-(. -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
[Zope-CMF] Re: backporting GenericSetup to CMF-1.5
Florent Guillaume wrote: To repost an earlier mail: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. It *has* to be tested for Plone, as I have no idea what Plone does w.r.t CMFCatalogAware monkey-patching. i've taken a look at this, the patch definitely introduces some problems w/ Plone. the issue is that AT's BaseFolderMixin class, which is the underlying class for all of Plone's folderish content, has a declaration that looks like this: class BaseFolderMixin(CatalogMultiplex, BaseObject, PortalFolder, ): 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. 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... in any event, i'll see if i can get some help on the plone side straightening out the indexing spaghetti. we can't just start using the new code, however, w/o serious breakage. :-(. -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: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. d'oh! this is on my (overflowing) list of things to do. alec already provided some info, but i'll install and test this out over the next day or so and report back. Ok thanks. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +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
Florent Guillaume wrote: Rob Miller wrote: 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. To repost an earlier mail: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. d'oh! this is on my (overflowing) list of things to do. alec already provided some info, but i'll install and test this out over the next day or so and report back. -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
Hi! Rob Miller wrote: Jens Vagelpohl wrote: On 12 Nov 2005, at 09:04, yuppie wrote: 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? Well. I'll try to summarize what comes to my mind. This doesn't include the things Tres is working on. 1.) GenericSetup is quite silent. We need a logging and reporting framework. There is the provisional 'note' method in ISetupContext, but it has an XXX comment and doesn't look mature. I'm afraid nobody is working on this. 2.) We have to decide if we want to support more handler modes than shouldPurge false and shouldPurge true. Possible other modes could be 'dry run' or an 'append' mode that adds a copy with a different name instead of overwriting existing objects. 3.) The format of the XML files will change over time. I guess it would be useful to add version numbers to each exported XML file. This way it would be easier to do the right thing on import or to throw an error if the profile is too old. This could replace the version numbers of import steps. 4.) As soon as the first three issues are resolved we can adjust the node adapter API and freeze it. Instead of passing around additional arguments I'd like to make node adapters multi-adapters for the object and an export/import context. This would be an important milestone because it would allow to write setup handlers that work with the final versions of CMF 1.6 and 2.0. 5.) There is my proposal for simplifying tool handlers: http://mail.zope.org/pipermail/zope-cmf/2005-November/023331.html I'm currently waiting for an answer from Florent. 6.) CMF 2.0 should no longer depend on CMFSetup. With a CMF 1.6 release that provides BBB for CMF 1.5 profiles we might even be able to remove CMFSetup completely in CMF 2.0. The remaining setup handlers should be modernized and moved to the related products. There are also other unresolved issues, but I think freezing the API for setup handlers is the most important thing. Improving the setup tool and stuff like that could be done in CMF 2.1 if necessary. 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. I would not like to do this work on different branches, but if GenericSetup is a SVN external or if someone else does the merging I'm fine with creating the 1.6 branch earlier. Anyway I don't think 1.6 can be released before 2.0. We did have to break CMFSetup backwards compatibility more than once in CMF 1.5 releases because the CMFSetup shipped with 1.5.0 wasn't mature at all. I would not like to do the same with GenericSetup and CMF 1.6/2.0. Don't know what Tres has on his ToDo list, but I guess we could need help with some tasks. 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: backporting GenericSetup to CMF-1.5
On Sunday 13 November 2005 05:21 am, Florent Guillaume wrote: > Rob Miller wrote: > > 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. > > To repost an earlier mail: > > The patch I propose to include is: > > http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html > > > > Could some Plone folks please test that switching to > > CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 > > doesn't cause problems in Plone ? This patch just changes the order of > > base class for File and Image, and to do the CMFCatalogAware recursion > > it calls its base class instead of redoing it by hand. > > It *has* to be tested for Plone, as I have no idea what Plone does w.r.t > CMFCatalogAware monkey-patching. Plone does no monkey-patching of CMFCatalogAware. AT's CatalogMultiplex subclasses CMFCatalogAware, to allow reindexing in multiple catalogs. It doesn't touch any of the manage_after* methods except manage_afterClone, which calls CMFCatalogAware.manage_afterClone directly (i.e. without super). The AT base classes in turn define manage_after* methods which call CatalogMultiplex.manage_after* directly (again without super). My understanding is that having these subclasses which don't use super could result in multiple calls to some baseclass methods, so that AT would end up with even more excess reindex calls than it already has. Additionally some 3rd-party products (in my sandbox only CMFBoard) make direct calls to CatalogMultiplex.manage_after*. Those are the only potential issues I'm seeing with regard to those changes in the products I have installed locally. 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 13 Nov 2005, at 08:21, Florent Guillaume wrote: To repost an earlier mail: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. It *has* to be tested for Plone, as I have no idea what Plone does w.r.t CMFCatalogAware monkey-patching. Even with this tested and working we still have one big unknown in GenericSetup itself. It looks like no one wants to make any estimate about the point in time when it is considered "done" enough for a 1.6 release branch... 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
Rob Miller wrote: 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. To repost an earlier mail: The patch I propose to include is: http://mail.zope.org/pipermail/cmf-checkins/2005-November/007137.html Could some Plone folks please test that switching to CMF/branches/efge-1.5-five-compatible instead of CMF/branches/1.5 doesn't cause problems in Plone ? This patch just changes the order of base class for File and Image, and to do the CMFCatalogAware recursion it calls its base class instead of redoing it by hand. It *has* to be tested for Plone, as I have no idea what Plone does w.r.t CMFCatalogAware monkey-patching. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +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
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
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
Guys, I'm weeping... we're actually talking to each other. :-) Martin On Sat, 12 Nov 2005 18:26:22 -, Florent Guillaume <[EMAIL PROTECTED]> wrote: 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 -- (muted) ___ 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 R&D +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
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
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. GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized. 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: 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 Design"http://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
