[Zope-CMF] [dev] GenericSetup and five.localsitemanager: managing tool registrations

[yuppie]

Hi!


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?


Cheers,

	Yuppie