yuppie-2 wrote: > > Martin Aspeli wrote: >> I've used this here now: >> >> http://svn.plone.org/svn/collective/borg/trunk/examples/charity/ >> >> 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 :) Martin -- View this message in context: http://www.nabble.com/Abusing-GenericSetup-during-traditional-installs-tf2014550.html#a5682770 Sent from the Zope - CMF list2 forum at Nabble.com. _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests