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
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
