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
