We have a concept of "Site" in the Zope Toolkit, along with SiteManager
and the like. What this concept allows us to do is locally register
components. Most typically this is used for local utilities such as a
During traversal, a thread-local is set with the current site, so that
code that looks up a compoment will check the current site(s) before
falling back on the global component registry.
The word "site" has bothered myself and others for some time. It doesn't
really have the right connotations for random programmers; when you hear
site you think about website, and that's not really what this implies.
The reason we called it site I think has to do with the idea that we
expected Zope-based web sites to be applications with a lot of local
I'm interested in refactoring zope.site to split it into two packages:
one that has the pure site-based logic with minimal dependencies, and
support to easily test with sites, and the other with dependencies on
zope.container. While thinking about this, I figured this might be a
good opportunity to rename the word 'site' to something better.
I propose we use the word 'Locus' instead of 'Site'. This word doesn't
have a lot of connotations in the web programming world, and people can
guess by simply looking at the word it might have something to do with
*local* components. It's also short. It's also a synonym of the word
site. The dictionary says: "a place, a locality" and "the scene of any
event or action". I think that works quite well.
Two possible options for moving forward with this:
* create a zope.locus package that contains the core locus support. It
only speaks in terms of "locus" and doesn't use the word "site"
* zope.locuscontainer will have the container support surrounding sites.
* zope.site becomes a backwards compatible but deprecated package that
does 'from .. import .. as' to keep 'getSite' and 'setSite' and such
around. The package itself will be deprecated and people will be
encouraged to depend on zope.locus (or zope.locuscontainer, but that
will be rare).
The other plan:
* we fold the locus support into zope.component. This is assuming that
the dependencies for Locus can be kept to a bare minimum (no ZODB
* we add the LocusContainer support to zope.container directly; since it
already uses zope.component this isn't a problem
* zope.site is still a backwards compatible package (that depends on
zope.container and zope.component, which it already does).
The second plan is my favorite if it is possible dependency-wise and
zope.component doesn't take on new dependencies. I think support for
local components could very well be part of zope.component conceptually.
It would allow us to eliminate one package (zope.site) without
introducing any new packages (the other plan increases the amount of
packages by one, trading zope.site for zope.locuscontainer).
What do people think about:
* the idea of renaming Site to Locus
* the plan for refactoring?
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -