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.


Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to