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.


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 :-)



Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to