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...
___
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 )
