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 _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See http://collector.zope.org/CMF for bug reports and feature requests
