[Zope-CMF] Re: GenericSetup doc
Rob Miller wrote: the 'upgradeStep' directive as florent described in his blog entry is also a good idea, i think. i prefer the version number approach for changes that can be cleanly represented in the setup profile, but i'm sure there will be things that need to happen that the setup profile won't be able to capture effectively. Here's an example of its use: You have a site with News documents and PressRelease documents. At some point, you decide to merge the two types into just News. Updating the profile is easy, but you'll still have to scan you database documents and modify the portal_type of the former PressReleases, and maybe adjust some attributes. That's what upgrade steps are for in CPS. 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: GenericSetup doc
hi all! and great document, florent... thanks! yuppie wrote: Tres Seaver wrote: The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. I first was confused by these sentences because currently import_steps.xml just registers handlers which might be used by many profiles. So reading "import step" I thought you meant the import handler. But if an "import step" represents a subset of a specific profile this starts to make sense. i think i understand, but i'm not 100% sure. i'm going to give an example of how i think this would work, hopefully someone will confirm or correct me. say i have a base profile that includes a given toolset.xml file. later, i develop for my product a new custom tool. i would add my tool to the toolset.xml file, and then update the version number of the toolset step in the import_steps.xml. this would (if it were working) indicate to the setup tool that this import step was now out of date in any prior installations, allowing me to trigger this import step (and any others that were out of date) to be re-executed. is this correct? if it is, i definitely like the idea, but think maybe it can be improved upon a bit. i'd rather see the version numbers actually live in the step definition file, for instance... the toolset import step's version number would live in the toolset.xml file, so i don't have to remember to open the import_steps.xml file to keep the versions current. also, version tagging the import step itself may be too broad a stroke at times. in cases where an action has changed on a type info declaration, you'd really want to be able to just update a version number on that particular type's description. this would require the importer itself to be smart enough to check for versions and compare them against a record of the versions at original import time. this type of behaviour could be very useful for content importers, as well. the 'upgradeStep' directive as florent described in his blog entry is also a good idea, i think. i prefer the version number approach for changes that can be cleanly represented in the setup profile, but i'm sure there will be things that need to happen that the setup profile won't be able to capture effectively. -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 doc
Hi Tres! Tres Seaver wrote: Tres Seaver wrote: - The "upgrade" feature you talk about for CPS sounds a bit like what the "version" attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were "newer" (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the "version" UI (or maybe both?) I have to admit that I never understood why import steps have a "version" attribute. And I still don't understand that concept: Does that mean each upgrade needs its own import steps? The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. I first was confused by these sentences because currently import_steps.xml just registers handlers which might be used by many profiles. So reading "import step" I thought you meant the import handler. But if an "import step" represents a subset of a specific profile this starts to make sense. Some version of the setup tool (maybe never publicly released) tracked the 'version' last installed for each step, and would show you the steps which were out-of-date, or had never been installed, in a way which made them easy to distinguish. I think there was a convenience button which ran only such steps, as well. I don't think I ever saw a version that implemented this. And I'm not sure if GenericSetup should implement this. But at least I understand now why import steps have a "version" attribute. 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 doc
Hi Jens! Jens Vagelpohl wrote: On 25 Jan 2006, at 10:42, yuppie wrote: BTW: In which checkin list do GenericSetup checkins show up now? They show up in the generic zope checkins list, where all the Zope checkins themselves go. Well. Not exactly true. The Zope checkins go to zope-checkins (=gmane.comp.web.zope.cvs) You are right that GenericSetup checkins go to the generic checkins list, but that is zope-cvs (=gmane.comp.web.zope.public-cvs) This can be changed to point at another list (or additional lists), but there would be drawbacks. Sending them to the CMF list would mean people who want to use it outside of the CMF would have to subscribe to the CMF list. Sending them to the generic list and the CMF list would mean duplicates for a lot of people. I'm not really happy with the current situation but as you mention all alternatives have also their drawbacks. So I'll subscribe to yet another Zope checkin list... Thanks! 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 doc
> Hi Tres! Hi Florent! > > > Tres Seaver wrote: >> >> Florent Guillaume wrote: >>> Here is some doc I wrote about GenericSetup: >>> >>> http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2006_01_24_genericsetup-for-cps-cmf >> >> A very nice writeup. Could we get it (or the non CPS-specific bits) >> added to docs for GenericSetup? > > I just added a 'doc' directory and checked in the fragments of > documentation I had in my sandbox. Everybody is welcome to change and > improve those docs. Florent's writeup would be indeed a valuable > contribution. > > BTW: In which checkin list do GenericSetup checkins show up now? http://mail.zope.org/mailman/listinfo/zope-cvs >> A couple of points: >> >> - The "selective export" think *used* to work; I didn't know it was >> broken. I used it frequently in the project which spawned the >> move from CMFSetup to GenericSetup. > > Florent writes about *incremental* exports, not about *selective* > exports. Selecting specific export steps should still work. Ah, OK. I was confused by the "which XML files" phrase. >> - The "upgrade" feature you talk about for CPS sounds a bit like what >> the "version" attribute was originally for on import steps: in the >> original implementation, the tool knew what versions of import steps >> had been run in the past, and you could see which steps were "newer" >> (or had never been run) on the import view. I don't know where that >> feature went. It seems as though we should either add your update >> feature, or else resurrect the "version" UI (or maybe both?) > > I have to admit that I never understood why import steps have a > "version" attribute. And I still don't understand that concept: Does > that mean each upgrade needs its own import steps? The use case was that, over time, an import step might be updated. If you had installed your site before the update, then your configuration might also need to be updated. Some version of the setup tool (maybe never publicly released) tracked the 'version' last installed for each step, and would show you the steps which were out-of-date, or had never been installed, in a way which made them easy to distinguish. I think there was a convenience button which ran only such steps, as well. Tres. ___ 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: GenericSetup doc
On 25 Jan 2006, at 10:42, yuppie wrote: BTW: In which checkin list do GenericSetup checkins show up now? Hi Yvo, They show up in the generic zope checkins list, where all the Zope checkins themselves go. This can be changed to point at another list (or additional lists), but there would be drawbacks. Sending them to the CMF list would mean people who want to use it outside of the CMF would have to subscribe to the CMF list. Sending them to the generic list and the CMF list would mean duplicates for a lot of people. 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: GenericSetup doc
Hi Tres! Hi Florent! Tres Seaver wrote: Florent Guillaume wrote: Here is some doc I wrote about GenericSetup: http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2006_01_24_genericsetup-for-cps-cmf A very nice writeup. Could we get it (or the non CPS-specific bits) added to docs for GenericSetup? I just added a 'doc' directory and checked in the fragments of documentation I had in my sandbox. Everybody is welcome to change and improve those docs. Florent's writeup would be indeed a valuable contribution. BTW: In which checkin list do GenericSetup checkins show up now? A couple of points: - The "selective export" think *used* to work; I didn't know it was broken. I used it frequently in the project which spawned the move from CMFSetup to GenericSetup. Florent writes about *incremental* exports, not about *selective* exports. Selecting specific export steps should still work. - The "upgrade" feature you talk about for CPS sounds a bit like what the "version" attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were "newer" (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the "version" UI (or maybe both?) I have to admit that I never understood why import steps have a "version" attribute. And I still don't understand that concept: Does that mean each upgrade needs its own import steps? 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 doc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florent Guillaume wrote: > Here is some doc I wrote about GenericSetup: > > http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2006_01_24_genericsetup-for-cps-cmf A very nice writeup. Could we get it (or the non CPS-specific bits) added to docs for GenericSetup? A couple of points: - The "selective export" think *used* to work; I didn't know it was broken. I used it frequently in the project which spawned the move from CMFSetup to GenericSetup. - The "upgrade" feature you talk about for CPS sounds a bit like what the "version" attribute was originally for on import steps: in the original implementation, the tool knew what versions of import steps had been run in the past, and you could see which steps were "newer" (or had never been run) on the import view. I don't know where that feature went. It seems as though we should either add your update feature, or else resurrect the "version" UI (or maybe both?) 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 iD8DBQFD1ya1+gerLs4ltQ4RApR8AJ9oljKrEqB/KfPNCE6ZqeDJBc9oKQCfb5RQ PtAsPq+oXvv922CqeykiqNY= =lmWi -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
