On Thursday 09 August 2007 14:59, Philipp von Weitershausen wrote:
> 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 :)
I agree, the site concept is about locality, which is a concept on top of
> 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.
I think "site" is widely understood term in Zope 3 now and everyone knows
about it. We gain absolutely nothing by renaming it. I think "zope.site"
would be a great package name for "ISite" and friends.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list