Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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:
http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html
Proposed solutions:
a) reverting most 'tools as utilities' changes (Kapil)
http://mail.zope.org/pipermail/zope-cmf/2007-March/025817.html
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)
http://mail.zope.org/pipermail/zope-cmf/2007-March/025822.html
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
http://dev.plone.org/plone/browser/plone.app.kss/trunk/plone/app/kss/five_lsm_patch.py
- 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:
http://mail.zope.org/pipermail/zope-cmf/2007-March/025708.html
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) ?
jens
--
Godefroid Chapelle (aka __gotcha)- BubbleNet http://bubblenet.be
_______________________________________________
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
