[Zope-dev] Re: unregistering components?

[Philipp von Weitershausen]

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