The tools-as-utilities changes seem to run fine, but so far there is no
easy way to manage the tool registrations in the local site manager.
The site manager has no UI for inspecting or manipulating registrations,
so I tried to use GenericSetup:
While importing settings seems to work without problems, the exports are
broken. Instead of the tool path (object attribute) the handler exports
the tool class (factory attribute).
Trying to figure out how to fix this, I stumbled over several issues:
Problem: Only setup handlers for Zope core objects should ship with
GenericSetup. The components handler was meant to be a handler for any
IComponentRegistry. But registering tool like objects doesn't really
work with the Zope core site manager. The tests are currently lying
about this. In fact this feature depends on five.localsitemanager.
Solution: Hope that the dependencies are a temporary problem and Zope
2.11 will ship with five.localsitemanager. Fix the handler to work with
five.localsitemanager and don't support the object attribute for other
Problem: The code that supports the object attribute assumes that the
parent of the setup tool is the local site object linked to the site
manager. This violates the contract of the setup adapter and makes the
handler useless for sub-sites.
Solution: five.localsitemanager is an ObjectManager, getSiteManager
returns the wrapped site manager. Get the site by acquisition, not from
the setup context.
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.
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.
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 '/'.
I guess that's enough for now. I still have not figured out
http://mail.zope.org/pipermail/zope-cmf/2007-March/025739.html, so I
still might miss something important for resolving these issues.
Writing this list doesn't mean I volunteer to fix these issues. Maybe
the people who contributed that code can fix it?
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests