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...
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...
- 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
- 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?
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -