Hi Rob!
Rob Miller wrote:
yuppie wrote:
Rob Miller wrote:
- allow extension profiles to specify which of the base profile's
import steps they depend on, so that only these can be run, instead
of the current situation where, AFAICT, you have to either run them
all or manually examine the profile and select the steps to run
- draw a more clear distinction between the base profile and the
extension profiles. instead of having the extension profiles
piggy-backing on the base profile, extension profiles would
explicitly define all of their own import steps, so that they can be
applied cleanly on top of existing sites w/o becoming quite so
muddled w/ the default configuration. this would also make it easier
to implement an uninstall process that would remove the extension
profile from the site.
These solutions will create new problems regarding the procedure for
exports and re-imports.
can you elaborate on this so i can understand the issues? it seems
that, for the first of these two options at least, it wouldn't be hard
to make it work w/o actually changing any current behaviour.
Sorry. I have to differentiate more:
The problems with the first approach are different ones. First it is a
BBB issue: All existing extension profiles have to provide that
additional information before we can rely on it. And second there are
different opinions regarding the future of setup steps: IMHO they should
not be part of any profile and registered globally instead.
Regarding the second approach: Let's use the action handler as example.
The export step for actions is responsible for *all* actions, not just
those added by a specific profile. It would not make sense to export all
existing action import steps because the new profile has only one
actions.xml. A snapshot is a new profile and needs a new action import
step. We either have to collect all the import steps from each profile
we ever loaded or we have to remove import steps if they are no longer
needed. But we can't remove all import steps of non-active profiles
because the step_registries handler needs them for writing exports.
I don't say these issues can't be resolved, but I can't see the benefit
of the additional complexity. Why would this make it easier to implement
an uninstall process?
Cheers,
Yuppie
_______________________________________________
Zope-CMF maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
