> You might have noticed already that GS has two sub-frameworks, one for
> configuration handlers and one for content handlers. My answer just
> applies to configuration handlers:
> The adapters are explicitly made for using them outside the GS tool.
> Body adapters are multi-adapters for ISetupEnviron and the interface of
> the object, e.g. IActionsTool for the Actions Tool.
> ISetupEnviron is a small interface that provides a generic logger object
> and the mode in which XML files are applied. GS doesn't ship with a
> class that implements only this minimal interface.
> So if you have the XML body in 'body', the tool in 'obj' and the
> SetupEnviron in 'environ', these two lines are all you need:
> importer = queryMultiAdapter((obj, environ), IBody)
> importer.body = body
My understanding of GS internals are fairly patchy, but that seems sensible.
Is there an example of this with a bit more context, i.e. one that actually
loads an XML file and runs the import step for that whole file?
> There are other solutions if your XML is part of a registered profile.
Do you just mean "better" or "incompatible"? I guess in this case they
wouldn't be part of a profile, but perhaps they could be and just never run
in the normal portal_setup way. Or would having them registered invalidate
or break a manual import mechanism?
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