Hi Hanno!

Hanno Schlichting wrote:
yuppie wrote:
Issue 3:

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.

Issue 4:

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?


Issue 5:

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

Reply via email to