On 5 Feb 2008, at 19:23 , Chris Withers wrote:
Stephan Richter wrote:
On Tuesday 15 January 2008, Chris Withers wrote:
For what I'm after, I need to have a more dynamic buildup of registrations based on which objects have been traversed through. Right. I think the component architecture is not really made for this.
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? Because then you can easily track down the same registry over and over again. 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).
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.
- stack the registries up during travesal in some way. I guess this would be a variant of what's done now with current nested registries. Is this feasible? Will there be performance problems? I think the performance would decrease, because caches cannot be built up. Also, you then must be able to access this custom registry. Remember, this must be all in memory, because of thread- safety!
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 strongly suspect that their caches may be garbage-collected at any time after the request is over. Also, let's not worry about premature optimizations right now...
- use one global registry and add/remove registrations during traversal as necessary. How fast is registration/unregistration of adapters and the like? How many adapter adds/removes at a traversal node would it take to really slow things down? You cannot do this; it is not thread-safe.
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, then modify it and then throw it away afterwards? Doesn't sound very clever to me...