Martin Aspeli wrote:
> Jens Vagelpohl wrote:
>> Let's talk about something fun instead, like that wrapping issue. I 
>> personally can't see any problem with Hanno's suggestion for a 
>> "special" component registry and automatically wrapping those tools 
>> that are in the little registry. I'm just concerned that this 
>> registry is being abused a little - it really was only meant for 
>> getToolByName to construct a more meaningful deprecation message 
>> where the interface name is displayed, looked up from the tool ID. It 
>> seems Hanno's suggestion forces it to be kept around even after 
>> getToolByName has gone away in the distant future.
> Why not do it a more Zope3 ish way:
> class ICMFTool(Interface):
>    """Marker for any CMF tool"""
> and then in the subclass of the local component registry:
> local_utility = ....
> if ICMFTool.providedBy(local_utility):
>     local_utility = local_utility.__of__(context)
> or so. We could mix ICMFTool into the interface hierarchy for CMF's
> tools, or declare it explicitly on each interface. We could even be more
> specific, and call it IAcquisitionDependentTool and only use it where aq
> is truly needed.

That's of course a better idea. I would prefer the more general name
IAcquisitionDependentUtility, as it might be used by code that's not a
tool in the first place. There's nothing tool specific about the
interface or its usage. All that the interface should promise is that
the object providing it, can be AQ-wrapped.

Right now I would let all existing CMF tools implement that interface,
so we would be on the safe side. In a later release we can revisit this
and see if some tools don't need Acquisition to work properly.

If I'm not mistaken this should let us remove all the manual AQ-wrapping
again (sorry Jens for the premature patch) and thus impose no extra pain
on add-on developers.

I'm starting to like this idea ;)

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to