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