Previously Ross Patterson wrote:

Chris Withers <chris@simplistix.co.uk> writes:

...

Hi All,

Does the component architecture support un-registering adapters and the like?

...

From zope.component.interfaces:

class IComponentRegistry(interface.Interface): """Register components """ <snip...> def unregisterUtility(component=None, provided=None, name=u''): """Unregister a utility <snip...> def unregisterAdapter(factory=None, required=None, provided=None, name=u''): """Register an adapter factory <snip...> def unregisterSubscriptionAdapter(factory=None, required=None, provides=None, name=u''): """Unregister a subscriber factory. <snip...> def unregisterHandler(handler=None, required=None, name=u''): """Unregister a handler. <snip...>

That'll do it, I think. :)

You need a bit of extra information that is not in the interface: where to find the registry. To get the global registry you can do this: from zope.component.globalregistry import base as base_registry Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.

----- "Philipp von Weitershausen" <philipp@weitershausen.de> wrote:

Wichert Akkerman wrote:

...

Previously Ross Patterson wrote:

...

Chris Withers <chris@simplistix.co.uk> writes:

...

Hi All,

Does the component architecture support un-registering adapters and the like? From zope.component.interfaces:

class IComponentRegistry(interface.Interface): """Register components """ <snip...> def unregisterUtility(component=None, provided=None, name=u''): """Unregister a utility <snip...> def unregisterAdapter(factory=None, required=None, provided=None, name=u''): """Register an adapter factory <snip...> def unregisterSubscriptionAdapter(factory=None, required=None, provides=None, name=u''): """Unregister a subscriber factory. <snip...> def unregisterHandler(handler=None, required=None, name=u''): """Unregister a handler. <snip...>

That'll do it, I think. :)

You need a bit of extra information that is not in the interface: where to find the registry. To get the global registry you can do this:

from zope.component.globalregistry import base as base_registry

I think you should use zope.component.getGlobalSiteManager() for this.

FWIW, I started documenting the complete API here: http://www.muthukadan.net/docs/zca.html Regards, Baiju M

On 25 Nov 2007, at 13:37 , Chris Withers wrote:

Philipp von Weitershausen wrote:

...

...

...

class IComponentRegistry(interface.Interface): I think you should use zope.component.getGlobalSiteManager() for this.

So getGlobalSiteManager returns a component registry?

Yes. It returns the one and only global registry.

If so, how come it's not called getGlobalComponentRegistry?

Because component registries used to be called site managers and we can't just change the API at this point anymore.

How do you set up nested registries? For example, if a certain area of a site should have a registry which overrides the global one, but only for that area, and should fall back on it if not adapter could be found?

You use sites. Sites are places (usually containers) in the component hierarchy that have (local) component registries associated with them. And yes, the name "site" is misleading, but again, we have it as legacy now. How to work with sites, how to set them up, etc. is all explained in my book. I'm sure you have a copy :) (Btw, this thread has nothing to do with the development *of* Zope and is therefore zope@zope.org or zope3-users@zope.org rather than zope-dev@zope.org material.)

Chris Withers wrote:

Philipp von Weitershausen wrote:

...

On 25 Nov 2007, at 13:37 , Chris Withers wrote:

...

Philipp von Weitershausen wrote:

...

...

...

class IComponentRegistry(interface.Interface): I think you should use zope.component.getGlobalSiteManager() for this.

So getGlobalSiteManager returns a component registry?

Yes. It returns the one and only global registry.

Am I right in thinking the global registry is _only_ used if no context is supplied?

No. One should never have to supply an explicit context.

...

...

If so, how come it's not called getGlobalComponentRegistry?

Because component registries used to be called site managers and we can't just change the API at this point anymore.

Well, getGlobalComponentRegistry could be added as an alternate spelling and people could be encouraged to use it ;-)

Feel free to submit a patch :)

There seems to be comments suggesting getSiteManager is deprecated, but maybe I'm not getting exactly what is being deprecated...

It's not deprecated at all. If it were, it would say so in the code and emit a deprecation warning when you try to use it.

...

...

How do you set up nested registries? For example, if a certain area of a site should have a registry which overrides the global one, but only for that area, and should fall back on it if not adapter could be found?

You use sites. Sites are places (usually containers) in the component hierarchy that have (local) component registries associated with them.

So, by "component heirarchy" I'm guessing you really mean "object hierarchy"

Yeah, sorry.

and by "Site" you mean "something implementing IComponentRegistry"?

No, something implementing ISite, which defines a setSiteManager and getSiteManager for setting and retrieving an IComponentRegistry.

I'm guessing the adapter to IComponentLookup is what implements the search up the object graph to find an IComponentRegistry?

Yes, but that's rarely used (only when you pass an explicit context which we almost never do). Normally, during traversal, an event subscriber reacts to ISites being traversed and remembers the site's component registry in a thread-local variable. getSiteManager() will then return whatever is in the thread-local variable, and therefore getUtility, getMultiAdapter, etc., will use that local registry.

If so, where do I find that adapter implementation(s)?

See zope.app.component (also for the subscriber stuff mentioned above).

...

And yes, the name "site" is misleading, but again, we have it as legacy now. How to work with sites, how to set them up, etc. is all explained in my book. I'm sure you have a copy :)

I do, and I'm very greatful for it...

...

(Btw, this thread has nothing to do with the development *of* Zope and is therefore zope@zope.org or zope3-users@zope.org rather than zope-dev@zope.org material.)

...however, I'm interested in the mechanics of how zope.component handles multiple component registries, in particular how registries are added to and removed from the set of registries that are searched hen looking for a component and some other bits and pieces.

Which is the *use* of Zope, not the *development* of Zope.

In short, if the current zope.component implementation already does what I want, or whether I need to do work on the development *of* it it order to get what I'm after...

...of course, I don't know exactly what I'm after yet, but I hope you'll bear with my questions in the meantime ;-)

On 26 Nov 2007, at 18:17 , Chris Withers wrote:

Philipp von Weitershausen wrote:

...

...

...

Yes. It returns the one and only global registry.

Am I right in thinking the global registry is _only_ used if no context is supplied? No. One should never have to supply an explicit context.

Surely that's only the case if you're using zope's traversal stuff?

Yup.

I'm guessing that if you are, you either need to stick with the one global registry or manage either ISites or IComponentLookup's yourself?

Not sure what you mean by "if you are".

...

...

...

...

If so, how come it's not called getGlobalComponentRegistry?

Because component registries used to be called site managers and we can't just change the API at this point anymore.

Well, getGlobalComponentRegistry could be added as an alternate spelling and people could be encouraged to use it ;-) Feel free to submit a patch :)

It's entertaining to get asked to submit a patch *and* told you're not doing anything that belongs on the -dev list in the same email ;-)

Touche ;)

...

...

There seems to be comments suggesting getSiteManager is deprecated, but maybe I'm not getting exactly what is being deprecated... It's not deprecated at all. If it were, it would say so in the code and emit a deprecation warning when you try to use it.

What's line 37 of component._api on about then?

# SiteManager API. This needs to get deprecated eventually. It says *eventually* :)

...

...

and by "Site" you mean "something implementing IComponentRegistry"? No, something implementing ISite, which defines a setSiteManager and getSiteManager for setting and retrieving an IComponentRegistry.

Are you sure you don't mean ISiteManager, which is marked as being deprecated and to be removed in 2007...

Yes, I'm sure I mean ISite.

If you mean a different ISite, where is it defined?

zope.app.component.interfaces. Well, it moved to zope.location.interfaces recently in order to reduce the amount of interdependencies between the eggs, but it's still available w/o deprecation from zope.app.component.interfaces.

(and I'm guessing there is an ISite somewhere, as I could find no definition of setSiteManager, but how does IComponentArchitecture's getSiteManager relate to that of ISite?)

zope.component.getSiteManager() will return whichever component registry is active. site.getSiteManager() will return the local component registry that has been associated with site (which provides ISite).

...

...

I'm guessing the adapter to IComponentLookup is what implements the search up the object graph to find an IComponentRegistry? Yes, but that's rarely used (only when you pass an explicit context which we almost never do).

I think I'm misreading the code in _api then. It looks to me that most things use getSiteManager (even though the comment says it needs to be deprecated) which always appears to return either the global registry or do an IComponentLookup adaptation. If no explicit context is supplied, how does anything other than the global registry end up getting used?

getSiteManager is "overloaded" from zope.app.component. See hooks.py. Yay for indirection :).

...

Normally, during traversal, an event subscriber reacts to ISites being traversed and remembers the site's component registry in a thread-local variable. getSiteManager() will then return whatever is in the thread-local variable, and therefore getUtility, getMultiAdapter, etc., will use that local registry.

...

If so, where do I find that adapter implementation(s)? See zope.app.component (also for the subscriber stuff mentioned above).

I spent quite a while looking and didn't spot them. Where exactly?

A quick look through zope.app.component/configure.zcml reveals that the subscriber is in site.py. The rest of the machinery is in hooks.py.

(also bear in mind that I don't really want to use any of zope.app...)

Fair enough.

...

...

...however, I'm interested in the mechanics of how zope.component handles multiple component registries, in particular how registries are added to and removed from the set of registries that are searched hen looking for a component and some other bits and pieces. Which is the *use* of Zope, not the *development* of Zope.

I'm not really sure why you're quibling over this but I'm quite happy to move this discussion to zope3-users if you're prefer and then move it back to zope-dev if it turns out I need to do *development* of Zope (such as the patch you requested above ;-) )

I guess I'm nitpicking. I would just like to stress the focus of the zope-dev list. And regarding the patch, I've encouraged people to submit patches on zope3-users before, too ;).

On 26 Nov 2007, at 19:22 , Chris Withers wrote:

...

...

(and I'm guessing there is an ISite somewhere, as I could find no definition of setSiteManager, but how does IComponentArchitecture's getSiteManager relate to that of ISite?) zope.component.getSiteManager() will return whichever component registry is active. site.getSiteManager() will return the local component registry that has been associated with site (which provides ISite).

Okay, what's the difference between these two registries?

Well, site.getSiteManager() will return a very specific component registry, namely the one that's associated with the object named 'site'. zope.component.getSiteManager() will return *whichever* component registry is the active one. Only if 'site' has been remembered as the current site (e.g. during traversal), then both will return the same registry.

...

...

I think I'm misreading the code in _api then. It looks to me that most things use getSiteManager (even though the comment says it needs to be deprecated) which always appears to return either the global registry or do an IComponentLookup adaptation. If no explicit context is supplied, how does anything other than the global registry end up getting used? getSiteManager is "overloaded" from zope.app.component. See hooks.py. Yay for indirection :).

So zope.app.component replaces the getSiteManager implementation in zope.component? :-(

Yes.

...

subscriber is in site.py. The rest of the machinery is in hooks.py.

As an aside, I assume zope.thread is needed because Zope doesn't yet run with Python 2.5 as a whole?

Not sure I'm following you here. zope.thread.local provides an implementation for the thread-local variable, so that we can remember the 'site' object during traversal in a global place, but still not interfere with other threads. Note that this mechanism was donated to the Python stdlib and is available already in Python 2.4 under 'threading.local'. The latest version of zope.thread.local just refers to 'threading.local'.

Also, where's the code which, in the local registry, defers to the global registry to find more adapters/subscribers/whatever?

Look for the __bases__ property and its dynamic setter.

...

I guess I'm nitpicking. I would just like to stress the focus of the zope-dev list.

Well, I guess with splitting zope into seeprately usable components, this all becomes a much greyer area. I'm exploring the realtionship between components and trying to understand their implementation. That feels like development *of* zope to me,

It doesn't to me (which doesn't have to mean anythign ;))

whereas zope3-users has felt like a list for people using "the whole of zope 3", whatever that is nowadays...

I think zope3-users is also for the users of the separately usable components. Well, as it turns out, they're not so separately usable right now, at least when you're tryinig to easy_install zope.component or so :(. But at least we're working on that.

I'd be happy to use either list and even happier to see all 3 lists merge now that they're low volume enough (ie: just have zope@zope.org, rather than zope-dev, zope and zope3-users)

I think there's value in separating development from the rest of the traffic. As far as zope@zope.org is concerned, I see a lot of old- school (e.g. DTML-related) traffic there, but even though I think it'd make sense to merge it with zope3-users.

PS: I am quite excited that it looks like I may actually be able to use bits of zope independently, and this wsgi stuff looks pretty cool too :-)

Cool! Be sure to let us know about it afterwards. I think we could use some feedback on projects like this.

On 28 Nov 2007, at 11:43 , Chris Withers wrote:

Philipp von Weitershausen wrote:

...

...

So zope.app.component replaces the getSiteManager implementation in zope.component? :-( Yes.

It's a shame this couldn't have been implemented in a more component- architecture-oriented way, but I'm guess things get chicken-and-egg- y at this point?

Yeah.

...

...

Also, where's the code which, in the local registry, defers to the global registry to find more adapters/subscribers/whatever? Look for the __bases__ property and its dynamic setter.

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!) are some sort of subclass of zope.interface.adapter.BaseAdapterRegistry which has the handling for cascading lookups through its __bases__ property. :)

...

I think zope3-users is also for the users of the separately usable components. Well, as it turns out, they're not so separately usable right now, at least when you're tryinig to easy_install zope.component or so :(. But at least we're working on that.

I still can't make out if the whole eggs/easy_install thing just sucks and we should build something else for the python community (it's not just zope that's struggled with easy_install ;-) ) or if it's just zope that's had the real problems 'cos of some "bad eggs"...

If eggs had some decent dependency handling. People often say that setuptools is reinventing what the Linux distros are doing, but poorly. As far as the dependency handling goes, they're right (setuptools' dependency handling could be *much* improved). However, I don't think eggs are much like Linux distros in any other way.

...

I think there's value in separating development from the rest of the traffic.

Why?

Because some developers prefer lower traffic lists that focus on solely on development.

...

As far as zope@zope.org is concerned, I see a lot of old-school (e.g. DTML-related) traffic there,

Really? I don't see much activity on that list at all nowadays, although there was quite an interesting thread (and quite relevent to zope3 and zope-dev) that kicked off which involved dtml ;-)

Yeah, saw that :).

...

...

PS: I am quite excited that it looks like I may actually be able to use bits of zope independently, and this wsgi stuff looks pretty cool too :-) Cool! Be sure to let us know about it afterwards. I think we could use some feedback on projects like this.

Will do, but please be patient with my fumblings in the meantime.

If it helps, as far as components and registries goes, I'm aiming for something like skin-like stacked registries that can be altered ttw...

Sounds wild :)

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

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"

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