Martin Aspeli wrote:
yuppie-3 wrote:
The proposed solution doesn't work:

The ImportStepRegistry is not only used for imports - it is also used for creating new 'import_steps.xml' files for exports.

Exported profiles are always base profiles, they have to specify *all* import handlers used for creating the site.

Right, that's fine. I think the current export functionality is right.
However, the current *import* functionality for extension profiles is
arbitrary and unpredictable.

What if we stored in the import step registry:

 - The setuphandler to call
 - The base or extension profile it came from

For an export operation, you just take the union of all the steps
(de-duplicated, of course).

For an import operation, you run:

 - All steps that came from the current base profile
 - All steps that came from explicit, transitive dependencies of the current
base profile (provided we get support for declaring profile dependencies)


Base profiles have per definition no dependencies. No?

 - All steps explicitly defined in the extension profile being run
 - All steps explicitly defined in transitive dependencies of the extension
profile being run (provided we get support for declaring profile

"Transitive" here means that if A depends on B and B depends on C, we run
steps from A, B and C.

I can see two ways to specify available import steps:

1.) 'import_steps.xml' is used as an index of available import steps. That's the way it was used before extension profile support was added to CMFSetup. It requires to maintain a lot of redundant information and a way to identify and remove duplicate steps for exports.

Yes... this sounds like what I am talking about above?

Not really. You are mixing both ways: Some import steps come from the registry (or are looked up in other profiles?), some from 'import_steps.xml'.

2.) The files in the profile determine which import steps are available. This is the current behavior, but further changes would make this more clear: Getting rid of 'import_steps.xml', using a global handler registry instead. And adding new code that checks if a step is available without actually running it.

I'm not sure how this gets any clearer... e.g. how does the author of an
extension profile for an add-on product ensure that the steps he needs are
in the registry?

The author of the add-on product is not responsible for this - just like he is not responsible for registering all adapters or utilities used by his product.

The author of the setup handler should add a ZCML file that registers the setup handler.

To me (and for a long time when I was using this blissfully unaware)
extension profiles really are separate entities that will generally be
applied in an uncontrolled order (unless we get explicit dependency support,
which would be really great). Flag files (be they empty boolean switches or
XML files with processing instructions) feel like a dirty way of dealing
with this unpredictability.

Why is it more explicit to have a 'flag' import step in 'import_steps.xml' or in 'import_steps.xml' of a dependency than a flag file in the current profile?



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

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

Reply via email to