[Zope-CMF] Re: tools, utilities, and getToolByName

[Rocky]

On Apr 22, 11:45 am, Martin Aspeli <optil... at gmx.net> wrote:
> So are we saying we need a bugfix/monkey patch to Five?

No.


> By "not using five.lsm" I meant "don't do the automatic acquisition
> wrapping".

Great.  And I agree with this.  As the main focus of five.lsm was to
support nested ISite's, not do do the aq wrapping (this was an
afterthought).


> I think I still don't quite understand why five.lsm breaks "normal" Zope
> 3 site managers, but I was under the impression that if we kept on using
> such "normal" site managers ourselves, it should "just work". I didn't
> realise Five needed its own implementation.

Each site manager needs to have it's __bases__ set in order to be able
to chain component lookup requests (ie not found in the current site?
look at the nearest site going up according to containment).  Zope 3
normally sets this based on checking on __parent__ and all that
ILocation stuff.  Five needs one that knows to check aq.  Enter
five.lsm.  Before five.lsm, Five's very basic ISite support meant that
if if you asked the current Site for a component and none was found,
it wouldn't bother asking up the tree to other site managers.  Which
means if you have a CMF portal instance (which is now an ISite) and
then created a subfolder and made it an ISite so that you could
override some random utility... then when you're in that subfolder and
do a lookup for a standard utility that might be provided by the
portal, it would return None because this subfolder site manager isn't
smart enough to ask the portal.

Anyways, this issue has been discussed quite a bit on the mailing
lists.  It's a very serious issue to the usability of component
registries / site managers.

- Rocky