Philipp von Weitershausen wrote:
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".
Sorry, meant "if you aren't"...
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).
Okay, what's the difference between these two registries?
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
getSiteManager is "overloaded" from zope.app.component. See hooks.py.
Yay for indirection :).
So zope.app.component replaces the getSiteManager implementation in
A quick look through zope.app.component/configure.zcml reveals that the
My bad, I assumed that particular configure.zcml would, in some way, be
"special" and so didn't read...
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?
Also, where's the code which, in the local registry, defers to the
global registry to find more adapters/subscribers/whatever?
I guess I'm nitpicking. I would just like to stress the focus of the
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, whereas zope3-users has felt
like a list for people using "the whole of zope 3", whatever that is
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 [EMAIL PROTECTED],
rather than zope-dev, zope and 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 :-)
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -