What from zope.app are you using
Hi there, we don't really want to ship all of zope.app with Zope 2. zope.app is supposed to be the Zope 3 application server. It shouldn't be included in Zope 2, especially since it requires twisted and such. We're therefore moving everything that isn't part of the core Zope 3 application server out of zope.app so that we won't have to include zope.app in future Zope 2 versions. Perhaps we can deprecate zope.app in Zope 2.10. I've compiled a list of zope.app subpackages that are directly used by Zope2/Five in a proposal: http://dev.zope.org/Zope3/MakeZopeAppSmaller. I am currently in the process of implementing this proposal on the jim-adapter branch of Zope 3. I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using. Philipp
On 4/5/06, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
I would like to know what other zope.app packages your 3rd party software is using.
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang. CPS uses zope.app.container for the container events and the IAdding interface all over the place. CPSMailAccess uses zope.app.cache, zope.app.dublincore, zope.app.copypastemove, and of course zope.app.mail. (And also zope.app.pagetemplate and zope.app.publisher.browser.BrowserView but I suspect those are special hacks or something, that may be avoidable now, Tarek might know more.) And we use zope.app.testing a lot, which you suggested not to move if I understand you correctly. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro-2 wrote:
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang.
We would like to start using browser menus in Plone
CPS uses zope.app.container for the container events and the IAdding interface all over the place.
We may want to reuse zope 3 containment concepts in Archetypes over time.
CPSMailAccess uses zope.app.cache, zope.app.dublincore, zope.app.copypastemove, and of course zope.app.mail.
We'd certainly want DC and Mail in Plone over time. Cache and copypastemove sounds like it would be useful, but I don't know what they do.
And we use zope.app.testing a lot, which you suggested not to move if I understand you correctly.
Anything to make testing easier, please. :) Martin -- View this message in context: http://www.nabble.com/What-from-zope.app-are-you-using-t1400253.html#a376785... Sent from the Zope - Dev forum at Nabble.com.
Martin Aspeli wrote:
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang.
We would like to start using browser menus in Plone
I was asking about current usage, not pious new years resolutions :).
CPS uses zope.app.container for the container events and the IAdding interface all over the place.
We may want to reuse zope 3 containment concepts in Archetypes over time.
Off-topic-ness aside, this would not be Archetypes role to play. We probably want make Zope 3 style containment an alternative to Acquisition in Zope 2 at some point. Of course, ideas, proposals and code would be welcome :).
And we use zope.app.testing a lot, which you suggested not to move if I understand you correctly.
Anything to make testing easier, please. :)
Bottom line: Stop using zope.app.placelesssetup. If you *are* using it, it's most probably my fault for telling you to use it. Philipp
Philipp von Weitershausen wrote:
Martin Aspeli wrote:
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang. We would like to start using browser menus in Plone
I was asking about current usage, not pious new years resolutions :).
This is the wrong attitude. Current usage should *not* guide what is shipped with Zope 2. The whole point is that *anything* in Zope 3 could be used in Zope 2, Zope 3 being a python library. Regards, Martijn
Martijn Faassen wrote:
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang. We would like to start using browser menus in Plone
I was asking about current usage, not pious new years resolutions :).
This is the wrong attitude. Current usage should *not* guide what is shipped with Zope 2. The whole point is that *anything* in Zope 3 could be used in Zope 2, Zope 3 being a python library.
You're mistaking my attitude with the explicit question in the email and the question driving my proposal. I agree with the rest of your statement. Philipp
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang.
We would like to start using browser menus in Plone
I was asking about current usage, not pious new years resolutions :).
This is the wrong attitude. Current usage should *not* guide what is shipped with Zope 2. The whole point is that *anything* in Zope 3 could be used in Zope 2, Zope 3 being a python library.
You're mistaking my attitude with the explicit question in the email and the question driving my proposal.
Okay point taken, my apologies. :) Regards, Martijn
Philipp von Weitershausen wrote at 2006-4-5 22:28 +0200:
... We probably want make Zope 3 style containment an alternative to Acquisition in Zope 2 at some point.
You are aware how many applications a replacement of acquisition by "Zope 3 containment" would break? -- Dieter
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-4-5 22:28 +0200:
... We probably want make Zope 3 style containment an alternative to Acquisition in Zope 2 at some point.
You are aware how many applications a replacement of acquisition by "Zope 3 containment" would break?
That's why I didn't say *replacement* but *alternative*. Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-4-5 22:28 +0200:
... We probably want make Zope 3 style containment an alternative to Acquisition in Zope 2 at some point.
You are aware how many applications a replacement of acquisition by "Zope 3 containment" would break?
That's why I didn't say *replacement* but *alternative*.
Jim is actively in favor of making acquisition wrappers support the Z3 location framework (i.e., expose '__parent__' and '__name__'), which would be neither. ;) Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFENZDj+gerLs4ltQ4RAmRBAJ9pB/U6sNLYl6SKLvGEjM7y9/Mo4wCg0hk+ Wix1WnAaIVhngXtsV/tC2Xw= =Al+E -----END PGP SIGNATURE-----
Tres Seaver wrote:
Philipp von Weitershausen wrote:
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-4-5 22:28 +0200:
... We probably want make Zope 3 style containment an alternative to Acquisition in Zope 2 at some point. You are aware how many applications a replacement of acquisition by "Zope 3 containment" would break?
That's why I didn't say *replacement* but *alternative*.
Jim is actively in favor of making acquisition wrappers support the Z3 location framework (i.e., expose '__parent__' and '__name__'), which would be neither. ;)
That's the alternative I had in mind. You would be able to use the ILocation API as an alternative to the Acquisition API. The real goal behind all this is to make the security machinery in Zope 2 understand the ILocation API so that you won't *have to* rely on Acquisition (but instead can use ILocation). Of course, you would still be able to use Acquisition. Philipp
Philipp von Weitershausen wrote: [snip]
The real goal behind all this is to make the security machinery in Zope 2 understand the ILocation API so that you won't *have to* rely on Acquisition (but instead can use ILocation). Of course, you would still be able to use Acquisition.
Yes, that would indeed be a terribly useful feature. It might make a version of Five possible where views don't need to inherit from acquisition. Regards, Martijn
On 4/7/06, Tres Seaver <tseaver@palladion.com> wrote:
That's why I didn't say *replacement* but *alternative*.
Jim is actively in favor of making acquisition wrappers support the Z3 location framework (i.e., expose '__parent__' and '__name__'), which would be neither. ;)
Or both. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On 4/5/06, Lennart Regebro <regebro@gmail.com> wrote:
CPSMailAccess uses zope.app.cache, zope.app.dublincore, zope.app.copypastemove, and of course zope.app.mail. (And also zope.app.pagetemplate and zope.app.publisher.browser.BrowserView but I suspect those are special hacks or something, that may be avoidable now, Tarek might know more.)
On an unrelated note, I would like to point out how cool it is that the CPSMailAccess uses so many parts of Zope3 in Zope2, and how well it works. The calendar uses almost nothing of zope.app directly, although it's a heavy user of Five integrational stuff. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
On 4/5/06, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
I would like to know what other zope.app packages your 3rd party software is using.
Well, CMFonFive uses zope.app.publisher.browser, because that's where the menus hang.
Menu support will be moved to zope.menu.
CPS uses zope.app.container for the container events and the IAdding interface all over the place.
Container support will be moved to zope.container once I figure out how to sanely deal with existing pickles. Is anyone in Zope 2 persisting zope.app.container.btree.BTreeContainer, zope.app.container.ordered.OrderedContainern or using the contained proxy (which is also persistent)?
CPSMailAccess uses zope.app.cache, zope.app.dublincore, zope.app.copypastemove, and of course zope.app.mail.
I've added these four to my list. They'll appear in an updated version of the proposal. I propose to move them all down to zope.* as they are (zope.app.mail should probably be called zope.sendmail). They're all not very complicated cases except zope.app.cache which has zope.app.form dependencies. I'd be glad if you could help me with moving them. I'm working on the jim-adapter branch. Straight moves usually just entail 1. svn mv'ing the directory 2. fixing up imports inside and outside the package 3. running the tests 3. providing BBB (I'm still figuring out a good way to do this w/o getting in circular import troubles)
(And also zope.app.pagetemplate and zope.app.publisher.browser.BrowserView but I suspect those are special hacks or something, that may be avoidable now, Tarek might know more.)
BrowserView will move to zope.publisher.browser. I haven't really made up my mind about zope.app.pagetemplate yet. Some use cases might be helpful. I'm also very much open for suggestions and, of course, for help :). The proposal still isn't finished regarding many important details. I myself am not sure what to do with some of the packages or the things we need from some packages.
And we use zope.app.testing a lot, which you suggested not to move if I understand you correctly.
Indeed. What from zope.app.testing are you using? If it's PlacelessSetup, I bet it's not needed (on Zope >2.9 that is). If you need Component Architecture setup and teardown, use zope.component.testing. Philipp
On 05.04.2006, at 17:29, Philipp von Weitershausen wrote:
implementing this proposal on the jim-adapter branch of Zope 3.
I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using.
i use zope.app.cachedescriptors in zope2 for various projects regards, bernd
On Wed, Apr 05, 2006 at 05:29:41PM +0200, Philipp von Weitershausen wrote:
I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using.
Aside from stuff mentioned on your proposal, we are using macros from zope.app.rotterdam.standardmacros. -- Paul Winkler http://www.slinkp.com
Paul Winkler wrote:
On Wed, Apr 05, 2006 at 05:29:41PM +0200, Philipp von Weitershausen wrote:
I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using.
Aside from stuff mentioned on your proposal, we are using macros from zope.app.rotterdam.standardmacros.
Aha. Why? Are you actually using parts of the Rotterdam skin? Philipp
On Wed, Apr 05, 2006 at 10:30:05PM +0200, Philipp von Weitershausen wrote:
Paul Winkler wrote:
Aside from stuff mentioned on your proposal, we are using macros from zope.app.rotterdam.standardmacros.
Aha. Why? Are you actually using parts of the Rotterdam skin?
Heh. Actually, a closer look reveals that we're not at all. In fact we're doing: from zope.app.rotterdam.standardmacros import StandardMacros as BaseMacros class StandardMacros(BaseMacros): macro_pages = ('common_macros', 'mydnanews_macros', 'main_template',) ... which means we get exactly nothing from using rotterdam, since rotterdam.standardmacros looks just like the above, it merely defines a different macro_pages tuple and imports the macros from basicskin. So in fact we're not using rotterdam at all, we're just using a single class that we could get from zope.app.basicskin rather than rotterdam. -- Paul Winkler http://www.slinkp.com
Hi Philipp! Philipp von Weitershausen wrote:
I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using.
What are your plans for zope.app.locales? Five uses its translations. And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code. Cheers, Yuppie
yuppie wrote:
Philipp von Weitershausen wrote:
I would like to know what other zope.app packages your 3rd party software is using. If thereare any other used than the ones mentioned in the proposal, we'll have to move them out of zope.app. I'd like to ask for your help on that, otherwise future Zope 2 versions might not anymore include the package you're using.
What are your plans for zope.app.locales? Five uses its translations.
Yes, that just occurred to me as well this morning.
And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code.
You're quite right. We should probably just move the whole zope.app.locales package. Perhaps to zope.translations? Perhaps it would also make sense to put the extractor and the ZCML directive handler for i18n:registerTranslations into zope.i18n and have zope.translations just contain the gettext files. Philipp
Hi Philipp! Philipp von Weitershausen wrote:
yuppie wrote:
And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code.
You're quite right. We should probably just move the whole zope.app.locales package. Perhaps to zope.translations?
Perhaps it would also make sense to put the extractor and the ZCML directive handler for i18n:registerTranslations into zope.i18n and have zope.translations just contain the gettext files.
Sounds good to me. At least if someone finds time to refactor the extractor. For now it is quite specific code for creating the zope gettext files and would better fit in zope.translations. Cheers, Yuppie
yuppie wrote:
Philipp von Weitershausen wrote:
yuppie wrote:
And CMF uses zope.app.locales.extract. Not in the CMF products, but for a script that extracts i18n messages. That script is a quick hack and zope.app.locales.extract isn't really made for reuse. But it contains some useful code.
You're quite right. We should probably just move the whole zope.app.locales package. Perhaps to zope.translations?
Perhaps it would also make sense to put the extractor and the ZCML directive handler for i18n:registerTranslations into zope.i18n and have zope.translations just contain the gettext files.
Sounds good to me. At least if someone finds time to refactor the extractor. For now it is quite specific code for creating the zope gettext files and would better fit in zope.translations.
On second thought, I think we should think about the zope.app.locales vs. zope.translation thing a bit harder. I don't think we should move it now. As for the extractor: it can very well be used for other projects than Zope 3. As you said, you guys are using it for the CMF. I would therefore still suggest moving it to zope.i18n. Philipp
Philipp von Weitershausen wrote:
yuppie wrote:
Sounds good to me. At least if someone finds time to refactor the extractor. For now it is quite specific code for creating the zope gettext files and would better fit in zope.translations.
On second thought, I think we should think about the zope.app.locales vs. zope.translation thing a bit harder. I don't think we should move it now.
As for the extractor: it can very well be used for other projects than Zope 3. As you said, you guys are using it for the CMF. I would therefore still suggest moving it to zope.i18n.
Yes. We are using it for CMF. But it was not fun to write the CMF code. Generally useful stuff is in utilities/i18nextract.py and zope specific stuff in zope.app.locales.extract. I did have to copy a lot from i18nextract.py and override many methods for changes that should be configurable. Extraction from ZCML still doesn't work. I don't want to blame anybody for that. Just say that the people who wrote it did not focus on writing reusable code. Cheers, Yuppie
Philipp von Weitershausen wrote:
As for the extractor: it can very well be used for other projects than Zope 3. As you said, you guys are using it for the CMF. I would therefore still suggest moving it to zope.i18n.
We've been using a slightly forked version for Silva for quite a while. I forget what changes were necessary, but one bit was hooking in support for extracting message ids from Formulator XML. Regards, Martijn
Philipp von Weitershausen wrote:
we don't really want to ship all of zope.app with Zope 2. zope.app is supposed to be the Zope 3 application server. It shouldn't be included in Zope 2, especially since it requires twisted and such.
I'm worried about this approach, as it stops the Five project from exposing more Zope 3 functionality into Zope 2 directly, instead having to wait for a new release of Zope 2 that includes the missing bits. I'd therefore recommend an approach that includes as much of zope.app into Zope 2 as is possible, while leaving out the obvious bits that shouldn't be there, like Twisted. Regards, Martijn
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
we don't really want to ship all of zope.app with Zope 2. zope.app is supposed to be the Zope 3 application server. It shouldn't be included in Zope 2, especially since it requires twisted and such.
I'm worried about this approach, as it stops the Five project from exposing more Zope 3 functionality into Zope 2 directly, instead having to wait for a new release of Zope 2 that includes the missing bits.
That's why I want to make sure that we include as much of zope.app in Zope 2. But I'm just one man so I tried to focus on current usage. I'm sure we all want to use as much as possible from Zope 3 in our Zope 2 projects in the future, but we have to draw the line for this release. The freeze is 3 weeks away. I'm aware that we might not get it all done for Zope 2.10. That's ok, we can phase out Zope 2's zope.app usage over a longer time.
I'd therefore recommend an approach that includes as much of zope.app into Zope 2 as is possible, while leaving out the obvious bits that shouldn't be there, like Twisted.
Then what's the point of zope.app at all? You're almost sounding like you want to move everything in zope.* to zope.app. I think in the past we didn't really understand what zope.app was. We just put everything in there. That didn't work. The twisted thing is just the biggest symptom. A much different, perhaps more subtle symptom is the fact that reusing stuff from zope.app is harder than reusing stuff that's independent of it. The fact that Zope 2 ships with zope.app is not because it wants to but because it needs to. All the things that *should* be reusable are tucked away there. If we continue to put everything in the zope.app bag, we won't be able to release more technology independently. I remember that you yourself suggested to put widgets into a more accessible and reusable location. I'm suggesting the same thing for all that other Zope 3 technology. Zope 2 is just the biggest motivator. Philipp
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Philipp von Weitershausen wrote:
we don't really want to ship all of zope.app with Zope 2. zope.app is supposed to be the Zope 3 application server. It shouldn't be included in Zope 2, especially since it requires twisted and such.
I'm worried about this approach, as it stops the Five project from exposing more Zope 3 functionality into Zope 2 directly, instead having to wait for a new release of Zope 2 that includes the missing bits.
That's why I want to make sure that we include as much of zope.app in Zope 2. But I'm just one man so I tried to focus on current usage. I'm sure we all want to use as much as possible from Zope 3 in our Zope 2 projects in the future, but we have to draw the line for this release. The freeze is 3 weeks away.
I'm aware that we might not get it all done for Zope 2.10. That's ok, we can phase out Zope 2's zope.app usage over a longer time.
Okay, that's fine, as long as we're clear that zope.app will still be part of Zope 2.10.
I'd therefore recommend an approach that includes as much of zope.app into Zope 2 as is possible, while leaving out the obvious bits that shouldn't be there, like Twisted.
Then what's the point of zope.app at all? You're almost sounding like you want to move everything in zope.* to zope.app.
Sorry, I was unclear. zope.app getting smaller good. Leaving zope.app out of Zope 2 in the next Zope 2 release, bad. There's a lot of stuff in zope.app that a lot of projects are using, and we may break stuff significantly if code is suddenly not there anymore. [snip arguing against putting lots of stuff in zope.app] I'm not arguing in favor of zope.app, I'm just arguing in favor of keeping zope.app included into Zope 2 releases for the time being, until we're a lot further with this process of moving things out of zope.app. Regards, Martijn
Martijn Faassen wrote:
That's why I want to make sure that we include as much of zope.app in Zope 2. But I'm just one man so I tried to focus on current usage. I'm sure we all want to use as much as possible from Zope 3 in our Zope 2 projects in the future, but we have to draw the line for this release. The freeze is 3 weeks away.
I'm aware that we might not get it all done for Zope 2.10. That's ok, we can phase out Zope 2's zope.app usage over a longer time.
Okay, that's fine, as long as we're clear that zope.app will still be part of Zope 2.10.
In a realistic scenario that will still be the case. For example, I don't see the zope.app.form beast dissected for this release.
I'd therefore recommend an approach that includes as much of zope.app into Zope 2 as is possible, while leaving out the obvious bits that shouldn't be there, like Twisted.
Then what's the point of zope.app at all? You're almost sounding like you want to move everything in zope.* to zope.app.
Sorry, I was unclear. zope.app getting smaller good. Leaving zope.app out of Zope 2 in the next Zope 2 release, bad. There's a lot of stuff in zope.app that a lot of projects are using, and we may break stuff significantly if code is suddenly not there anymore.
[snip arguing against putting lots of stuff in zope.app]
I'm not arguing in favor of zope.app, I'm just arguing in favor of keeping zope.app included into Zope 2 releases for the time being, until we're a lot further with this process of moving things out of zope.app.
Agreed. Thanks for your input. Philipp
Martijn Faassen wrote at 2006-4-6 11:51 +0200:
... I'd therefore recommend an approach that includes as much of zope.app into Zope 2 as is possible, while leaving out the obvious bits that shouldn't be there, like Twisted.
To the contrary, I am interested to get a Zope 2 as small as possible. -- Dieter
Hi everybody, Just to sketch out my general points to be clear: * I'm fine with a Zope 3 project that moves things from zope.app into zope. * I'm also fine with Zope 2 usage guiding which things should be moved first. * I'm not fine with a Zope 2 shipping with only parts of the library-like functionality of Zope 3. I think the Five project, along with Five users, should continue to have the ability to expose bits of Zope 3, no matter where they happen to be residing (zope or zope.app), into Zope 2. * I don't see why shipping zope.app (as long as it exists) with Zope 2 is a problem. It doesn't hurt except for taking up a bit more of cheap diskspace. * You could argue for removing those bits of zope.app that really have nothing to do with Zope 2, but I'd still be careful here. Someone might *want* to work on a new publisher for Zope 2 that uses Twisted, using bits of Zope 3 that integrate with Twisted, and why make life more difficult for them? * if you do not ship zope.app with Zope 2 anymore, the usage by Zope 2 will stop being a guide for which things to move from zope.app into zope next. Regards, Martijn
participants (9)
-
Bernd Dorn -
Dieter Maurer -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Paul Winkler -
Philipp von Weitershausen -
Tres Seaver -
yuppie