[Zope-dev] more on stacked component registries

[Chris Withers]

Philipp von Weitershausen wrote:
>> Sure it is, I'm talking about what basically happens with nested site 
>> managers. The problem is that the current nesting implementation seems 
>> predicated on zodb-like persistence. I'm looking at storing all 
>> "data", including site managers, in a relational database. The actual 
>> folder structure should remain as static as it does with zodb...
> 
> Well, each place in the ZODB will still know that it is a site, i.e. 
> that it has a site manager associated, right? 

Aside from the fact that I'm not using ZODB, yes, that's true. But I'd 
like to explore not having such a rigid hierarchical structure. In 
particular, I want to support multiple traveral paths to getting to a 
site manager, ie: objects with multiple "parents" where the overal 
registry at any point is made up of the registries traversed through 
rather than limiting that traversal to be up one "containment path".

 > Because then you can
> easily track down the same registry over and over again.

I'm not sure I follow you 100%, but yes, something like that ;-)

> You could 
> probably even register them as global utilities for easy access (like 
> it's done with other registries, e.g. the ones from z3c.baseregistry).

Not sure what you mean...

>>> I think it would be easier to turn on/off registrations by using 
>>> dynamically directly provided interfaces (via a proxy) or use security.
>>
>> Not sure what you mean by either of these...
> 
> You can change which adapters are found for a particular object by 
> applying marker interfaces.

Eww...

>> Yeah, but this is what happens more static-ly with the existing site 
>> managers, right?
> 
> I'm not sure how the ZODB-based registries do caching. 

I had to stop looking before my head exploded, but it looked like they 
based their caching on a static "containment path" and recomputed if the 
registry was "moved".

>> Well okay, one registry per thread... would that work?
> 
> So you would basically copy the whole global registry to a thread-local 
> variable at the beginning of the request,

Well, hopefully we could come up with something a little cleverer than 
that ;-)

> then modify it and then throw 
> it away afterwards? Doesn't sound very clever to me...

..but yes, basically modifying a pristine "global registry" during the 
traversal (nb: not request, there may be many traversals during a 
request) and then bin the results when the traversal is garbage collected...

I'm trying to get the code working with just a global registry for now, 
as I think it'd be easier to try and explain what I'm after with some 
code to show you :-)

cheers,

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
            - http://www.simplistix.co.uk