[Zope-dev] RFC: Site - Locus
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 )
Re: [Zope-dev] RFC: Site - Locus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 28, 2009, at 13:08 , Martijn Faassen wrote: What do people think about: * the idea of renaming Site to Locus I think that's a terrible name. While site at least means something to people, locus doesn't carry any meaning in the specific knowledge domain you're trying to push it into. jens P.S.: Lokus is a slang word for toilet in German. Great connotation. My utilities need to go into the dump. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkoec2kACgkQRAx5nvEhZLIHHwCgoNQ76/TKTC6KQ8FBAWMQVIhh KS8AoKse/t3sRe9UEwDg0obcJWa8MIwX =rG/4 -END PGP SIGNATURE- ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hey, Jens Vagelpohl wrote: On May 28, 2009, at 13:08 , Martijn Faassen wrote: What do people think about: * the idea of renaming Site to Locus I think that's a terrible name. While site at least means something to people, locus doesn't carry any meaning in the specific knowledge domain you're trying to push it into. But the whole point is that while site means something to people, it gives people the *wrong* idea about what the functionality is actually about. A site in Zope terminology is something where local components can be registered and found. A site in any other web terminology means web site. site having a meaning to people already is actually a bad thing. If they see the word 'locus' they get two possible clues: * this is something I don't understand yet, so I need to figure it out. * Hm, I wonder whether it has something to do with local utilities. P.S.: Lokus is a slang word for toilet in German. Great connotation. My utilities need to go into the dump. Yes, many words we can use are bad slang word in some other language. Locus is also commonly used in genetics, my genes in the dump. :) We just need to watch out for slang words in English. 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 )
Re: [Zope-dev] RFC: Site - Locus
On 28 May 2009, at 12:39, Martijn Faassen wrote: * Hm, I wonder whether it has something to do with local utilities. I don't think I'd make this jump. I'd not be averse to a longer package name if it made it more explicit. Matt ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Previously Martijn Faassen wrote: 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. I don't see short as a very important quality here. It is not a name you have to type in often, so I would prefer something more descriptive. How about componentroot or componentcontainer.. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Matthew Wilkes wrote: On 28 May 2009, at 12:39, Martijn Faassen wrote: * Hm, I wonder whether it has something to do with local utilities. I don't think I'd make this jump. I'd not be averse to a longer package name if it made it more explicit. I wasn't primarily talking about a package name, but about the name for the concept (which can then be reflected class names, and a package name, if such a package is necessary). 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 )
Re: [Zope-dev] RFC: Site - Locus
Wichert Akkerman wrote: Previously Martijn Faassen wrote: 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. I don't see short as a very important quality here. It is not a name you have to type in often, so I would prefer something more descriptive. How about componentroot or componentcontainer.. I do find short an important quality here, because I find myself typing getSite() frequently, and in tests, setSite as well. It's also something one talks about. A site isn't a container, I'll note. A site is something that has local components registered but doesn't need to be implemented as a container at all. 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 )
Re: [Zope-dev] RFC: Site - Locus
Previously Martijn Faassen wrote: Wichert Akkerman wrote: Previously Martijn Faassen wrote: 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. I don't see short as a very important quality here. It is not a name you have to type in often, so I would prefer something more descriptive. How about componentroot or componentcontainer.. I do find short an important quality here, because I find myself typing getSite() frequently, and in tests, setSite as well. It's also something one talks about. People also talk about www which is horrible to pronounce in English :) A site isn't a container, I'll note. A site is something that has local components registered but doesn't need to be implemented as a container at all. A site contains component registraties and possible persistent components. That makes it a container to me. Perhaps componentRegistry works better for you? Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hi Martjin, Christian Betreff: [Zope-dev] RFC: Site - Locus [...] 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 Oh my god, many -1 * the plan for refactoring? I think we have other things to cleanup in zope.site befor we think about to split something out as the same as before. What I like to see is that we remove the default Folder container and simplify the hole implementation. Since Jim and Stephan refactored the component registry we are able to skip the half setup we use today. There is no need to support a default Folder for our utilities since we can registrer utilities everywhere. Such registered component will get found, doesnt' matter where they are located etc. I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. Are you aware of all the overhead we have in zope.site right now? We also have a bad/broken registry. I think Christian Theuni also knows about it. Not sure if this is fixed or if some utility registrations still hang arround in the local registry but shouldn't. If so, we have to take care if we touch the existing implementation and find out what could happen on all our production systems. And we need to support a fix for this broken registrations befor we touch or move something. Chistian, are I'm correct that you run itno that too. Did you fix something in zope.app.site once or did you add an issue on launchpad? I remember something but not sure if I'm correct. Regards Roger Ineichen ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hey, Roger Ineichen wrote: [snip] What do people think about: * the idea of renaming Site to Locus Oh my god, many -1 Motivations beyond oh my god? One reason Locus might be a bad word is because it's easily confused with Location, a concept we already have. What I like to see is that we remove the default Folder container and simplify the hole implementation. I'm proposing we separate the folder implementation from the basic site functionality. It will then become easier for people to ignore the folder implementation and not use it, while we retain backwards compatibility for those who do need it. [snip] I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. What is the same old bad concept? Details? Are you aware of all the overhead we have in zope.site right now? Since I actually assembled these things into zope.site, I have some awareness of what is in there. Could you actually point to specific points in the zope.site code? It's not a lot of code, after all. I'm proposing we move some of this code into zope.component, and the rest into zope.container (or we could leave it in zope.site for now). Where is the overhead we can safely remove? 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 )
Re: [Zope-dev] RFC: Site - Locus
zope.locusts? I don't think locus is an improvement to site. Although site is not strictly correct, it's often the fact that it is a site. Locus doesn't say anything, and adds another abstraction with no obvious benefit. A longer name is better in that case. Like componentlocation or registrationroot or something. But I don't think site is particularily confusing in the first place, even if it isn't 100% correct. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
One reason Locus might be a bad word is because it's easily confused with Location, a concept we already have. an other one is that in german locus is often used for a place where you sit down and use paper to clean your back afterwards.. robert ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus Hey, Roger Ineichen wrote: [snip] What do people think about: * the idea of renaming Site to Locus Oh my god, many -1 Motivations beyond oh my god? My first motivation was the same as Jens had. Lokus is such a unique word in german that you defently think this is a typo if you read Locus But I think right now we have: - a well known pattern with the ISite - the concept is not bad or wrong - the site is not a page (in web terms) - the site is a kind of root (in web terms) - the site map is an overview of what a site includes (in web terms) I can't think there could be a better name for what the site pattern does right now. There is absolutly no reason why we should use another name for the same concept we use the last 5 years. Probably I missed something in your proposal, but as far as I can see you don't propose to change something in the concept of the site pattern? right? One reason Locus might be a bad word is because it's easily confused with Location, a concept we already have. What I like to see is that we remove the default Folder container and simplify the hole implementation. I'm proposing we separate the folder implementation from the basic site functionality. It will then become easier for people to ignore the folder implementation and not use it, while we retain backwards compatibility for those who do need it. Probably a good idea [snip] I think a dependency cleanup and split the same old bad concept into different packages is not usefull right now. What is the same old bad concept? Details? Are you aware of all the overhead we have in zope.site right now? Since I actually assembled these things into zope.site, I have some awareness of what is in there. Could you actually point to specific points in the zope.site code? It's not a lot of code, after all. I'm proposing we move some of this code into zope.component, and the rest into zope.container (or we could leave it in zope.site for now). Where is the overhead we can safely remove? The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Also the lookup concept for this default container should get reviewed. I also think since we do not offer a Zope 3 application server the hole default setup which is not needed for a working local component registry shuld probably go to a own package. I think the hard part of refactoring the ISite and local utility concept is to moe the right concept how this pakage get used into diefferent packags and not the components. My first step whould be to write down the differen usecase of zope.site, global and local utilities, location, component and the registry which brings everything together. Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. What do you like to use independently from each other which is now assembled as a unit in zope.site? Regards Roger Ineichen 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 ) ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus I think if we really need a better naming, we should think about how everyting will fit together. e.g. application, root, site, registry, local, global component, location, container, item, etc. I don't think locus is the right missing part for a better understanding if you need to explain the zope world. Regards Roger Ineichen ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
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 )
Re: [Zope-dev] RFC: Site - Locus
Roger Ineichen wrote: [snip] The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Yes, with Grok we've been installing directly in the SiteManagementContainer (which contains the folder, if I got my terminology right). We can't just get rid of this though, as it would break a lot of existing ZODBs. [snip] Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. Of course if we make such a separation each end needs to be useful for something. What do you like to use independently from each other which is now assembled as a unit in zope.site? One use case I have is that I want to be able to write tests that just deal with site management without pulling in a lot. I have done this with hacked up code now in both z3c.saconfig and hurry.custom. The other use case I have is that I want to write packages that just need to be able to set the site or get the site and shouldn't need to care about, or depend on, zope.container at all. 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 )
Re: [Zope-dev] RFC: Site - Locus
Fabio Tranchitella wrote: * 2009-05-28 13:09, Martijn Faassen wrote: What do people think about: * the idea of renaming Site to Locus What is the technical advantage of renaming Site to Locus? To me it looks just like a (not so necessary) cosmetic change. Obviously there is no technical advantage to a renaming. But good naming is important. I'm fine if people don't like Locus, but I do think Site has been misleading, so it'd be nice if we could come up with a better word. Alternatively I'll just stick with 'site' and shuffle the code around without renaming. 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 )
Re: [Zope-dev] RFC: Site - Locus
Hi Jim Betreff: Re: [Zope-dev] RFC: Site - Locus 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. probably we can also find a simpler concept for make local configuration available with global configration files like we have done in z3c.baseregistry. This could have the benefit of both local and global done with the same pattern e.g. zope.configuration. I think global and local ist not so confusing, but the need to define global and local configuration in a totaly different way is complex to explain and understand. Regards Roger Ineichen ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hi Martjin Betreff: Re: [Zope-dev] RFC: Site - Locus Roger Ineichen wrote: [snip] The site offers a SiteManagementFolder, SiteManagerContainer and a LocalSiteManager. The SiteManagementFolder by default installed as ['default'] is absolutly useless and obsolate since the last refactoring. It's just a container, earlier it was a kind of namespace. Yes, with Grok we've been installing directly in the SiteManagementContainer (which contains the folder, if I got my terminology right). We can't just get rid of this though, as it would break a lot of existing ZODBs. [snip] Just refactoring zope.site and move the same packages arround because of dependencies is in my point of view the wrong thing. We need to define wich package will offer which parts of the hole site concept. otherwise it could be useless if at the end all packages get used together in 99% of all Zope projects. Of course if we make such a separation each end needs to be useful for something. What do you like to use independently from each other which is now assembled as a unit in zope.site? One use case I have is that I want to be able to write tests that just deal with site management without pulling in a lot. I have done this with hacked up code now in both z3c.saconfig and hurry.custom. I don't know this packages, but I agree, simpler testing setup is a great use case The other use case I have is that I want to write packages that just need to be able to set the site or get the site and shouldn't need to care about, or depend on, zope.container at all. Probably a rare use case or could become imporant if we use other patterns then the container traversal pattern. Do you have some ideas of using a contianer less traversal pattern? Regards Roger Ineichen 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 ) ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
Hey, Roger Ineichen wrote: [snip] Probably a rare use case or could become imporant if we use other patterns then the container traversal pattern. Do you have some ideas of using a contianer less traversal pattern? Take a look at this graph: http://startifact.com/depgraphs/zope.app.publisher-after2.svg zope.app.publisher is pointing at both zope.container and zope.site. I believe it's possible to break the dependency on zope.container. But if we did so and still had a (small) dependency on zope.site, we won't gain anything. If we do manage to break both dependencies, we can lose zope.site, zope.container, zope.cachedescriptors, zope.dottedname, zope.broken and zope.filerepresentation and zope.lifecycleevent from its dependency graph, if I read it well. That's 7 packages. :) 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 )
Re: [Zope-dev] RFC: Site - Locus
On Thursday 28 May 2009, Jim Fulton wrote: 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. :) Another important use case for local registrations are plugins. Using z3c.baseregistry, Roger and I have been building plugins using local registries created via ZCML. It works very well. Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] RFC: Site - Locus
On Thursday 28 May 2009, Martijn Faassen wrote: * the idea of renaming Site to Locus -1. I immediately had the same connotation as all the other German speakers. And I am studying genetics right now as well, so I knew about locus. Furthermore, I really do not see an advantage of renaming stuff right now. It would only force me to remap my brain for no good reason. * the plan for refactoring? +1 on the refactoring, so I do not have to have the weight of the site management container around anymore/ Regards, Stephan -- Entrepreneur and Software Geek Google me. Zope Stephan Richter ___ 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 )
