Michael Howitz wrote:
zope.app.component.interfaces.ISite is used in (at least) zope.location,
so the site concept seems to be necessary outside zope.app.
It seem so. Please also see my reply to Roman's email.
I think, ISite should be migrated to zope.component or even (if it has
nothing to do with the component architecture) to a separate package
zope.site (which not yet exists).
When we moved stuff out of zope.app, we made the mistake of overloading
zope.component. I wouldn't want to make that mistake again. That's why I
don't think it should go into zope.component. I was once close to moving
ISite out of zope.app.component (and Baiju actually did it once without
discussing it first, IIRC), but Jim had doubts... I don't remember,
perhaps he can speak up :)
By the way, I personally find the word "site" a bit misguided. An ISite
is not a "website". An "ISite" may often be used as the root object for
a website, but it can just as well be used for other objects in the
In fact, technically speaking, a "site" is just a place that has access
to a component registry. So "sites" are places in your object hierarchy
that allow component registrations, in other words, that allow the
alteration of component acquisition. (If you compare that with Zope 2
and the old-school attribute acquisition, every object was a site back
then. Now it's limited to very specific objects that provide ISite).
I would much rather call this "place that has a component registry".
That's a bit too long, of course. "component place", or even better,
"component site" sounds short enough to me for a package name (e.g.
To cut a long story short, I'm +1, but zope.componentsite or so would be
much preferred to zope.site.
http://worldcookery.com -- Professional Zope documentation and training
Zope3-dev mailing list