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

[Kapil Thangavelu]

On Sun, 22 Apr 2007 10:02:25 -0400, Rocky <rocky at serverzen.com> wrote:

> 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.

although it should be noted, all you really need is a utility function  
that walks the context chain to give you a set of bases that can be used,  
when instantiating a new persistent components. its just initialization  
sugar. it doesn't actually need a five.lsm subclass dependency. thats just  
how we've spelled convenience.

-kapil