On Sun, 22 Apr 2007 10:02:25 -0400, Rocky <[EMAIL PROTECTED]> wrote:

On Apr 22, 11:45 am, Martin Aspeli <[EMAIL PROTECTED]> wrote:
So are we saying we need a bugfix/monkey patch to Five?


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

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

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.

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to