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:

Issue 1:

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 site managers.

Issue 2:

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.

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.

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.

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 '/'.

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

Reply via email to