Jens Vagelpohl wrote:
Hash: SHA1

On 10 Apr 2007, at 10:30, yuppie wrote:
Currently non-five.lsm site managers don't work in CMF, see this thread:

Proposed solutions:

a) reverting most 'tools as utilities' changes (Kapil)

I'd like to mention this is not just Kapil proposal. Other people at the sprint were involved in the discussion that lead to Kapil's mail. Actually, that mail was written and reviewed by multiple persons.

b) supplementing five.lsm (Hanno)

I am not sure if the following has been made clear so I'll try to explain it again.

The current implementation of zope.component.registry.Components accesses the internals of the registries instead of using external APIS (I suspect this is for performance reasons). This implies that there are only two ways of implementing automatic acquisition-wrapping of utilities :

- patch the Z3 registry itself in order to make all registries acquisition-aware as done currently in Plone 3.0

- have all local component registries (including five.lsm) derive from a common mixin class that implements 'queryUtility', 'getUtility', 'getUtilitiesFor' and 'getAllUtilitiesRegisteredFor' methods.

This is easy to do (I had an implementation in 20 mins).

However, in order to use with five.lsm components that are valid in Z3, we would need to "fix" :-S them with conditional imports.

The above were facts, lets move to my opinion ;-)

Both solutions do not smell very good but it would not be the first time we live with bad smells.

However, my main concern regards the strategy used to get rid of tools in content space. I think that we inverse the order of things to do : we try to get rid of getToolByName API before getting rid of dependency on acquisition.

Today, we are far away enough from the removal of tools from content space that we need the acquisition magic in five.lsm (correct me if I am wrong) to make most CMF tools work correctly.

We first need to fix the most fundamental tools so that they can be used without acquisition (iow as pure utilities). When they are fixed, we can switch their calls from the getToolByName proposed in (a) to the getUtility we all wish.

By fixing the implementation/use of those tools, we will have explored most of the consequences of the 'migration'. We can at that moment deprecate the getToolByName API as we will be able to give advices and patterns how to fix, to people that will still be relying on getToolByName acquisition wrapping.

c) improving five.lsm (Rocky)
AFAICS this is an other attempt to resolve the same issue:

We have to decide which way to go. I prefer c) if it works,  b) otherwise.

Same here. c) first, then b). Strongly against a).

Before the sprint, I have spent more than one day exploring (c) Rocky's proposal and did not get to anything satisfactory. The zope.interface.adapter.AdapterRegistry would need to be acquisition-aware. IOW, we would once again pollute Z3.

I explained here above why (b) is not a solution I like and why I support (a).

Could you explain why you are strongly against (a) ?


Godefroid Chapelle (aka __gotcha)- BubbleNet

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to