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

[Hanno Schlichting]

Hi,

yuppie wrote:
> 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:

I think this is on the todo-list for five.localsitemanager. Adding
support for a ++etc++site view or so, which works similar to the one in
Zope3.

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

I like solutions based on hope ;) Limiting support for the object
attribute to IObjectManagerSites makes sense to me.

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

Sounds fine.

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

> 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 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?

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 :)

Hanno