Re: [Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
Previously Hanno Schlichting wrote: > Jens Vagelpohl wrote: > > My checkins today addressed at least the second change set you list by > > making the site itself a utility and looking it up that way. The > > additional wrapping is gone as well. > > I tested the branch again against the current Plone trunk and found no > branch related problems, except one small glitch in our testing > infrastructure which causes three tests to fail (it's missing the > setSite() call somewhere). This can be easily fixed by us. > > I have already updated the current Plone trunk to set up a component > registry based on five.localsitemanager and added the migration steps to > register all the tools as utilities, as well as addding those to our > base profile. So once the branch is merged at least Plone will work > straight away. > > While my vote might not count much, I'd give a +1 to merging the branch > and release a beta including it. +1 here as well. The test runs do now reveal any problems aside from what Hanno already mentioned and the result is a good improvement. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
Hi, Jens Vagelpohl wrote: > My checkins today addressed at least the second change set you list by > making the site itself a utility and looking it up that way. The > additional wrapping is gone as well. I tested the branch again against the current Plone trunk and found no branch related problems, except one small glitch in our testing infrastructure which causes three tests to fail (it's missing the setSite() call somewhere). This can be easily fixed by us. I have already updated the current Plone trunk to set up a component registry based on five.localsitemanager and added the migration steps to register all the tools as utilities, as well as addding those to our base profile. So once the branch is merged at least Plone will work straight away. While my vote might not count much, I'd give a +1 to merging the branch and release a beta including it. Hanno ___ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Re: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1 Mar 2007, at 17:36, yuppie wrote: BTW: While fixing the tests a month ago I made two quick and dirty changes, adding some XXX comments: - in SkinnableObjectManager http://svn.zope.org/?view=rev&rev=72251 - in PropertiesTool http://svn.zope.org/?view=rev&rev=72252 Maybe someone can work on a more sophisticated solution and tests? My checkins today addressed at least the second change set you list by making the site itself a utility and looking it up that way. The additional wrapping is gone as well. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6svQRAx5nvEhZLIRAoWMAJ9H6mELtpy4MnMEF06pMbDB76Yk1ACghibn 26TOJ/zYktPWnmym05eYD7o= =HMKr -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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1 Mar 2007, at 17:36, yuppie wrote: Jens Vagelpohl wrote: On 28 Feb 2007, at 15:14, Rocky wrote: Now that I have completed the primary functionality for five.localsitemanager it seems to me that the CMF jens_tools_as_utilities branch should be ready for merging into trunk in anticipation of the of the next cmf 2.1 alpha/beta release. It's ready for merging when we have a story for existing sites, meaning a clear migration path. I was going to do some simple testing closer to this weekend (busy until then) and do a simple script that can be run via zopectl run and document it if no one else has a better idea or steps up. My assumption here is that the script needs to do two things for each CMF Site encountered in the ZODB: - - create the new magic component registry - - duplicate tool registration as done by the GS componentregistry step Please correct me if I am wrong. I resolved the first part some days ago: http://svn.zope.org/?view=rev&rev=72782 But I'm not sure if "notify(BeforeTraverseEvent(self, REQUEST))" is in the right place. Maye it should just be called by PortalObjectBase, not by all DynamicType subclasses. BTW: While fixing the tests a month ago I made two quick and dirty changes, adding some XXX comments: - in SkinnableObjectManager http://svn.zope.org/?view=rev&rev=72251 - in PropertiesTool http://svn.zope.org/?view=rev&rev=72252 Maybe someone can work on a more sophisticated solution and tests? I have now removed all the additional "manual" tool wrapping in the code and rely on the new component registry wrapping only. Tests are passing 100%. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6rr8RAx5nvEhZLIRAiuWAKCFImduWyycEYRBB9dP7YYLtO+K5gCfW/wP /tG+7QMzP9Vld+1sq0YM4Nk= =G8N9 -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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2 Mar 2007, at 13:01, Jens Vagelpohl wrote: I can't seem to replicate this in a script. Changing the import context to "CMFDefault:default" does not seem to update the available import steps - however, using the ZMI and the "Properties" tab on the setup tool does. Found it: Internally, the profile ID to use with setImportContext is not "Products.CMFDefault:default", as I was using, it needs to be mangled into "profile-Products.CMFDefault:default". That one works... jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6CL2RAx5nvEhZLIRAhDGAJ9NLACW8mQ070HtLm+Kq3uzaT4M0ACeJsFZ 8Mfs7ybrJ2s9rmwLNwf50rw= =oysr -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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2 Mar 2007, at 13:36, yuppie wrote: I can't seem to replicate this in a script. Changing the import context to "CMFDefault:default" does not seem to update the available import steps - however, using the ZMI and the "Properties" tab on the setup tool does. Both ways call the very same code (setImportContext) under the hood. Would anyone know why this does update the available steps from the ZMI, but not in the script? I've already tried a few things, like committing a transaction or calling _updateImportStepsRegistry manually, it just doesn't do anything... Just a wild guess: Does this now depend on looking up local utilities? Maybe you have to use setSite() explicitly? No, the code path here is very short and does not involve any utility lookups. Matter of fact no code in GenericSetup.tool.SetupTool does any lookups. Adding setSite right before manipulating the portal diesn't help, either. To be more precise about the symptoms, the change in import context is successful. It turns into CMFDefault:default. It just seems to retain the (shorter) list of import steps that CMF 1.6 offered, so the actual failure stems from the inability to locate a "componentregistry" import step in the profile. When I use the ZMI to change contexts instead the step registry is reloaded correctly. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6B/fRAx5nvEhZLIRAoplAJ9WhBH+HZrzgiHZgb1SHADGxlEOFgCgldHO +6L8pIDon/TgNbE3YScLAhQ= =eiDn -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: tools-as-utilities, merging, releasing, etc
Jens Vagelpohl wrote: I'm working on the second step, trying to effect the component registration, and keep running into a strange problem. Using the ZMI, I can get a CMF site created in CMF 1.6 to a functioning state using the setup tool and executing the following steps + dependencies: - - CMFDefault:default "actions" and "componentregistry" - - CMFCalendar/CMFUid/CMFActionIcons "componentregistry" I can't seem to replicate this in a script. Changing the import context to "CMFDefault:default" does not seem to update the available import steps - however, using the ZMI and the "Properties" tab on the setup tool does. Both ways call the very same code (setImportContext) under the hood. Would anyone know why this does update the available steps from the ZMI, but not in the script? I've already tried a few things, like committing a transaction or calling _updateImportStepsRegistry manually, it just doesn't do anything... Just a wild guess: Does this now depend on looking up local utilities? Maybe you have to use setSite() explicitly? HTH, 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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1 Mar 2007, at 17:36, yuppie wrote: It's ready for merging when we have a story for existing sites, meaning a clear migration path. I was going to do some simple testing closer to this weekend (busy until then) and do a simple script that can be run via zopectl run and document it if no one else has a better idea or steps up. My assumption here is that the script needs to do two things for each CMF Site encountered in the ZODB: - - create the new magic component registry - - duplicate tool registration as done by the GS componentregistry step I'm working on the second step, trying to effect the component registration, and keep running into a strange problem. Using the ZMI, I can get a CMF site created in CMF 1.6 to a functioning state using the setup tool and executing the following steps + dependencies: - - CMFDefault:default "actions" and "componentregistry" - - CMFCalendar/CMFUid/CMFActionIcons "componentregistry" I can't seem to replicate this in a script. Changing the import context to "CMFDefault:default" does not seem to update the available import steps - however, using the ZMI and the "Properties" tab on the setup tool does. Both ways call the very same code (setImportContext) under the hood. Would anyone know why this does update the available steps from the ZMI, but not in the script? I've already tried a few things, like committing a transaction or calling _updateImportStepsRegistry manually, it just doesn't do anything... jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFF6BILRAx5nvEhZLIRAnUZAJ4nvjcD8F9ouXJbwxMRGqLdfw5q+ACgh0UN lm7Xuc76c36hX/SF9yaUBu4= =1pFk -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: tools-as-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. Yes, the ZPublisher should be firing it. But it doesn't. While it's clearly an oversight for Zope 2.10, I wonder if it can be classified as a bug or not. Probably not. Certainly a lot of existing Zope 2 ISites will have this hideous persistent before-traverse hook that came to us via whoever thought of Five.site (*cough* right, Sidnei? :)). So if the ZPublisher introduces this event, we'll ahve to be careful that it won't be sent twice for an object... Patches are welcome :). -- 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: tools-as-utilities, merging, releasing, etc
Sidnei da Silva wrote: That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. That might be right, I'm not familiar with the details. But Zope 2.10 doesn't fire the BeforeTraverseEvent, so CMF has to do it somehow. I just refactored a dynamically set 'before traverse hook' using a hardcoded call in __before_publishing_traverse__. AFAICS that didn't make things worse. 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: tools-as-utilities, merging, releasing, etc
That BeforeTraverseEvent should be fired by ZPublisher/BaseRequest.py, after it looks up __before_publishing_traverse__ but before calling it I believe. Firing it from inside CMF doesn't make sense. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ 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: tools-as-utilities, merging, releasing, etc
Hi Jens! Jens Vagelpohl wrote: On 28 Feb 2007, at 15:14, Rocky wrote: Now that I have completed the primary functionality for five.localsitemanager it seems to me that the CMF jens_tools_as_utilities branch should be ready for merging into trunk in anticipation of the of the next cmf 2.1 alpha/beta release. It's ready for merging when we have a story for existing sites, meaning a clear migration path. I was going to do some simple testing closer to this weekend (busy until then) and do a simple script that can be run via zopectl run and document it if no one else has a better idea or steps up. My assumption here is that the script needs to do two things for each CMF Site encountered in the ZODB: - - create the new magic component registry - - duplicate tool registration as done by the GS componentregistry step Please correct me if I am wrong. I resolved the first part some days ago: http://svn.zope.org/?view=rev&rev=72782 But I'm not sure if "notify(BeforeTraverseEvent(self, REQUEST))" is in the right place. Maye it should just be called by PortalObjectBase, not by all DynamicType subclasses. BTW: While fixing the tests a month ago I made two quick and dirty changes, adding some XXX comments: - in SkinnableObjectManager http://svn.zope.org/?view=rev&rev=72251 - in PropertiesTool http://svn.zope.org/?view=rev&rev=72252 Maybe someone can work on a more sophisticated solution and tests? 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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky wrote: > On Feb 28, 12:15 pm, Tres Seaver <[EMAIL PROTECTED]> wrote: >> On that note, I would *greatly* appreciate it if you (Rocky) would >> promise not to move the SVN tag for LSM after this point: the >> possibility of chasing down reports which can't be replicated due to >> having the same tag point at different actual versions is terrifying to me. > > The release-0.1 tag for LSM is permanent. It will not be changed/ > moved. I only changed it before so that we would have something to > play with on the cmf branch. > > Any future LSM work will be snapshotted as a 0.2 or 1.0beta (or > something to that effect) tag. Thanks! Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5ayk+gerLs4ltQ4RAhGQAJ4qX55UB31FeagzZuTHHOls1UZVHwCbBzDd 8C19QM4d8XxsDhfeQZbv2y0= =ZLgw -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: tools-as-utilities, merging, releasing, etc
On Feb 28, 12:15 pm, Tres Seaver <[EMAIL PROTECTED]> wrote: > On that note, I would *greatly* appreciate it if you (Rocky) would > promise not to move the SVN tag for LSM after this point: the > possibility of chasing down reports which can't be replicated due to > having the same tag point at different actual versions is terrifying to me. The release-0.1 tag for LSM is permanent. It will not be changed/ moved. I only changed it before so that we would have something to play with on the cmf branch. Any future LSM work will be snapshotted as a 0.2 or 1.0beta (or something to that effect) tag. - 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: tools-as-utilities, merging, releasing, etc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rocky wrote: > Now that I have completed the primary functionality for > five.localsitemanager it seems to me that the CMF > jens_tools_as_utilities branch should be ready for merging into trunk > in anticipation of the of the next cmf 2.1 alpha/beta release. > > Even if the functionality is unstable at this point I would think it's > fine for beta since there is no more intended functionality meant to > be included. > > Just for a bit of extra info, I have solidified the release-0.1 tag > for five.localsitemanager and this tag is used directly by the jens > CMF branch. I'd prefer to keep 0.1 as a silent release with the goal > of five.localsitemanager 1.0 final being released simultaneously with > CMF 2.1 final. > > What do you all think? This change is the most potentially disruptive one to land in the CMF in quite a while. Can we get some feedback from those who need the merge that the branch works reasonably well for them? And do we have any writeup about what folks who have been working at or near the tip of the trunk should expect after such a merge? We should tag the tip before the merge, to give those who need stability a place to hide, too. On that note, I would *greatly* appreciate it if you (Rocky) would promise not to move the SVN tag for LSM after this point: the possibility of chasing down reports which can't be replicated due to having the same tag point at different actual versions is terrifying to me. BTW, the Plone practice of bundling all the component products as '-trunk' has bitten me more than once on this front: I don't think you can ask people not directly involved in developing the component pieces to test something which differs from minute-to-minute. It is more work to do "real" release management on the components, but I have found it very worthwhile. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5ZyN+gerLs4ltQ4RAjd4AKDW2S6ts0dCMbjX7LpYsBDAwl+eqQCfaa5A zeWxWXTvzdOgyg/inEX9N3E= =20nh -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
