A few high-level comments. 1. I admire your desire to make this clearer. :)
2. I think local configuration address use cases that most people don't have but introduce complexity that I bet a lot of developers trip over. 3. I think the right word here is "local registry". I think the whole concept should be labeled as advanced and we should discourage people from even pondering it unless they have a strong use case, like wanting to host multiple web sites with different configs in the same application. :) 4. I think we should step back (re)think how we handle the goals that drive this. If we do, we might come up with something so different that we'd make this discussion moot. Jim On May 28, 2009, at 7:08 AM, Martijn Faassen wrote: > Hi there, > > 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 > catalog. > > 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 > components. > > 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 > dependencies either). > > * 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? > > Regards, > > Martijn > > _______________________________________________ > Zope-Dev maillist - Zope-Dev@zope.org > http://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://mail.zope.org/mailman/listinfo/zope-announce > http://mail.zope.org/mailman/listinfo/zope ) -- Jim Fulton Zope Corporation _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
