> 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 :)
View this message in context:
Sent from the Zope - CMF list2 forum at Nabble.com.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests