Hanno Schlichting wrote:
Problem: The export handler uses registeredUtilities(). Tools looked up
that way are not acquisition wrapped, object paths can't be found.
Solution: Use getUtility() for each registered utility.
The real issue here is that five.localsitemanager does not return
wrapped utilities in all cases. This has been become apparent when you
have a nested site manager which is not based on five.lsm. You get
unwrapped utilities then in all cases. Onces this is fixed in five.lsm
the export handler should work.
+1, at least in the long run. If we don't have soon an improved version
of five.localsitemanager, I still think using getUtility() makes sense
as a temporary workaround.
Problem: The re-wrapped tools returned by five.localsitemanager are
always wrapped in the site root. We don't know the actual path of the tool.
Solution: Support only tools in the root of the local site (or
sub-site), no tools in normal subdirectories.
OK, this means adding a bit of documentation and removing the half-baked
support for registering tools in subfolders, right?
Problem: If modified as proposed, the handler still has problems
exporting the ISiteRoot utility. The exported object path is empty, but
import expects '/'.
Solution: Support '' as well for import, deprecating '/'.
Sounds fine. Should we deprecate the whole '/' in all cases then, as we
only support registering objects in the same directory anyways?
I cannot promise to look at those things shortly, but should find some
time once we have the Plone 3 beta out, which means probably in two
weeks or so. Of course any help is most appreciated :)
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests