Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
Hello from the grok department, On 4 March 2011 11:48, Brian Sutherland wrote: > On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote: >> >> Hello, >> >> On Fri, 4 Mar 2011 10:15:18 +0100 >> Brian Sutherland wrote: >> >> > > In zope.app.wsgi all those idiosyncracies are more or less >> > > handled by a WSGI middleware. I guess you can reuse it. >> > > >> > > One of the purpose of the zope.app.wsgi implementation was to be >> > > able to convert the existing tests just by changing the import, and >> > > get ride of zope.testbrowser dependencies on the crazy >> > > zope.app.testing nobody-knows-what-it-does-and-does-everything in >> > > Grok (without adding many others). Which worked perfectly. >> > >> > I'll definitely look into reusing the middleware. >> > >> > But, tell me, how do I run all the grok tests? (So I can see what >> > idiosyncracies are required) >> > >> >> There is a Grok ToolKit, that works exactly like the Zope ToolKit: >> >> http://svn.zope.org/groktoolkit/trunk >> >> If you run this buildout you should get a ./bin/test-grok command >> that runs all the tests, using z3c.recipe.compattest. >> >> Actually, I think you can start by testing only grokcore.view. I >> guess it is one of the base packages that uses a lot the test browser. > > Ok, there are 2 grokcore.view failures with my branch. > > The first is due to the Basic Auth header and is fixable by adding the > middleware we were talking about. To get the groktoolkit tests and my company's applications to run with Brian's zope.testbrowser+webtest branch I did the following things: * I created a branch of zope.app.wsgi trunk [1] to which I copied the AuthorizationMiddleware from zope.testbrowser trunk (moved there in [2]). The three middleware components (Transaction, Authorization and HandleErrors) are needed to make the groktoolkit tests pass. The AuthorizationMiddleware is not available on Brian's branch, but is available on zope.testbrowser trunk. If we can land this middleware in zope.testbrowser, we can again remove it from zope.app.wsgi.testlayer. In my opinion, this middleware should be part of zope.testbrowser, because handleErrors is part of the IBrowser interface. * The `http caller` in zope.app.wsgi.testlayer is used in grokcore.rest. On my branch, I rewrote the http caller to use WebTest and _APP_UNDER_TEST instead of wsgi_intercept. The import from zope.testbrowser is bothering me; can we put the http caller in zope.testbrowser? The http caller returns a FakeResponse instance, which could very well be a WebTest TestResponse. The FakeResponse wrapper is merely used to fix the current tests. * I fixed some tests in grok and grokcore.rest to use the WebTest-style http caller. > The other is more interesting, in > src/grokcore/view/ftests/url/redirect.py. It seems that that test is > actually making calls over the network to google's servers. Probably not > a good thing. > > The new behaviour (probably not good either) is to send the request to > the application even if the hostname is "www.google.com". > > I would guess that the right behaviour would be to raise an error if the > hostname is not "localhost" or 127.0.0.1. +1 In order to run the tests on the groktoolkit trunk, run: bin/buildout sources:zope.testbrowser="svn svn+ssh://svn.zope.org/repos/main/zope.testbrowser/branches/jinty-webtest3" sources:zope.app.wsgi="svn svn+ssh://svn.zope.org/repos/main/zope.app.wsgi/branches/janjaapdriessen-webtest" buildout:auto-checkout="zope.testbrowser zope.app.wsgi grok grokcore.rest" versions:WebTest=1.2.3 && bin/test-grok -- Jan-Jaap Driessen 1) http://zope3.pov.lt/trac/changeset/120756/zope.app.wsgi/branches/janjaapdriessen-webtest/src/zope/app/wsgi/testlayer.py 2) http://zope3.pov.lt/trac/changeset/119878/zope.app.wsgi/trunk/src/zope/app/wsgi/testlayer.py ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Sprints at PyCon
Am 10.02.2011, 07:07 Uhr, schrieb Christian Theune : > Who's coming? Who's interested? Any topic suggestions? I'll be there and hoping to finalise my work on CMF so that we can release 2.3 Is anyone bringing copies of the DZUG Brochure on Zope? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 90 OK, 16 Failed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit > From: ccomb at free.fr > Date: Thu Mar 3 22:13:09 EST 2011 > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033836.html > > Subject: FAILED : ZTK 1.0dev / Python2.6.5 Linux 64bit > From: ccomb at free.fr > Date: Thu Mar 3 22:13:26 EST 2011 > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033837.html > > Subject: FAILED : ZTK 1.0dev / Python2.5.5 Linux 64bit > From: ccomb at free.fr > Date: Thu Mar 3 22:13:40 EST 2011 > URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033838.html This is some infuruating doctest-based failure in /home/ccomb/ztk1.0dev-slave/Python2.6.5-Linux-64bit/build/src/zope.testing/src/zope/testing/testrunner/testrunner-layers-buff.txt I'm never gonna diagnose that one. In re the various 'z3c' failures: if we can't pin them to an earlier lxml version, can we at least disable them until we have the lxml binary available? The noise is counterproductive. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1xCfcACgkQ+gerLs4ltQ7sWwCfTBklPQ4pEX7S4FV0qQUD+qC8 ossAn3mLDIF4nMoKRNsfKFtgwFgUjI6g =qw+J -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 90 OK, 16 Failed
Summary of messages to the zope-tests list. Period Thu Mar 3 12:00:00 2011 UTC to Fri Mar 4 12:00:00 2011 UTC. There were 106 messages: 8 from Zope Tests, 4 from buildbot at pov.lt, 38 from buildbot at winbot.zope.org, 11 from ccomb at free.fr, 45 from jdriessen at thehealthagency.com. Test failures - Subject: FAILED : winbot / z3c.pagelet_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 09:02:20 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033757.html Subject: FAILED : winbot / z3c.rml_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 09:21:11 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033759.html Subject: FAILED : winbot / z3c.coverage_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 09:35:12 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033761.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.6 slave-win From: jdriessen at thehealthagency.com Date: Thu Mar 3 12:41:46 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033768.html Subject: FAILED : Zope Buildbot / zope2.13_win-py2.7 slave-win From: jdriessen at thehealthagency.com Date: Thu Mar 3 12:44:17 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033770.html Subject: FAILED : Zope 3.4 Known Good Set / py2.4-64bit-linux From: buildbot at pov.lt Date: Thu Mar 3 21:17:52 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033830.html Subject: FAILED : winbot / z3c.ptcompat_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 22:10:45 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033840.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit From: ccomb at free.fr Date: Thu Mar 3 22:13:09 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033836.html Subject: FAILED : ZTK 1.0dev / Python2.6.5 Linux 64bit From: ccomb at free.fr Date: Thu Mar 3 22:13:26 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033837.html Subject: FAILED : ZTK 1.0dev / Python2.5.5 Linux 64bit From: ccomb at free.fr Date: Thu Mar 3 22:13:40 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033838.html Subject: FAILED : winbot / z3c.rml_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 22:32:23 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033841.html Subject: FAILED : winbot / z3c.form_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 22:49:11 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033842.html Subject: FAILED : winbot / z3c.coverage_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 23:22:47 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033844.html Subject: FAILED : winbot / z3c.macro_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 23:23:49 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033845.html Subject: FAILED : winbot / z3c.pagelet_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 23:32:07 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033846.html Subject: FAILED : winbot / z3c.template_py_265_32 From: buildbot at winbot.zope.org Date: Thu Mar 3 23:53:40 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033847.html Tests passed OK --- Subject: OK : winbot / ZODB_dev py_270_win64 From: buildbot at winbot.zope.org Date: Thu Mar 3 07:17:41 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033752.html Subject: OK : winbot / ztk_10 py_254_win32 From: buildbot at winbot.zope.org Date: Thu Mar 3 07:26:15 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033753.html Subject: OK : winbot / ZODB_dev py_265_win64 From: buildbot at winbot.zope.org Date: Thu Mar 3 08:22:34 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033754.html Subject: OK : winbot / zc_buildout_dev py_270_win32 From: buildbot at winbot.zope.org Date: Thu Mar 3 08:38:08 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033755.html Subject: OK : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Thu Mar 3 08:57:35 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033756.html Subject: OK : winbot / zc_buildout_dev py_254_win32 From: buildbot at winbot.zope.org Date: Thu Mar 3 09:18:48 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033758.html Subject: OK : winbot / zc_buildout_dev py_265_win64 From: buildbot at winbot.zope.org Date: Thu Mar 3 09:33:31 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033760.html Subject: OK : Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 From: jdriessen at thehealthagency.com Date: Thu Mar 3 12:24:42 EST 2011 URL: http://mail.zope.org/pipermail/zope-tests/2011-March/033762.html Subject: OK : Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 From: jdriessen at theh
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2 - modified proposal
Hi again! Based on the discussion I modified my proposal: - Products.Five.browser.decode should be marked as deprecated. It implements charset negotiation without making sure the 'Vary' header is set correctly. Fixing this will cause other caching issues. - The setPageEncoding() function will not be replaced at all. We just rely on HTTPResponse.setBody() if the 'Content-Type' header is not set explicitly by the view. It is recommended to set default-zpublisher-encoding to utf-8. This is how plone.z3cform currently handles this. - The processInputs() function is replaced by a HTTPRequest method called postProcessInputs(). This method first tries to decode with HTTPRequest.default_encoding. If that causes failures, it falls back to the encodings returned by getPreferredCharsets(). - Directly after traversal ZPublisher.Publish.publish() calls request.postProcessInputs() if the object implements zope.publisher.interfaces.browser.IBrowserPage. If there are no objections I'll implement it that way on Zope trunk. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Fri, Mar 04, 2011 at 10:25:59AM +0100, Sylvain Viollon wrote: > > Hello, > > On Fri, 4 Mar 2011 10:15:18 +0100 > Brian Sutherland wrote: > > > > In zope.app.wsgi all those idiosyncracies are more or less > > > handled by a WSGI middleware. I guess you can reuse it. > > > > > > One of the purpose of the zope.app.wsgi implementation was to be > > > able to convert the existing tests just by changing the import, and > > > get ride of zope.testbrowser dependencies on the crazy > > > zope.app.testing nobody-knows-what-it-does-and-does-everything in > > > Grok (without adding many others). Which worked perfectly. > > > > I'll definitely look into reusing the middleware. > > > > But, tell me, how do I run all the grok tests? (So I can see what > > idiosyncracies are required) > > > > There is a Grok ToolKit, that works exactly like the Zope ToolKit: > > http://svn.zope.org/groktoolkit/trunk > > If you run this buildout you should get a ./bin/test-grok command > that runs all the tests, using z3c.recipe.compattest. > > Actually, I think you can start by testing only grokcore.view. I > guess it is one of the base packages that uses a lot the test browser. Ok, there are 2 grokcore.view failures with my branch. The first is due to the Basic Auth header and is fixable by adding the middleware we were talking about. The other is more interesting, in src/grokcore/view/ftests/url/redirect.py. It seems that that test is actually making calls over the network to google's servers. Probably not a good thing. The new behaviour (probably not good either) is to send the request to the application even if the hostname is "www.google.com". I would guess that the right behaviour would be to raise an error if the hostname is not "localhost" or 127.0.0.1. > > Regards, > > Sylvain, > > -- > Sylvain Viollon -- Infrae > t +31 10 243 7051 -- http://infrae.com > Hoevestraat 10 3033GC Rotterdam -- The Netherlands -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Charlie Clark wrote: > Am 04.03.2011, 08:58 Uhr, schrieb yuppie: > >> If we always send UTF-8, their current implementation doesn't make much >> sense to me. Don't know if we really should try to fall back to all the >> charsets mentioned in Accept-Charset. But at least we should *always* >> try UTF-8 decoding first. > > I'm not sure if this is directly related but I remember Withers having a > discussion (alright, shouting match) with Andreas about cycling through > all kinds of encoding possibilities on the resolver. I can't find the > thread at the moment but I think it related to the way templates could be > edited TTW or how to handle situations of mixed encoding. I considered to propose that we don't use the IUserPreferredCharsets adapter at all in Zope 2 and remove its registration in ZCML. But then I noticed the code Andreas wrote in Products.PageTemplates.unicodeconflictresolver.PreferredCharsetResolver. I'm not going to start that discussion again. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Am 04.03.2011, 08:58 Uhr, schrieb yuppie : > If we always send UTF-8, their current implementation doesn't make much > sense to me. Don't know if we really should try to fall back to all the > charsets mentioned in Accept-Charset. But at least we should *always* > try UTF-8 decoding first. Hiya, I'm not sure if this is directly related but I remember Withers having a discussion (alright, shouting match) with Andreas about cycling through all kinds of encoding possibilities on the resolver. I can't find the thread at the moment but I think it related to the way templates could be edited TTW or how to handle situations of mixed encoding. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
Hello, On Fri, 4 Mar 2011 10:15:18 +0100 Brian Sutherland wrote: > > In zope.app.wsgi all those idiosyncracies are more or less > > handled by a WSGI middleware. I guess you can reuse it. > > > > One of the purpose of the zope.app.wsgi implementation was to be > > able to convert the existing tests just by changing the import, and > > get ride of zope.testbrowser dependencies on the crazy > > zope.app.testing nobody-knows-what-it-does-and-does-everything in > > Grok (without adding many others). Which worked perfectly. > > I'll definitely look into reusing the middleware. > > But, tell me, how do I run all the grok tests? (So I can see what > idiosyncracies are required) > There is a Grok ToolKit, that works exactly like the Zope ToolKit: http://svn.zope.org/groktoolkit/trunk If you run this buildout you should get a ./bin/test-grok command that runs all the tests, using z3c.recipe.compattest. Actually, I think you can start by testing only grokcore.view. I guess it is one of the base packages that uses a lot the test browser. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Thu, Mar 03, 2011 at 11:04:12AM +0100, Sylvain Viollon wrote: > On Wed, 02 Mar 2011 09:16:14 +0100 > Wolfgang Schnerring wrote: > > > Hello Brian, > > > > Hello, > > > it's taken a while, but I finally had a chance to review your > > branch(es). > > > > * Brian Sutherland [2011-02-12 18:57]: > > >> > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring > > >> > wrote: > > >> >> I'd prefer if we treated this as two separate steps, then: > > >> >> a) improve the testbrwoser+wsgi story by replacing > > >> >> wsgi_intercept with WebTest > > > > > > I pulled this out of my original branch and put it here: > > > > > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal > > > > Thanks, that helped me understand what's going on much better. > > > > I do have a few questions about this part: > > > > - Does the (webtest-based) wsgi.Browser behave similarly to the > > Publisher-Browser? > > > > When we ported the wsgi_intercept variant from zope.app.wsgi, we found > > that there were some idiosyncracies woven in that people may rely on. > > This kind of stuff of course isn't documented, and we didn't do much > > research, but rather took care to port what we found in zope.app.wsgi, > > namely filtering some HTTP headers from the response (meh, doesn't > > feel important), and handling Basic Auth headers (that feels > > important to preserve). > > > > > > Don't forget the support to do handleErrors = False. It is I think > one of the most important, which help to debug the tests. That's supported for both zope.app.wsgi and Paste applications. YMMV for other WSGI applications. > In zope.app.wsgi all those idiosyncracies are more or less handled by > a WSGI middleware. I guess you can reuse it. > > One of the purpose of the zope.app.wsgi implementation was to be able > to convert the existing tests just by changing the import, and get > ride of zope.testbrowser dependencies on the crazy zope.app.testing > nobody-knows-what-it-does-and-does-everything in Grok (without adding > many others). Which worked perfectly. I'll definitely look into reusing the middleware. But, tell me, how do I run all the grok tests? (So I can see what idiosyncracies are required) > Regards, > > Sylvain, > > -- > Sylvain Viollon -- Infrae > t +31 10 243 7051 -- http://infrae.com > Hoevestraat 10 3033GC Rotterdam -- The Netherlands > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) -- Brian Sutherland ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.testbrowser and WebTest (round 2)
On Wed, Mar 02, 2011 at 09:16:14AM +0100, Wolfgang Schnerring wrote: > Hello Brian, > > it's taken a while, but I finally had a chance to review your branch(es). Great! > * Brian Sutherland [2011-02-12 18:57]: > >> > On Tue, Feb 01, 2011 at 09:32:11AM +0100, Wolfgang Schnerring wrote: > >> >> I'd prefer if we treated this as two separate steps, then: > >> >> a) improve the testbrwoser+wsgi story by replacing wsgi_intercept with > >> >> WebTest > > > > I pulled this out of my original branch and put it here: > > > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3-minimal > > Thanks, that helped me understand what's going on much better. > > I do have a few questions about this part: > > - Does the (webtest-based) wsgi.Browser behave similarly to the > Publisher-Browser? > > When we ported the wsgi_intercept variant from zope.app.wsgi, we found > that there were some idiosyncracies woven in that people may rely on. > This kind of stuff of course isn't documented, and we didn't do much > research, but rather took care to port what we found in zope.app.wsgi, > namely filtering some HTTP headers from the response (meh, doesn't feel > important), and handling Basic Auth headers (that feels important to > preserve). I feel strongly that these idiosyncrasies shouldn't get built into the new WSGI testbrowser and perpetuated. You had some WSGI middleware which implemented these. I think we can do it in the same way and anyone migrating from Publisher-Browser based code could use it. Perhaps that needs to be inside zope.testbrowser itself, or could be done in zope.app.wsgi. Depends on the details I guess. Unfortunately, as you say, they are undocumented and seem to be untested. I would like to make a deeper investigation of those issues and write some tests. Is there any test suite (grok perhaps?) that I can run using the new WSGI based browser that'll highlight these issues? > - What should happen in zope.app.wsgi? > > We moved the wsgi-based Testbrowser from there and left BBB imports to > zope.testbrowser.wsgi, taking care to be API compatible. I guess that > won't be possible with the WebTest-based Testbrowser (or would it?), > so we probably have to break that. (Hmm, would that imply a major version > bump there, too?) > > Since the Grok people are the ones who probably use the zope.app.wsgi > Testbrowser the most, they should probably take the WebTest-Testbrowser > for a test drive and see whether it works for them, otherwise we're > going to make them quite unhappy if we just break zope.app.wsgi. > (Could you ask on grok-dev about that? I guess it's too buried here to > be noticed.) I'll try to co-ordinate with the grok/zope.app.wsgi developers on this. I was unaware that they had BBB imports from zope.testbrowser. > - What's connection.py? > > I don't really understand where that came from or what its purpose is, > especially since wsgi.py seems to be the only one that uses it? > > Ah. I take that last bit back, the extracted Publisher-Browser in > zope.app.testing uses it, so I guess this is a split-off artifact of the > refactoring/extraction. > > But I still don't really understand what it is all about. %-) It's about minimizing the duplicated code in zope.app.testing.testbrowser and zope.testbrowser.wsgi. It's kind of "reusable pieces to build zope.testbrowser connections". That said, I'm uncomfortable with it. connection.py is probably not really very reusable. And anyone changing it would have to be aware that it was reused in zope.app.testing. Another way would be to fold connection.py into zope.testbrowser.wsgi and copy the necessary code to zope.app.testing. It's not obvious to me which way is better. You could easily persuade me another way is better. > - The layer looks good. (OK, so that's not a question ;) > > I'm glad you found a way that the browser can get the application "out > of the air". I've tried the explicit passing way on a project of mine, > and it's a huge hassle (I've ended up stuffing a preconfigured browser > instance into the doctest globs, ugh.) yeah, in the end wsgi_intercept uses global variables. So it's the same approach. > I think it would be good if the layer stored the application of > self.app, we did that in the wsgi_intercept variant and were glad of it > a few times already. Sure, I've added that. > >> >> b) extract the testbrowser part that talks to the Publisher > > > > This is here and by necessity includes the changes for step (a): > > svn+ssh://svn.zope.org/repos/main/zope.testbrowser/jinty-webtest3 > > > > svn+ssh://svn.zope.org/repos/main/zope.app.testing/branches/jinty-testbrowser > > The extraction of the Publisher-Browser makes a lot of sense, and looks > clean to me, as does the rewrite of the tests to use a plain WSGI app > instead of a Zope-based app. Great! > > I would much prefer to merge both steps together. > > Yes, I guess that makes sense because only step (b) includes proper > tes
Re: [Zope-dev] ZPublisher: using zope.formlib and z3c.form in Zope 2
Hi! Laurence Rowe wrote: > On 2 March 2011 11:29, yuppie wrote: >> Laurence Rowe wrote: >>> On 2 March 2011 10:00, yuppiewrote: Martin Aspeli wrote: > I don't know what setPageEncoding() does, though. It sets a response Content-Type header with the first charset processInputs tries for decoding. >>> >>> Is the charset of the request necessarily the right choice for the >>> response? In Plone we always serve UTF-8 encoded. >> >> getPreferredCharsets()[0] always returns 'utf-8' **if** UTF-8 is accepted. >> >> If 'utf-8' is not in getPreferredCharsets(), it is not very likely that >> the browser speaks UTF-8 and processInputs will not even try to decode >> with UTF-8. In that case it might be better to respond with an accepted >> encoding. > > If you serve differently encoded pages then you should set Vary: > Accept-Charset. That seems to be correct. So you found a bug in zope.publisher and five.formlib. If they do charset negotiation, they have to set Vary. > But then without normalization you'd get an explosion > of different page variations. AFAICS that normalization can't be done by the server and we can't prevent ineffective caching. > Without the Vary, it means that a visitor can poison the cache by > supplying (only) a weird charset in Accept-Encoding. The page would > then be served in this encoding, cached downstream, and if other > visitor's browsers don't support that charset then they have a > problem. That sounds like charset negotiation isn't a good idea and neither zope.publisher nor five.formlib should do it. If we don't negotiate the charset, we should still have a setPageEncoding method that overrides the ZPublisher default_encoding with UTF-8. But what does all that mean for the processInputs methods in Five (used by five.formlib) and in plone.z3cform? If we always send UTF-8, their current implementation doesn't make much sense to me. Don't know if we really should try to fall back to all the charsets mentioned in Accept-Charset. But at least we should *always* try UTF-8 decoding first. Cheers, Yuppie ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
