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

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. zope.componentsite).

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to