Re: [Zope-dev] traversal and __before_publishing_traverse__ conflict
I have commited a possible fix in a wichert=request-modifier branch. I made a change which tests if a traversal step did any real traversing or only did something else and use that to control calling of the before publish hook. All Zope tests are passing with this change. Wichert. On 2010-2-21 21:21, Wichert Akkerman wrote: > Apologies for the cross post, but since there are many components > involved here I'm not sure what the right list is. > > Plone uses plone.theme to set an IBrowserSkinType on the request that > matches the currently selected CMF skin. This is very useful since it > allows you to register browser views and other components for a CMF > skin. plone.theme does this by using the __before_publishing_traverse__ > hook on the site root. > > For one site I want to offer a different skin to people coming in via a > separate URL. I do this by proxying to the site and adding a ++skin++ > traverser to set the skin layer. > > However this does not work due to how Zope 2 publication works. What > happens is this: > > 1. ZPublisher traverses over the site root and calls the > CMF __before_publishing_traverse__ hooks. Via a IBeforeTraverseEvent > event plone.theme gets called and adds a IBrowserSkinType layer > for the current CMF skin. > 2. ZPublisher handles ++skin++name, which sets an IBrowserSkinType layer > for my new skin, replacing the layer set by plone.theme. The > traverser returns the same object, our site root, again. > 3. ZPublishes procees by calling the __before_publishing_traverse__ for > the site root again, which ends up calling plone.theme again and > replacing my skin layer again. > > The problem here is that a ++skin++ traverser always returns the same > object again, and ZPublisher will happily treat it as a new object and > call all hooks for it again. > > The only way to avoid this that I can see is to make ZPublisher check if > a traversal step returns the same object again, and if so skip > the __before_publishing_traverse__ hook in that case. This feels like a > safe change, but I am not sure if this would break anything. > > Wichert. > -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] traversal and __before_publishing_traverse__ conflict
Apologies for the cross post, but since there are many components involved here I'm not sure what the right list is. Plone uses plone.theme to set an IBrowserSkinType on the request that matches the currently selected CMF skin. This is very useful since it allows you to register browser views and other components for a CMF skin. plone.theme does this by using the __before_publishing_traverse__ hook on the site root. For one site I want to offer a different skin to people coming in via a separate URL. I do this by proxying to the site and adding a ++skin++ traverser to set the skin layer. However this does not work due to how Zope 2 publication works. What happens is this: 1. ZPublisher traverses over the site root and calls the CMF __before_publishing_traverse__ hooks. Via a IBeforeTraverseEvent event plone.theme gets called and adds a IBrowserSkinType layer for the current CMF skin. 2. ZPublisher handles ++skin++name, which sets an IBrowserSkinType layer for my new skin, replacing the layer set by plone.theme. The traverser returns the same object, our site root, again. 3. ZPublishes procees by calling the __before_publishing_traverse__ for the site root again, which ends up calling plone.theme again and replacing my skin layer again. The problem here is that a ++skin++ traverser always returns the same object again, and ZPublisher will happily treat it as a new object and call all hooks for it again. The only way to avoid this that I can see is to make ZPublisher check if a traversal step returns the same object again, and if so skip the __before_publishing_traverse__ hook in that case. This feels like a safe change, but I am not sure if this would break anything. Wichert. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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: 6 OK
Summary of messages to the zope-tests list. Period Sat Feb 20 12:00:00 2010 UTC to Sun Feb 21 12:00:00 2010 UTC. There were 6 messages: 6 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Feb 20 20:37:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013605.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Feb 20 20:39:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013606.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Feb 20 20:41:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013607.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Feb 20 20:43:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013608.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Feb 20 20:45:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013609.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Feb 20 20:47:00 EST 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-February/013610.html ___ 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] Adding W3C validating to zope.testbrowser
Hi, (removed plone.devel cross-post) On 02/20/2010 01:53 PM, Ross Patterson wrote: > I started a branch for doing W3C HTML validation on responses to > zope.testbrowser requests: > > svn://svn.zope.org/repos/main/zope.testbrowser/branches/rossp-validator > > The idea is to be able to flip a switch and run all my functional > zope.testbrowser tests and see validation failures as test failures. > The current implementation in that branch just uses a simple environment > variable since I wasn't sure what the best way was to support flipping a > switch like that. Note that it's possible to use a local installation > of the W3C validator (such as is available on Debian based systems in > the w3c-markup-validator package) so that the validation doesn't > actually slow tests down all that much. > > I have a couple of questions I'd like to hear any thoughts on. > > What's the best way to support "flipping the switch" in a global sense > so that during the inner testing loop extra time isn't being wasted on > repeated validations? I would not look at environment variables within the testbrowser code at all but stick to Python's mechanics to store "global" or local data. The test runner could grow an option then which can influence that switch beforehand. (E.g. via a feature) I think that's one of the valid use cases of "arbitrary" plugins for the test runner. Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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] Adding W3C validating to zope.testbrowser
Ross Patterson writes: > I started a branch for doing W3C HTML validation on responses to > zope.testbrowser requests: > > svn://svn.zope.org/repos/main/zope.testbrowser/branches/rossp-validator > > The idea is to be able to flip a switch and run all my functional > zope.testbrowser tests and see validation failures as test failures. > The current implementation in that branch just uses a simple environment > variable since I wasn't sure what the best way was to support flipping a > switch like that. Note that it's possible to use a local installation > of the W3C validator (such as is available on Debian based systems in > the w3c-markup-validator package) so that the validation doesn't > actually slow tests down all that much. > > I have a couple of questions I'd like to hear any thoughts on. > > What's the best way to support "flipping the switch" in a global sense > so that during the inner testing loop extra time isn't being wasted on > repeated validations? > > Does this belong in zope.testbrowser or in the underlying mechanize > package? Another option would be to integrate this with the publisher itself. For example, an option could be provided for validating the HTML to be returned by the publisher whenever it's running in validating mode, similar to debug mode. It seems like this could make the validating service more accessible to less technical users. I'm not really sure where this belongs. Ross > Other than that, what's the path forward to merging? > > Ross > > ___ > 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 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 )
