Re: [Zope-dev] more on stacked component registries
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 )
Re: [Zope-dev] more on stacked component registries
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 )
Re: [Zope-dev] more on stacked component registries
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... 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... - 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? - 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? 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 )
Re: [Zope-dev] more on stacked component registries
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. I think it would be easier to turn on/off registrations by using dynamically directly provided interfaces (via a proxy) or use security. It would help me, if you could describe your actual use case. I can see two ways to approach this: - 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! - 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. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
[Zope-dev] more on stacked component registries
Hi All, Happy New Year, etc :-) Been working more on this stuff so finally have some more questions... Philipp von Weitershausen wrote: Okay, but where's this code? (ie: what .py should I look at for the local registry implementation) zope.app.component.site contains the LocalSiteManager class. This is the persistent component registry used in Zope 3's standard ISites. It inherits from zope.component.persistentregistry.PersistentComponents which in turn inherits from zope.component.registry.Components. The latter has the dynamic __bases__ property. You'll see that the setter really just sets the __bases__ on its internal adapter and utility registry. Both of those (sic!) What does this sic mean? are some sort of subclass of zope.interface.adapter.BaseAdapterRegistry which has the handling for cascading lookups through its __bases__ property. Actually, it doesn't. The handling of __bases__ appears to be done in the functions of the mysterious zope.interface.ro module. (that ro thing takes the biscuit for obscure naming :-( ) Am I off base here? If so, more info please! :-) Anyway, another question I have relates to the way in which registries and sub registries are stacked up. Am I right in assuming the current code is designed around a static setup of adapter registries which the deeper registries cache the results of the registries higher up? For what I'm after, I need to have a more dynamic buildup of registrations based on which objects have been traversed through. I can see two ways to approach this: - 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? - 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? I still feeling like I'm grasping a bit here but I hope you guys can help! 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 )
