[Zope-CMF] Re: [CMF 2.1] PersistentComponents is not enough

[Philipp von Weitershausen]

On 8 Jan 2007, at 17:30 , Rocky Burt wrote:
> On Mon, 2007-08-01 at 15:40 +0100, Philipp von Weitershausen wrote:
>> Using PersistentComponents() as the component registry (a.k.a. site
>> manager) for local sites isn't enough. That's because it doesn't
>> understand about containment hierarchies. Imagine this folder  
>> hierarchy:
>>
>> /root_site/
>> +  cmf_site/
>>     +  somefolder/
>>     +  anotherfolder/
>>     +  sitefolder/
>>     +  +   stuff_in_here
>>
>> "cmf_site" is obviously a site. Let's say "root_site" and  
>> "sitefolder"
>> are also sites (yes, Zope3-style sites can be nested). That's not  
>> to say
>> that sitefolder is another CMF Site, it's just a Zope3-style ISite
>> (regular zope 2 folders can be sites in Zope 2.10).
>>
>> You would expect component lookup at "stuff_in_here" to
>> * first lookup stuff in "sitefolder",
>> * then in "cmf_site",
>> * then in "root_site",
>> * and finally in the global registry
>>
>> If you use PersistentComponents() this won't automatically happen!
>
> This is a major problem.  This means that if someone is traversing to
> sitefolder and some view code calls getUtility(ICatalog) (instead  
> of the
> deprecated getToolByName(context, 'portal_catalog') then the lookup  
> will
> fail if sitefolder doesn't provide the utility (and it probably won't
> provide it).

Right.

>> Since Five is feature-frozen and new stuff should be added in Python
>> packages anyway, my suggestion is to put this thing into a
>> five.localsitemanager package which would then be used by CMF 2.1,  
>> Plone
>> 3, etc.. It could possibly be included into the Zope 2.11 release.
>
> This would be the best approach (creating five.localsitemanager) in my
> opinion.  But, this means CMF will either require (or distribute)
> five.localsitemanager.  (Plone will have the same issue)  I'm not sure
> where we stand on this.

Me neither. I'd just like to avoid that either CMF or Plone or both  
grow their own implementations. The problem is completely generic to  
Zope 2, hence we should have an independent package. If we must  
(because Plone and CMF havne't figured out their egg story yet), then  
I guess we can make a Five 1.6 (which would be a fork of Five 1.5;  
the current Five trunk has no version number anymore as it'll be  
integrated into the Zope trunk).

>> I'd like to avoid making a Five 1.6.
>
> +1