Martin Aspeli wrote:
> yuppie-2 wrote:
>> Martin Aspeli wrote:
>>> I've used this here now:
>>> I'm basically using it to modify a FTI that I know exist (the use case
>>> is to modify, explicitly, not add).
>>> It may be nice if something like this was generalised a bit further and
>>> placed in a component of its own?
>> I'm not sure if this is the way to go.
>> My example code showed how to apply a single XML file. Your example
>> includes a small but complete extension profile in the 'setup'
>> directory. I guess it would be easier to use a DirectoryImportContext
>> and import step handlers for that profile instead of implementing
>> similar stuff in update* methods.
>> Unfortunately I can't point you to code that works this way.
> All I did was remove the hardcoding of a filename and a product module from
> your code. In this case, I'm not interested in the rest of the extension
> profile mechanism (e.g. knowing which profiles are applied, doing an
> import-all relative to an active profile), only in defining a new FTI or
> workflow with a more natural syntax.
> Of course, the wrapping in an updateXYZ() method is sub-optimal because it
> could infer what it was working on by walking the directory tree as I assume
> the regular GS machinery does. That degree of generalisation (point it at a
> directory, parse the data in the files, modify the ZODB accordingly) would
> be more useful of course - it was just a bit beyond my knowledge of GS :)
I don't know what's the best solution for your use case. But you are
moving in a direction where using DirectoryImportContext might become
useful, not just overkill.
The code that walks the directory tree (utils.importObjects) depends on
a more rich context that implements not just ISetupEnviron, but also
IImportContext. DirectoryImportContext implements this interface for
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests