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
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
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
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
