[Zope-CMF] Re: GenericSetup-based installation backport mostly complete
Hi Rob! Rob Miller wrote: yuppie wrote: 2.) Please set svn:keywords Id on new python files. /me reads svn docs to learn about svn:keywords. The easiest way to make sure they are set is to modify your svn config. You might need something like this:: [miscellany] enable-auto-props = yes [auto-props] *.py = svn:eol-style=native;svn:keywords=Id *.pt = svn:eol-style=native *.txt = svn:eol-style=native *.xml = svn:eol-style=native *.zcml = svn:eol-style=native *.zpt = svn:eol-style=native svn:eol-style=native seems to be set already in your config. 3.) I'm a bit surprised how much of the TypesTool changes you ported back. all i did was move the FTI factory methods out of the TypesTool class and into the module. this makes it possible for the FTIs to be added to the types tool using the regular GenericSetup.utils.ObjectManagerHelpers mechanism, otherwise Factory-based Type Information won't exist in Products.meta_types. i did this because i'm trying to match CMF trunk's site creation mechanisms as much as possible. it's possible (probable, even) that there are side effects that i'm missing here, though. Sounds reasonable. There will not be many third-party products that try to register their own TypeInfo class. But you also removed the oldstyle manage_add* methods. That might break some products. 4.) At least CMF 2.0 TypesTool and ActionsTool have modifications that make it impossible to use the CMF 2.0 handlers for CMF 1.5 code. I guess you have to modify CMFSetup and use some CMF 1.5 handlers to get everything working. i've got all this working, or at least i think i do. are the TypesTool changes the ones i was mentioning above? I thought it would be easier to use some old handlers, but your approach to modify the new ones is fine. And I guess you are right that with your TypesTool changes the new handler works out of the box. for the ActionsTool, creating actions as full blown objects of course isn't working. all i had to do to get this working, though, was to remove some code from CMFCore.exportimport.actions.ActionsToolNodeAdapter. at first i modified this code to actually add actions to the action providers in the old manner, but was surprised to see that the actions were all added twice; i guess the tool initializations handle adding the actions themselves. I hope you saved a copy of what you did first. In CMF 1.5 all tools come with hardcoded initial settings. The handlers have to purge those settings and to add the actions from the profile. If you saw the actions added twice you forgot to clear the actions before doing the right thing. 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: GenericSetup-based installation backport mostly complete
yuppie wrote: Hi Rob! Rob Miller wrote: yuppie wrote: 2.) Please set svn:keywords Id on new python files. /me reads svn docs to learn about svn:keywords. The easiest way to make sure they are set is to modify your svn config. You might need something like this:: [miscellany] enable-auto-props = yes [auto-props] *.py = svn:eol-style=native;svn:keywords=Id *.pt = svn:eol-style=native *.txt = svn:eol-style=native *.xml = svn:eol-style=native *.zcml = svn:eol-style=native *.zpt = svn:eol-style=native svn:eol-style=native seems to be set already in your config. right... i've added the svn:keywords=Id to the *.py declaration, thx for the tip. 3.) I'm a bit surprised how much of the TypesTool changes you ported back. all i did was move the FTI factory methods out of the TypesTool class and into the module. this makes it possible for the FTIs to be added to the types tool using the regular GenericSetup.utils.ObjectManagerHelpers mechanism, otherwise Factory-based Type Information won't exist in Products.meta_types. i did this because i'm trying to match CMF trunk's site creation mechanisms as much as possible. it's possible (probable, even) that there are side effects that i'm missing here, though. Sounds reasonable. There will not be many third-party products that try to register their own TypeInfo class. But you also removed the oldstyle manage_add* methods. That might break some products. true... i'll put them back. 4.) At least CMF 2.0 TypesTool and ActionsTool have modifications that make it impossible to use the CMF 2.0 handlers for CMF 1.5 code. I guess you have to modify CMFSetup and use some CMF 1.5 handlers to get everything working. i've got all this working, or at least i think i do. are the TypesTool changes the ones i was mentioning above? I thought it would be easier to use some old handlers, but your approach to modify the new ones is fine. And I guess you are right that with your TypesTool changes the new handler works out of the box. for the ActionsTool, creating actions as full blown objects of course isn't working. all i had to do to get this working, though, was to remove some code from CMFCore.exportimport.actions.ActionsToolNodeAdapter. at first i modified this code to actually add actions to the action providers in the old manner, but was surprised to see that the actions were all added twice; i guess the tool initializations handle adding the actions themselves. I hope you saved a copy of what you did first. In CMF 1.5 all tools come with hardcoded initial settings. The handlers have to purge those settings and to add the actions from the profile. If you saw the actions added twice you forgot to clear the actions before doing the right thing. okay, no prob. i'll re-add that code, purging the appropriate actions first. i'm guessing the actions from all of the action providers need to be removed, regardless of whether or not the action providers are mentioned in the new profile. thanks for your help, -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: GenericSetup-based installation backport mostly complete
yuppie wrote: Hi Rob! Rob Miller wrote: i managed to get the lion's share of the GenericSetup-based installation backported to the 1.6 branch tonight. the unit tests need to be fixed up, and i haven't done anything with the CMFTopic extension profile yet, but it is possible to add a functional CMF site TTW. i'll work on getting the tests to pass and the CMFTopic profile working later this week. Great! this is my first foray into working directly on the CMF, please let me know if i miss anything w.r.t. dev process, documentation, etc. additional eyes on the changes i've made also appreciated. 1.) Please subscribe to the CMF-checkins list. This way your checkins will show up in that list and additional eyes can see them. urgh. i have to subscribe? i use gmane to follow all of the lists... *sigh* 2.) Please set svn:keywords Id on new python files. /me reads svn docs to learn about svn:keywords. If you copy files from an other branch, it's better to use svn copy. That preserves the history and svn properties. ah, right. will do. 3.) I'm a bit surprised how much of the TypesTool changes you ported back. all i did was move the FTI factory methods out of the TypesTool class and into the module. this makes it possible for the FTIs to be added to the types tool using the regular GenericSetup.utils.ObjectManagerHelpers mechanism, otherwise Factory-based Type Information won't exist in Products.meta_types. i did this because i'm trying to match CMF trunk's site creation mechanisms as much as possible. it's possible (probable, even) that there are side effects that i'm missing here, though. And that PortalGenerator is gone. Those changes potentially break products that work with CMF 1.5. yes, i guess this can be put back in. 4.) At least CMF 2.0 TypesTool and ActionsTool have modifications that make it impossible to use the CMF 2.0 handlers for CMF 1.5 code. I guess you have to modify CMFSetup and use some CMF 1.5 handlers to get everything working. i've got all this working, or at least i think i do. are the TypesTool changes the ones i was mentioning above? for the ActionsTool, creating actions as full blown objects of course isn't working. all i had to do to get this working, though, was to remove some code from CMFCore.exportimport.actions.ActionsToolNodeAdapter. at first i modified this code to actually add actions to the action providers in the old manner, but was surprised to see that the actions were all added twice; i guess the tool initializations handle adding the actions themselves. i might be missing some key points here, though. /me looks forward to being enlightened. -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: GenericSetup-based installation backport mostly complete
Rob Miller wrote: 1.) Please subscribe to the CMF-checkins list. This way your checkins will show up in that list and additional eyes can see them. urgh. i have to subscribe? i use gmane to follow all of the lists... *sigh* You can subscribe and then change the settings to receive no mail. 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: GenericSetup-based installation backport mostly complete
Florent Guillaume wrote: Rob Miller wrote: 1.) Please subscribe to the CMF-checkins list. This way your checkins will show up in that list and additional eyes can see them. urgh. i have to subscribe? i use gmane to follow all of the lists... *sigh* You can subscribe and then change the settings to receive no mail. thanks. done. -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
