Re: [Zope-dev] What from zope.app are you using
On Thu, 06 Apr 2006 15:42:34 +0100, whit <[EMAIL PROTECTED]> wrote: to echo Martijn, I've learned much more about zope3 thumbing through the z3 bundled with Zope 2 than I have looking at actual zope3 source, because I don't have a job that pays me to do pure zope3. I would argue sending the whole enchilada is good social programming. one less download before someone explores the codebase and a lower barrier to experimentation if someone gets the itch to integrate a z3 feature into zope2. +10 zope.app smaller, better modularised - good zope.app gone for the sake of purity - bad (I suspect Philipp wasn't arging for this, though, only to use the Zope 2 comparison as a guide) Martin -- (muted) ___ 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] Re: What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
-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 [EMAIL PROTECTED] 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- ___ 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] Re: Zope Test Summaries 2006-04-05
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Thu, Apr 06, 2006 at 12:06:25PM -0400, Paul Winkler wrote: > >>On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote: >> >>>The VHM tests in Zope 2.9 and trunk broke last night: >>> >>>http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html >>>http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html >> >>I'm assuming this was me, but I ran test.py -q -all before checking in >>so I'm not sure how that happened. Investigating. > > > Must've run the tests in the wrong sandbox :-\ > > This failure was a side-effect of the changes I made: > > - The unit tests in Products/Session were polluting os.environ > with SERVER_NAME and SERVER_PORT keys. > > - The unit tests in Products/SiteAccess were relying on the old > behavior of Testing.makerequest to unconditionally set those > keys in the request. > > - My change allowed the values from the Sessions tests to show up > in the SiteAccess tests. > > I've fixed the Sessions tests to use a dict instead of os.environ. > > But I'm also concerned that similarly indirect breakage might happen > in other projects if they use os.environ carelessly. > > This part of my change was an effort to remove redundancy, > not a bugfix; so on second thought, given the demonstrated > potential for breakage in other test suites, it doesn't > belong on the stable 2.9 branch and I'll revert that change there. > But I'll leave it on the trunk. +1 for getting rid of *anything* in Testing which does something as Utterly Evil (tm) as scribbling on 'os.environ'. Any tests which break on that account should be fixed, not covered over. You don't risk breaking production code, only tests, and those *need* to be fixed, even when running against the "stable" tree (I would even think backporting to 2.8 was worthwhile, just for the testing bugs it would expose). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] 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 iD8DBQFENZBb+gerLs4ltQ4RAntpAJ9iRnL8zZPMtaNGrQrKxAhxD7L7JgCgmC3O K/mIjFr++qV6xpo2L+x60vg= =1xn+ -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 )
[Zope-dev] Re: [Checkins] SVN: Zope/trunk/ Fixed collector 2057: Testing.makequest broke getPhysicalPath()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Winkler wrote: > On Thu, Apr 06, 2006 at 11:17:20AM +0200, Stefan H. Holek wrote: > >>For the record: I am still opposed to this change. It basically >>endows the request (as in self.REQUEST) with a getPhysicalPath >>method, and I have no idea what kind of side-effects this may have. > > > That's because there aren't any ;-) > > The only way you can ever hit REQUEST.getPhysicalPath is if > you specifically ask for it, which is obviously stupid; or if > the object you're wrapping doesn't terminate getPhysicalPath(). > > >>AFAICS your test suite is the only suite around that wants to request- >>wrap non-root objects. > > > I'd reprhase that as "... wants to request-wrap non-Zope2.app() > objects." > > FWIW, I didn't write it, and at the time those tests were added, > I believe they worked. This was using zope 2.8.something. > > I know who originally added those tests, That would be me. I don't see anything wrong with using a non-Zope2-app object for unit testing: in fact, I think it is *superior* practice. Most tests don't need to have the whole shooting match of the Zope startup dance done, and in fact will be better unit tests if they are tested *outside* of that environment. > I was hired several months later and discovered some apparent bit-rot in > our test suite, i.e. a number of failures and errors, and one of the > principal points of failure was the issue we're discussing. > I'm not sure, but I'm guessing that the calls to getPhysicalPath() in > our app were added later, and whoever did that must've punted on > figuring out the resulting test issues. I think you will see lots of usage of the pattern in CMF and related products: the RequestTest and SecurityRequestTest base classes from CMFCore are used *everywhere*. The only caveat is that, if your tests *needs* to call 'getPhysicalPath' and get a "realistic" value, you need to ensure that the object used as the root does the Right Thing (TM). > >>There's nothing wrong with using your own >>makerequest for your own test suite, if this is what you want. But I >>don't think your use-case warrants changing Zope. > > > Noted, and that's a reasonable position. Does nobody else care? I don't beleive that "must be a Zope2.app()" is a real part of the contract of 'makerequest': "must be able to emulate one well enough for the rest of the test to succeed" is. > Using an Item or Folder as your root object for tests works fine except for > this one issue, so why not allow that? > My feeling is that setting up an app is unnecessary work when you > don't need one; for one thing, your test module needs to call > Zope2.startup() first; for another, afaict creating a Zope2.app is > a couple orders of magnitude slower than creating a SimpleItem. > > So maybe more people *should* use makerequest(NotAnApp) ;-) +1. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] 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 iD8DBQFENY+6+gerLs4ltQ4RAiB7AJ9s/Ntu6pkWN8nyiQ6ifNfCj7DgPwCgzg0g SwE3IdhmcFdEnDL5kIpIiYU= =26iW -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] Zope Test Summaries 2006-04-05
On Thu, Apr 06, 2006 at 12:06:25PM -0400, Paul Winkler wrote: > On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote: > > The VHM tests in Zope 2.9 and trunk broke last night: > > > > http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html > > http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html > > I'm assuming this was me, but I ran test.py -q -all before checking in > so I'm not sure how that happened. Investigating. Must've run the tests in the wrong sandbox :-\ This failure was a side-effect of the changes I made: - The unit tests in Products/Session were polluting os.environ with SERVER_NAME and SERVER_PORT keys. - The unit tests in Products/SiteAccess were relying on the old behavior of Testing.makerequest to unconditionally set those keys in the request. - My change allowed the values from the Sessions tests to show up in the SiteAccess tests. I've fixed the Sessions tests to use a dict instead of os.environ. But I'm also concerned that similarly indirect breakage might happen in other projects if they use os.environ carelessly. This part of my change was an effort to remove redundancy, not a bugfix; so on second thought, given the demonstrated potential for breakage in other test suites, it doesn't belong on the stable 2.9 branch and I'll revert that change there. But I'll leave it on the trunk. -- Paul Winkler http://www.slinkp.com ___ 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] Re: [Checkins] SVN: Zope/trunk/ Fixed collector 2057: Testing.makequest broke getPhysicalPath()
On Thu, Apr 06, 2006 at 11:17:20AM +0200, Stefan H. Holek wrote: > For the record: I am still opposed to this change. It basically > endows the request (as in self.REQUEST) with a getPhysicalPath > method, and I have no idea what kind of side-effects this may have. That's because there aren't any ;-) The only way you can ever hit REQUEST.getPhysicalPath is if you specifically ask for it, which is obviously stupid; or if the object you're wrapping doesn't terminate getPhysicalPath(). > AFAICS your test suite is the only suite around that wants to request- > wrap non-root objects. I'd reprhase that as "... wants to request-wrap non-Zope2.app() objects." FWIW, I didn't write it, and at the time those tests were added, I believe they worked. This was using zope 2.8.something. I know who originally added those tests, and he's pretty high profile in the community, so I wouldn't be surprised if there are many such tests around. I was hired several months later and discovered some apparent bit-rot in our test suite, i.e. a number of failures and errors, and one of the principal points of failure was the issue we're discussing. I'm not sure, but I'm guessing that the calls to getPhysicalPath() in our app were added later, and whoever did that must've punted on figuring out the resulting test issues. > There's nothing wrong with using your own > makerequest for your own test suite, if this is what you want. But I > don't think your use-case warrants changing Zope. Noted, and that's a reasonable position. Does nobody else care? Using an Item or Folder as your root object for tests works fine except for this one issue, so why not allow that? My feeling is that setting up an app is unnecessary work when you don't need one; for one thing, your test module needs to call Zope2.startup() first; for another, afaict creating a Zope2.app is a couple orders of magnitude slower than creating a SimpleItem. So maybe more people *should* use makerequest(NotAnApp) ;-) -- Paul Winkler http://www.slinkp.com ___ 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] Re: What from zope.app are you using
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 ___ 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] What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] Very minor bugfix suggestion. Strip role names
+1, I've made similar mistakes, very very frustrating. On Thu, Apr 06, 2006 at 06:31:39PM +0200, Lennart Regebro wrote: > When adding new rols through the ZMI it is easy to accidentaly let > trailing or leading spaces stay in the role name, especially if you > cut and paste. Debugging that is very annoying because that leading > and trailing space is not visible anywhere. > > So, I suggest to just add a .strip() like so (This is in Roles.py): > def manage_defined_roles(self, submit=None, REQUEST=None): > """Called by management screen. > """ > > if submit=='Add Role': > role=reqattr(REQUEST, 'role') > return self._addRole(role.strip(), REQUEST) > > > -- > Lennart Regebro, Nuxeo http://www.nuxeo.com/ > CPS Content Management http://www.cps-project.org/ > ___ > 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 ) -- Paul Winkler http://www.slinkp.com ___ 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] Re: What from zope.app are you using
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
___
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] Very minor bugfix suggestion. Strip role names
When adding new rols through the ZMI it is easy to accidentaly let trailing or leading spaces stay in the role name, especially if you cut and paste. Debugging that is very annoying because that leading and trailing space is not visible anywhere. So, I suggest to just add a .strip() like so (This is in Roles.py): def manage_defined_roles(self, submit=None, REQUEST=None): """Called by management screen. """ if submit=='Add Role': role=reqattr(REQUEST, 'role') return self._addRole(role.strip(), REQUEST) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] Zope Test Summaries 2006-04-05
--On 6. April 2006 12:06:25 -0400 Paul Winkler <[EMAIL PROTECTED]> wrote: On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote: The VHM tests in Zope 2.9 and trunk broke last night: http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html zope-tests? I've never seen that list :-) But this reminds of that I am missing mails from the buildbotnobody broke the the trunk/branches lately? Unbelieveble :-) Andreas pgpJkV028Jox3.pgp Description: 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 )
[Zope-dev] Re: What from zope.app are you using
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 ___ 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] Zope Test Summaries 2006-04-05
On Thu, Apr 06, 2006 at 10:45:11AM +0200, Stefan H. Holek wrote: > The VHM tests in Zope 2.9 and trunk broke last night: > > http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html > http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html I'm assuming this was me, but I ran test.py -q -all before checking in so I'm not sure how that happened. Investigating. -- Paul Winkler http://www.slinkp.com ___ 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] What from zope.app are you using
Brian Sutherland wrote: > Ok, I make some tests without importing any of those dependencies, the > issues I have found thus far: > > * missing factory directive Recent Five releases should have it. It's deprecated now, though. > * missing class directive It's in the recent bugfix releases. I just haven't gotten around announcing them since, partially because there's another important bugfix in the pipe that would classify for another round of bugfix releases. > * zope.View permission not defined This can easily be fixed by redefining the zope.View permission to the zope.View permission: By the way, I'm keeping an updated version of the proposal at http://codespeak.net/svn/user/philikon/MakeZopeAppSmaller.txt (will periodically sync this with the one at zope.org). Philipp ___ 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] Re: What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] What from zope.app are you using
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 ___ 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] What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] What from zope.app are you using
On Thu, Apr 06, 2006 at 12:12:05AM +0200, Philipp von Weitershausen wrote: > Brian Sutherland wrote: > > On Wed, Apr 05, 2006 at 11:18:46PM +0200, Philipp von Weitershausen wrote: > >> Brian Sutherland 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. > >>> Er, FiveSQLOS is using quite a lot actually: > >>> > >>> https://codespeak.net/svn/z3/sqlos/trunk/Zope2/FiveSQLOS/dependencies-meta.zcml > >>> https://codespeak.net/svn/z3/sqlos/trunk/Zope2/FiveSQLOS/dependencies.zcml > >> Why are you loading zope.app.component/meta.zcml and > >> zope.app.security/meta.zcml? Five should provide all the necessary > >> directive registrations > > > > I havn't touched that code since the Zope2.8 days. I'll believe you for > > now and try testing it when the dust has settled. > > Ok. By the way, that "should" in "Five should provide..." also means > that if Five doesn't provide the necessary directive registrations yet > (which might very well be), then we need to make it. Ok, I make some tests without importing any of those dependencies, the issues I have found thus far: * missing factory directive * missing class directive * zope.View permission not defined This is not an exhaustive list and all of them came from the file: http://codespeak.net/svn/z3/sqlos/trunk/src/sqlos/configure.zcml > > >> As for zope.app.rdb, I guess we'll have to move it down to zope.rdb. > > > > I can probably take care of that in the next days. > > Great. Note that I'm working on the jim-adapter branch. I suggest you do > your modifications there as well. sure. > > Philipp > > ___ > 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 ) > -- Brian Sutherland Metropolis - "it's the first movie with a robot. And she's a woman. And she's EVIL!!" ___ 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] What from zope.app are you using
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 ___ 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] Re: What from zope.app are you using
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 ___ 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] What from zope.app are you using
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 ___ 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] Re: [Checkins] SVN: Zope/trunk/ Fixed collector 2057: Testing.makequest broke getPhysicalPath()
For the record: I am still opposed to this change. It basically
endows the request (as in self.REQUEST) with a getPhysicalPath
method, and I have no idea what kind of side-effects this may have.
AFAICS your test suite is the only suite around that wants to request-
wrap non-root objects. There's nothing wrong with using your own
makerequest for your own test suite, if this is what you want. But I
don't think your use-case warrants changing Zope.
Stefan
On 5. Apr 2006, at 22:51, Paul Winkler wrote:
Log message for revision 66581:
Fixed collector 2057: Testing.makequest broke getPhysicalPath()
when used on anything other than an app object.
Also added an 'environ' argument if you want to use something
other than os.environ, and added a couple trivial tweaks from
ZopeTestCase.makereqeust.
Added unit tests for this stuff.
Changed:
U Zope/trunk/doc/CHANGES.txt
U Zope/trunk/lib/python/Testing/makerequest.py
A Zope/trunk/lib/python/Testing/tests/
A Zope/trunk/lib/python/Testing/tests/__init__.py
A Zope/trunk/lib/python/Testing/tests/test_makerequest.py
-=-
Modified: Zope/trunk/doc/CHANGES.txt
===
--- Zope/trunk/doc/CHANGES.txt 2006-04-05 20:04:59 UTC (rev 66580)
+++ Zope/trunk/doc/CHANGES.txt 2006-04-05 20:51:21 UTC (rev 66581)
@@ -46,6 +46,9 @@
Features added
+ - Testing.makerequest: Added an 'environ' argument so
+clients can use mappings other than os.environ.
+
- Updated to Docutils 0.4.0
- reStructuredText: The default value for the 'stylesheet'
@@ -202,6 +205,10 @@
Bugs Fixed
+ - Collector #2057: Allow Testing.makerequest to work with
+ any acquisition-supporting root object, not just Zope2.app.
+Formerly, if you did that, getPhysicalPath() was broken.
+
- Collector #2051: Applied patch by Yoshinori Okuji to fix some
XML export/import problems, including tests for that feature.
Modified: Zope/trunk/lib/python/Testing/makerequest.py
===
--- Zope/trunk/lib/python/Testing/makerequest.py 2006-04-05
20:04:59 UTC (rev 66580)
+++ Zope/trunk/lib/python/Testing/makerequest.py 2006-04-05
20:51:21 UTC (rev 66581)
@@ -19,27 +19,50 @@
import makerequest
app = makerequest.makerequest(Zope2.app())
+You can optionally pass stdout to be used by the response,
+and an environ mapping to be used in the request.
+Defaults are sys.stdout and os.environ.
+
+If you don't want to start a zope app in your test, you can wrap
other
+objects, but they must support acquisition and you should only wrap
+your root object.
+
+
$Id$
"""
import os
-from os import environ
from sys import stdin, stdout
from ZPublisher.HTTPRequest import HTTPRequest
from ZPublisher.HTTPResponse import HTTPResponse
from ZPublisher.BaseRequest import RequestContainer
-def makerequest(app, stdout=stdout):
+def makerequest(app, stdout=stdout, environ=None):
resp = HTTPResponse(stdout=stdout)
-environ['SERVER_NAME']='foo'
-environ['SERVER_PORT']='80'
-environ['REQUEST_METHOD'] = 'GET'
+if environ is None:
+environ = os.environ
+environ.setdefault('SERVER_NAME', 'foo')
+environ.setdefault('SERVER_PORT', '80')
+environ.setdefault('REQUEST_METHOD', 'GET')
req = HTTPRequest(stdin, environ, resp)
-
+req._steps = ['noobject'] # Fake a published object.
+req['ACTUAL_URL'] = req.get('URL') # Zope 2.7.4
+
# set Zope3-style default skin so that the request is usable for
-# Zope3-style view look-ups
+# Zope3-style view look-ups.
from zope.app.publication.browser import setDefaultSkin
setDefaultSkin(req)
-return app.__of__(RequestContainer(REQUEST = req))
+requestcontainer = RequestContainer(REQUEST = req)
+# Workaround for collector 2057: ensure that we don't break
+# getPhysicalPath if app has that method.
+# We could instead fix Traversable.getPhysicalPath() to check for
+# existence of p.getPhysicalPath before calling it; but it's such
+# a commonly called method that I don't want to impact
performance
+# for something that AFAICT only affects makerequest() in
+# practice.
+if getattr(app, 'getPhysicalPath', None) is not None:
+requestcontainer.getPhysicalPath = lambda: ()
+
+return app.__of__(requestcontainer)
Added: Zope/trunk/lib/python/Testing/tests/__init__.py
===
--- Zope/trunk/lib/python/Testing/tests/__init__.py 2006-04-05
20:04:59 UTC (rev 66580)
+++ Zope/trunk/lib/python/Testing/tests/__init__.py 2006-04-05
20:51:21 UTC (rev 66581)
@@ -0,0 +1 @@
+#
Property changes on: Zope/trunk/lib/python/Testing/tests/__init__.py
___
Name: svn:keywords
+ "Author Date Revision"
Added: Zope/trunk/lib/python/Testing/tests/tes
[Zope-dev] Re: What from zope.app are you using
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 ___ 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 Test Summaries 2006-04-05
[We seem to have lost Steve Alexander's test summarizer. I will contact him in a separate mail.] The switch to Python 2.3.4 caused tests for Zope 2.7 and 2.8 to experience a funny problem with the logging module. Anybody want to take a guess what's up here? I know these are not a truly "supported" configurations, but still. http://mail.zope.org/pipermail/zope-tests/2006-April/004645.html http://mail.zope.org/pipermail/zope-tests/2006-April/004647.html The VHM tests in Zope 2.9 and trunk broke last night: http://mail.zope.org/pipermail/zope-tests/2006-April/004648.html http://mail.zope.org/pipermail/zope-tests/2006-April/004649.html Stefan -- Anything that happens, happens. --Douglas Adams ___ 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 )
