Re: [Zope-dev] zope.testrunner import location notifications
Hi, On Tue, 2009-05-26 at 12:42 +0200, Martijn Faassen wrote: > Hi there, > > (in particular Christian Theune) thanks for reminding. I dropped the ball on those. > What's the status of the 'import location' notification functionality in > zope.testrunner? I'll resume work on that once the ZODB migration code is done. > What's the status of the ZODB migration code? I'm taking up work on that again. It still lives in the Sandbox (svn +ssh://svn.zope.org/repos/main/Sandbox/ctheune/zodbupgrade), but I restructured it today so that it becomes easier to use. I still need to provide tests and documentation though. I think this can happen in the next days. Christian -- Christian Theune · c...@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 signature.asc Description: This is a digitally signed message part ___ 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] [Checkins] SVN: zope.app.http/trunk/ - Replacedthedependency on zope.deprecation with BBB imports
Hi there, Roger Ineichen wrote: [snip] > The only thing I could say about this concept is that we > didn't start to remove #BBB marked imports. > > Just wait till we start remove the BBB imports and > the packages from install_requires ... Since we were hardly in a hurry removing deprecation warnings *years* after we promised to remove them in the text (there's still some around), I can't say we'll be in that much of a hurry to remove these. :) 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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hey, Stephan Richter wrote: [snip] > I have been following this discussion and just want to mention that I fully > agree with Roger. If you release a final version of Zope or a package that > spews deprecation warnings or has not fixed the imports, then this should be > considered bad releasing. I'm not sure I understand this. If you are releasing a final version of zope.app.component, do you want it *not* to spew deprecation warnings? Or do you mean you require someone to go through all packages that may depend on zope.app.component and change the imports there before zope.app.component is released? But if so, you'd need to release zope.app.component with deprecation warnings. Several times in the previous discussion I heard people talk about wanting to support multiple releases of a single package and not wanting indirect deprecation warninsg. I'm not going to defend their view here myself, but I must note we've been spending some months now moving away from zope.deprecation. I highly doubt that this will hurt us seriously in the coming years. And if it does, at least we'll be using Python imports amenable by analysis by any Python programmer, with records in the CHANGES.txt that can be read by anyone, and not our own home-grown import system using module proxies. 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] 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 )
[Zope-dev] Zope Tests: 7 OK, 1 Failed
Summary of messages to the zope-tests list. Period Wed May 27 12:00:00 2009 UTC to Thu May 28 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Test failures - Subject: FAILED (errors=1) : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Wed May 27 21:02:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011808.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed May 27 20:51:54 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011803.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed May 27 20:53:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011804.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Wed May 27 20:55:56 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011805.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Wed May 27 20:58:00 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011806.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Wed May 27 21:00:04 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011807.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Wed May 27 21:04:06 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011809.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Wed May 27 21:06:07 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011810.html ___ 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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Martijn > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- > Replacedthedependency on zope.deprecation with BBB imports > > Hey, > > Stephan Richter wrote: > [snip] > > I have been following this discussion and just want to > mention that I > > fully agree with Roger. If you release a final version of Zope or a > > package that spews deprecation warnings or has not fixed > the imports, > > then this should be considered bad releasing. > > I'm not sure I understand this. If you are releasing a final > version of zope.app.component, do you want it *not* to spew > deprecation warnings? My fear is that deprecated imports will pull in packages and act as the single point of an egg declaration. If someone removes a dependency during a deprecation import cleanup lets say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a custom project didn't fix the zope.formlib depndency in his setup.py because there is no need to do so. Good luck if the last egg cleans up the zope.formlib dependency and you didn't fix it in your project for your self. This will end in loosing the dependency at all and you don't know why. Of corse you can fix this lost dependency and add it to your setup.py. But you still don't know why. You also can't find information about why in the zope.formlib package is not needed anymore because another package is responsible for not using the zope.formlib package. I''m pretty sure that at this moment you like to know if you should still like to depend on zope.formlib or not and also change to something else, but to what? What get refactored and is not using zope.formlib anymore? With deprecation warnings, you get very early informed and you will see which package are using newer versions. This will give you the required information that you also should switch a to another better concept. The deprecation message is a very important information and can keep you informed on what's going on and about new better concepts. Regards Roger Ineichen > Or do you mean you require someone to go through all packages > that may depend on zope.app.component and change the imports > there before zope.app.component is released? But if so, you'd > need to release zope.app.component with deprecation warnings. I'm absolutly sure you should not release packages in a KGS with deprecation warnings or deprecated imports. Of corse there could be a package which uses deprecated imports because another package get refactored. but not in a KGS. I think this is an important point. We agree that there could be packages with deprecated imports. but the release manager of the KGS has to do all the work for a clean deprecation free KGS release. That's a pain for them. > Several times in the previous discussion I heard people talk > about wanting to support multiple releases of a single > package and not wanting indirect deprecation warninsg. I'm > not going to defend their view here myself, but I must note > we've been spending some months now moving away from zope.deprecation. > > I highly doubt that this will hurt us seriously in the coming > years. And if it does, at least we'll be using Python imports > amenable by analysis by any Python programmer, with records > in the CHANGES.txt that can be read by anyone, and not our > own home-grown import system using module proxies. The current situation without deprecation warnings requires to read and follow 100 - 115 CAHNGES.txt files for some of our projects. That's just a pain. And I'm pretty sure nobody which proposes to skip deprecation messages and uses such an amount of packages is reading every CHANGES.txt file. I'm 100% sure nobody not invloved in the core development is happy with reading such an amount of CHANGES.txt files. And as more as I think about our concept I think it's totaly wrong. It's just bad to officialy recommend that everybody should read the CHANGEs.txt or he get lost in working with Zope packages. Note if you will loose a dependency(egg) you can't read the CHANGES.txt file of the lost package, you have to find out why you lost the dependency an consult all CHANGES.txt files from all of your used packages. 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
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 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 )
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 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 )
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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hey, Roger Ineichen wrote: [snip] > My fear is that deprecated imports will pull in packages > and act as the single point of an egg declaration. If someone > removes a dependency during a deprecation import cleanup lets > say zope.formlib in z3c.form from version 1.9.0 to 2.0.0 then > it's possible that a custom project didn't fix the zope.formlib > depndency in his setup.py because there is no need to do so. I'm not sure I understand, but if you directly use zope.formlib you should have a direct dependency on it in your setup.py. > Good luck if the last egg cleans up the zope.formlib dependency > and you didn't fix it in your project for your self. This > will end in loosing the dependency at all and you don't know > why. Of corse you can fix this lost dependency and add it to > your setup.py. But you still don't know why. You also can't > find information about why in the zope.formlib package is not > needed anymore because another package is responsible for > not using the zope.formlib package. If you don't use zope.formlib, there isn't a problem. If you do use it, you should declare it. I'm not sure I understand the problem here. Of course the dependency refactoring will cause breakages here and there, but I don't think they're intractable (especially if we do provide a KGS for the toolkit packages). > The deprecation message is a very important information and > can keep you informed on what's going on and about new better > concepts. I think you should be reading the CHANGES.txt of the packages you depend on when you upgrade the dependency. If you *don't* depend on a package directly, you normally shouldn't have to be concerned when it disappears. Of course there might be bugs introduced in this process: packages you do somehow indirectly depend on disappear. That's something we'll have to live with if we want to move forward at all. I don't see how zope.deprecation is going to make any difference in this in any way however - you won't see any deprecation warnings either as the underlying package is simply gone. A CHANGES.txt can contain much much better information than the deprecation warnings ever could. It can detail what happened, why it did, and what you should be doing. I've been rather confused with a "what now?" feeling when confronted with deprecation warnings in the past, and there was nothing else but these messages that I could investigate. 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
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] [Checkins] SVN: zope.app.http/trunk/- Replacedthedependency on zope.deprecation with BBB imports
Hi Martjin > Betreff: Re: [Zope-dev] [Checkins] SVN: zope.app.http/trunk/- > Replacedthedependency on zope.deprecation with BBB imports > > Hey, > > Roger Ineichen wrote: > [snip] > > My fear is that deprecated imports will pull in packages and act as > > the single point of an egg declaration. If someone removes a > > dependency during a deprecation import cleanup lets say > zope.formlib > > in z3c.form from version 1.9.0 to 2.0.0 then it's possible that a > > custom project didn't fix the zope.formlib depndency in his > setup.py > > because there is no need to do so. > > I'm not sure I understand, but if you directly use > zope.formlib you should have a direct dependency on it in > your setup.py. should is the right word for this ;-) > > Good luck if the last egg cleans up the zope.formlib dependency and > > you didn't fix it in your project for your self. This will end in > > loosing the dependency at all and you don't know why. Of > corse you can > > fix this lost dependency and add it to your setup.py. But you still > > don't know why. You also can't find information about why in the > > zope.formlib package is not needed anymore because another > package is > > responsible for not using the zope.formlib package. > > If you don't use zope.formlib, there isn't a problem. If you > do use it, you should declare it. I'm not sure I understand > the problem here. Of course the dependency refactoring will > cause breakages here and there, but I don't think they're > intractable (especially if we do provide a KGS for the > toolkit packages). > > > The deprecation message is a very important information and > can keep > > you informed on what's going on and about new better concepts. > > I think you should be reading the CHANGES.txt of the packages > you depend on when you upgrade the dependency. > > If you *don't* depend on a package directly, you normally > shouldn't have to be concerned when it disappears. Of course > there might be bugs introduced in this process: packages you > do somehow indirectly depend on disappear. That's something > we'll have to live with if we want to move forward at all. I > don't see how zope.deprecation is going to make any > difference in this in any way however - you won't see any > deprecation warnings either as the underlying package is simply gone. The point is that the deprecation message informs you for upcomming work. Which is a good information. I do not read the CHANGES.txt files ever night. > A CHANGES.txt can contain much much better information than > the deprecation warnings ever could. It can detail what > happened, why it did, and what you should be doing. I've been > rather confused with a "what now?" feeling when confronted > with deprecation warnings in the past, and there was nothing > else but these messages that I could investigate. Of corse should we have CHANGES.txt files. A deprecation warning should show a link where vi and emac users can write script which points directly to the CHANGES.txt at pypi if they click on the deprecation warning link ;-) 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
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
* 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. Fabio. ___ 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 )
[Zope-dev] refactoring site functionality
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&view=auto 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) ___ 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] 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. Wichert. -- Wichert Akkerman 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 )
Re: [Zope-dev] refactoring site functionality
Hi Wichert > -Ursprüngliche Nachricht- > Von: zope-dev-bounces+dev=projekt01...@zope.org > [mailto:zope-dev-bounces+dev=projekt01...@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 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 ) > ___ 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] refactoring site functionality
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 ___ 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] refactoring site functionality
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 ___ 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 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" ___ 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 )
Re: [Zope-dev] refactoring site functionality
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" ___ 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] refactoring site functionality
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 · c...@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 signature.asc Description: This is a digitally signed message part ___ 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 )
