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
-----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-----
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
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
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 <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
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
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 <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
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
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
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
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 )
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
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 )
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
On Thursday 28 May 2009, Martijn Faassen wrote:
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.
Oh, that's the separation you are proposing. I am all for this. The "local registry" should have a simple API. And I would leave the site management container stuff around only for BBB and phase it out quickly. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
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.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
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
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
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
Hey, Jim Fulton wrote:
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.
I think there are two cases where people typically deal with local configuration: * setting up local utilities (for authentication, the catalog, application-specific configuration storage + UI) * writing tests that involve local utilities. (a more advanced case, but still quite common)
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. :)
I don't think "hosting multiple web sites with different configs in the same application" is the only use case. * the catalog. This can be done using a global component that somehow stuffs information in the ZODB, but there are no common patterns for this that people can follow, so local utilities are currently easier to use. * often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed.
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.
My goals are: * I do care about local component configuration * I'm a simple person and want to make my life easier * I want to be able to write and test local utilities without having to depend on zope.site for my testing (right now I have a hacked up version that I just copy and paste). An example of the hacked up version of site management is here: http://svn.zope.org/hurry.custom/trunk/src/hurry/custom/testing.py?rev=99648... And I'd like to put that code somewhere proper. * I'd like to change the dependency structure so that a minor dependency on site management doesn't require a package to pull in zope.container (which pulls in quite a bit itself) Regards, Martijn P.S. As of this point I'm dropping my proposal to rename anything to anything. Let's indeed focus on the wider discussion (as indicated by Roger and Jim)
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed.
That sounds like a complicated workaround for not having a mutable global configuration. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hi Wichert
-----Ursprüngliche Nachricht----- Von: zope-dev-bounces+dev=projekt01.ch@zope.org [mailto:zope-dev-bounces+dev=projekt01.ch@zope.org] Im Auftrag von Wichert Akkerman Gesendet: Donnerstag, 28. Mai 2009 17:21 An: Martijn Faassen Cc: zope-dev@zope.org Betreff: Re: [Zope-dev] refactoring site functionality
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed.
That sounds like a complicated workaround for not having a mutable global configuration.
Or the right concept if a Server restart is not an option ;-) btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago? Regards Roger Ineichen
Wichert.
-- Wichert Akkerman <wichert@wiggy.net> It 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 )
On Thursday 28 May 2009, Roger Ineichen wrote:
btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago?
BTW, plone.reload looks really promising. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Thursday 28 May 2009, Roger Ineichen wrote:
btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago?
BTW, plone.reload looks really promising.
For all I know plone.reload works and people use it during daily development including myself. The code reloading part has some limitations, like not dealing with properties / decorated methods, but the ZCML part should just work (tm). It's currently a bit Zope 2 specific, but the general pattern as seen in http://dev.plone.org/plone/browser/plone.reload/trunk/plone/reload/zcml.py should be easy to adopt to non-Zope 2. It makes some assumptions like zope.testing.cleanup functions to be available for all secondary registries populated by ZCML handlers. Hanno
Hanno Schlichting, on 2009-06-01:
Stephan Richter wrote:
On Thursday 28 May 2009, Roger Ineichen wrote:
btw, you are pointing to a good direction. Didn't we talk about reload global configuration during runtime years ago?
BTW, plone.reload looks really promising.
For all I know plone.reload works and people use it during daily development including myself. The code reloading part has some limitations, like not dealing with properties / decorated methods, but the ZCML part should just work (tm).
Confirmed, I use it daily with great delight, so thanks for creating it! Some things indeed do not work, for example I usually get errors when trying to reload code in plone portlets. When errors like that occur, or I notice some other problem that might be cuased by bad reloading, I do not even think about it but first restart Zope to see if the error is still there. For a small zope 3 or grok application the startup is already small though, so it may not be useful there. Cheers, -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]
On Tuesday 02 June 2009, Maurits van Rees wrote:
For a small zope 3 or grok application the startup is already small though, so it may not be useful there.
Well, I would hook it up so that it reloads Python files at every request automatically, if any changed and ZCML if a ZCML file changed. This way I can avoid the roundtrip to the shell all the time. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
If you start up a WSGI app with "paster", this is what "paster serve --reload" does, except it just restarts the process. In practice, when the application starts fast enough, it's very useful. - C On 6/2/09 10:16 AM, Stephan Richter wrote:
On Tuesday 02 June 2009, Maurits van Rees wrote:
For a small zope 3 or grok application the startup is already small though, so it may not be useful there.
Well, I would hook it up so that it reloads Python files at every request automatically, if any changed and ZCML if a ZCML file changed. This way I can avoid the roundtrip to the shell all the time.
Regards, Stephan
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed.
That sounds like a complicated workaround for not having a mutable global configuration.
I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too. Regards, Martijn
On 6/4/09 11:59 AM, Martijn Faassen wrote:
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration.
I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too.
This is true. OTOH, I've never really been keen on the idea that the CA API should be bent around the idea that you're going to often want to find a persistent registry. It seems just as reasonable to: - put a persistent object someplace (with its own UI) that isn't registered as a CA utility. - find it via the location API when you need it in your code. - *Pass* it to global utilities (or adapters) when you need to vary behavior based on location. Maybe CMF tools weren't such a bad idea. - C
Previously Chris McDonough wrote:
On 6/4/09 11:59 AM, Martijn Faassen wrote:
Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed. That sounds like a complicated workaround for not having a mutable global configuration.
I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too.
This is true. OTOH, I've never really been keen on the idea that the CA API should be bent around the idea that you're going to often want to find a persistent registry. It seems just as reasonable to:
- put a persistent object someplace (with its own UI) that isn't registered as a CA utility.
- find it via the location API when you need it in your code.
- *Pass* it to global utilities (or adapters) when you need to vary behavior based on location.
Maybe CMF tools weren't such a bad idea.
For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hi there, Wichert Akkerman wrote: [snip]
For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration.
That's very interesting! I can see the benefits of separating this out, though on the other hand it does introduce more indirection, which is a cost as well. And the configuration UI itself could become simpler or at least less scattered around, so that's a win. I can see how this cost is worth it in large apps like Plone. I'm not sure about smaller apps, but could be a win too, as you could reuse the configuration UI. The costs can also be minimized with the use of a proxy (I saw you have one). It's definitely an interesting approach. I'll be keeping an eye on it... [it's licensed GPL at the moment the pypi page says. Is this going to change?] Regards, Martijn
Hi Martijn, Martijn Faassen wrote:
Hi there,
Wichert Akkerman wrote: [snip]
For Plone we regret that we used persistent utilities to store configuration: they have made Plone instances much more fragile (removing a utiliy's implementation breaks the whole site) and forces you to write a UI for the stored configuration again and again. To move forwards we have come up with plone.registry (see http://pypi.python.org/pypi/plone.registry), which gives you a nice central storage system for configuration.
That's very interesting!
I can see the benefits of separating this out, though on the other hand it does introduce more indirection, which is a cost as well.
I'm not sure that it does, as such. It's more of a conceptual change. The plone.registry model is kind of like about:config in Firefox. You have a place to create configuration records (values with a schema) and a way to retrieve them. There's still only one level of indirection: find the thing that stores your values, and get them. It's just that instead of calling getUtility(IMyUtility) you call getUtility(IRegistry) and get the values from there. You can, if you want, build your records from a schema for convenience, and get back an object conforming to that schema backed by the registry. However, the registry does not contain any persistent references to your custom code, so it doesn't break if that symbol is no longer importable. plone.app.registry adds a GenericSetup synax + a generic config editor + a base class for building custom "control panel" forms based on the registry.
And the configuration UI itself could become simpler or at least less scattered around, so that's a win.
At least you can generalise the things that you don't need to expose the user. Like Firefox, there's a control panel for the user-facing stuff, and about:config as a geeky fallback.
I can see how this cost is worth it in large apps like Plone. I'm not sure about smaller apps, but could be a win too, as you could reuse the configuration UI. The costs can also be minimized with the use of a proxy (I saw you have one).
Right. There's some value in standardising on a pattern, too. I think if you want some kind of persistent configuration, plone.registry or something like it adds useful consistency and safety. If you don't want persistent configuration, it's obviously moot.
It's definitely an interesting approach. I'll be keeping an eye on it...
[it's licensed GPL at the moment the pypi page says. Is this going to change?]
Yes, as soon as the Plone Foundatino licensing changes are completed, this will be BSD licensed. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Chris McDonough wrote:
On 6/4/09 11:59 AM, Martijn Faassen wrote: [snip]
I don't think it's complicated. It's nice to install an object somewhere that stores data and has a UI and also be able to register it as a local utility. If you were to have mutable global configuration, you'd need some way to expose it to the UI and content-space too.
This is true. OTOH, I've never really been keen on the idea that the CA API should be bent around the idea that you're going to often want to find a persistent registry. It seems just as reasonable to:
- put a persistent object someplace (with its own UI) that isn't registered as a CA utility.
- find it via the location API when you need it in your code.
By location API, you mean something like mycurrentapp()['foo']['bar']?
- *Pass* it to global utilities (or adapters) when you need to vary behavior based on location.
Doesn't this make you have to scatter a lot of location-getting and context-passing code throughout your codebase? I guess it depends on how your codebase is factored. But say you have a utility that sends email, and can be configured with the email address to send it to somewhere in a config screen, you could have 10 places in your code that need to get the configured email address and then pass it to the utility. Now that's probably easy enough to encapsulate in a function, but: * but if you have your configuration right there in the local utility it comes pre-encapsulated. Now you got two bits, one that knows how to send email and one that is being configured. This separation into bits may be right in some cases, but it seems overkill in many. * you're going to have to pass your current application context in each time you want to send email. That's avoided with a utility lookup (as this is implicit). So, I'm having trouble seeing the benefits to this alternative approach, could you explain? Regards, Martijn
On 5/28/09 11:00 AM, Martijn Faassen wrote:
Hey,
Jim Fulton wrote:
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.
I think there are two cases where people typically deal with local configuration:
* setting up local utilities (for authentication, the catalog, application-specific configuration storage + UI)
I suppose the original reason authentication was made a local utility is for the management UI. I've never actually seen the Zope 3 management UI for authentication data. But FTR, as far as authentication goes, I very seldom require a context-sensitive "user folder" for an application, even if the "application" is actually several instances of the same application in multiple locations. It's pretty hard to create a generally useful management UI for arbitrary authentication sources anyway. They all have slightly different constraints: some are read/write, some are read-only, etc. So I usually end up writing my own anyway or I just rely on an existing UI (direct SQL, ldap browser, etc). It might be easier for developers to understand, at least if no management UI was required, if the authentication service was always just a global utility, and the utility accepted a context in each of its API definitions. Then people who really do need context-sensitive authentication can register a utility that adapted the passed in context as necessary, but a simpler utility would just use global data. The pattern is this: delegate the context adaptation to a global utility and let the developer do as he must in that global utility to return appropriate data based on the context. I suspect a similar pattern would be useful for cataloging, etc. - C
On May 28, 2009, at 11:00 AM, Martijn Faassen wrote:
Hey,
Jim Fulton wrote:
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.
I think there are two cases where people typically deal with local configuration:
* setting up local utilities (for authentication, the catalog, application-specific configuration storage + UI)
* writing tests that involve local utilities. (a more advanced case, but still quite common)
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. :)
I don't think "hosting multiple web sites with different configs in the same application" is the only use case.
* the catalog. This can be done using a global component that somehow stuffs information in the ZODB, but there are no common patterns for this that people can follow, so local utilities are currently easier to use.
* often it is nice to have application configuration to have a user interface, so that end users can configure aspects of the application. This may be filling in an email address or customizing a template or adding a user, etc. Local utilities are a nice solution for this, even if there is just a single application installed.
I think we're talking about 2 different things. There is the registry that is "local" to the root object and that is stored in the database. Having registration data in the database makes sense for a number of reasons and I don't consider this advanced. This is effectively a global registry. It doesn't really matter that it is attached to the root folder. Then there are registries sprinkled around the object tree below the root. These are truly local, because they pertain to a subset of the object tree. This is the usage that I think we should relegate to an advanced feature and rethink the goals for. Most importantly, IMO, we should avoid having this advanced usage complicate the lives of 98% of developers who don't need it. Jim -- Jim Fulton Zope Corporation
Hi there, Jim Fulton wrote: [snip]
I think we're talking about 2 different things.
There is the registry that is "local" to the root object and that is stored in the database. Having registration data in the database makes sense for a number of reasons and I don't consider this advanced. This is effectively a global registry. It doesn't really matter that it is attached to the root folder.
Then there are registries sprinkled around the object tree below the root. These are truly local, because they pertain to a subset of the object tree. This is the usage that I think we should relegate to an advanced feature and rethink the goals for. Most importantly, IMO, we should avoid having this advanced usage complicate the lives of 98% of developers who don't need it.
So if I understand you correctly, when you say 'root' you're talking about the ZODB root, not a particular application's root? And you're suggesting there be only a single db-dependent registry in the ZODB as the basic use case, and that people can register object in the ZODB into that registry? I'm not sure how this simplifies matters very much compared to the current API, which isn't all that complicated in my experience. The one thing I can see is that 'setSite' and traversal hooks could potentially go away. Is that what you're thinking about? Regards, Martijn
Hi, On Thu, 2009-05-28 at 17:00 +0200, Martijn Faassen wrote:
Hey,
[...]
P.S. As of this point I'm dropping my proposal to rename anything to anything. Let's indeed focus on the wider discussion (as indicated by Roger and Jim)
(I'm not directly proposing a naming here, I'm just dumping my thoughts on how I think about 'sites' which happen to include a name.) I've been thinking about the concept of 'site' and 'locality' with the terms 'context' or 'focus' for a while to avoid CMSish jargon for my non-CMS applications. In my understanding a context provides deviating policies for the application based on the context's location in the object graph. Let me give you a short example how I use this: in one of our applications we have companies, facilities and people. The application itself provides some global (most times technical) policies, e.g. which views are attached where and what permissions are protecting what attributes. In addition to that when working in the context of companies we can access company-specific services like financial systems interfaces, company-specific statistical parameters, etc. On the level of facilities we still use the same financial system as the company does, but we allow to change statistical parameters for the facility. Person objects do not introduce policy changes but are located within a facility and will thus inherit the policy from them based on them being located within a facility, within a company within the application. I find this pattern to be pretty neutral WRT the web or to locations (as we know them from zope.location). This is basically my 0.02 EUR on the topic. Unfortunately, I do have to point to a naming thing: the component lookup methods already support an argument to say where to look for registries: it's called 'context'. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Christian Theune wrote: [snip]
I find this pattern to be pretty neutral WRT the web or to locations (as we know them from zope.location).
I think you're describing the pattern of (contextual) acquisition? :)
Unfortunately, I do have to point to a naming thing: the component lookup methods already support an argument to say where to look for registries: it's called 'context'.
Yes, that's a good point. 'context' is a rather broad term though, perhaps 'acquisition context' would work. :) Regards, Martijn
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"
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"
participants (15)
-
Chris McDonough -
Christian Theune -
Fabio Tranchitella -
Hanno Schlichting -
Jens Vagelpohl -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Matthew Wilkes -
Maurits van Rees -
robert rottermann -
Roger Ineichen -
Stephan Richter -
Wichert Akkerman