[Zope-CMF] Re: GenericSetup extension profile import step
mis-feature
yuppie
y.2007- at wcm-solutions.de
Tue Jul 31 08:33:12 EDT 2007
Hi!
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
> dependencies)
>
> "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?
Cheers,
Yuppie
More information about the Zope-CMF
mailing list