After consulting with Andreas, there will be a Zope 2.9.3 bugfix release next Monday. It will contain some more Zope 3 packages that were forgotten in the initial Zope 2.9 release line (my bad). There will also be one or two Five bugfixes. If you have a bugfix in the line for Zope 2.9, you have till Sunday night :). Philipp
Previously Philipp von Weitershausen wrote:
After consulting with Andreas, there will be a Zope 2.9.3 bugfix release next Monday. It will contain some more Zope 3 packages that were forgotten in the initial Zope 2.9 release line (my bad). There will also be one or two Five bugfixes.
If you have a bugfix in the line for Zope 2.9, you have till Sunday night :).
Is Alec's traversal patch or Dieter's alternative being considered? Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
Previously Philipp von Weitershausen wrote:
After consulting with Andreas, there will be a Zope 2.9.3 bugfix release next Monday. It will contain some more Zope 3 packages that were forgotten in the initial Zope 2.9 release line (my bad). There will also be one or two Five bugfixes.
If you have a bugfix in the line for Zope 2.9, you have till Sunday night :).
Is Alec's traversal patch or Dieter's alternative being considered?
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1. 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 iD8DBQFERo/k+gerLs4ltQ4RAqsRAJ4wVHKCe3hSPP9D08RGT+IwWr2BbgCcDckM X+8XcBIHsr+fhGTT6hHDNFE= =jwlb -----END PGP SIGNATURE-----
--On 19. April 2006 15:30:44 -0400 Tres Seaver <tseaver@palladion.com> wrote:
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
Do you say that we introduced an incompatibility in 2.9.2? -aj ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jung wrote:
--On 19. April 2006 15:30:44 -0400 Tres Seaver <tseaver@palladion.com> wrote:
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
Do you say that we introduced an incompatibility in 2.9.2?
Yes. The change was introduced in Five 1.3.3, revision 66191: http://svn.zope.org/Products.Five/branches/1.3/?rev=66191&view=rev The discussion on the list of the "fix" didn't take into account all the usage patterns. I would vote to delay a release until we find a way to restore the broken functionality. Could we perhaps provide an alternate implementation with the original lookup order, and make it pluggable? 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 iD8DBQFERpXA+gerLs4ltQ4RAle7AKCiSroAtAY3+0I12aqXXOPONZidaQCgzNL0 wdLRuXJ7SepHBTfFL7Pl5PQ= =G7f7 -----END PGP SIGNATURE-----
On 4/19/06, Tres Seaver <tseaver@palladion.com> wrote:
I would vote to delay a release until we find a way to restore the broken functionality. Could we perhaps provide an alternate implementation with the original lookup order, and make it pluggable?
Possibly. But more interestingly, can you provide the use case that fails? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
--On 19. April 2006 15:55:44 -0400 Tres Seaver <tseaver@palladion.com> wrote:
The discussion on the list of the "fix" didn't take into account all the usage patterns.
I would vote to delay a release until we find a way to restore the broken functionality. Could we perhaps provide an alternate implementation with the original lookup order, and make it pluggable?
I agree that we should have a clear solution for this. I think Philipp explained the reasons for the change when I had some trouble which the lookup order as well. Philipp? Andreas
Andreas Jung wrote:
The discussion on the list of the "fix" didn't take into account all the usage patterns.
I would vote to delay a release until we find a way to restore the broken functionality. Could we perhaps provide an alternate implementation with the original lookup order, and make it pluggable?
I agree that we should have a clear solution for this. I think Philipp explained the reasons for the change when I had some trouble which the lookup order as well.
The rationale for the fix and why I consider it a fix was explained in the original proposal (http://codespeak.net/pipermail/z3-five/2006q1/001186.html). A more detailed discussion regarding the CMF took place later (http://codespeak.net/pipermail/z3-five/2006q1/001201.html). This discussion never questioned the rationale of the fix, though. Instead, solutions for how to cope with the result of the fix in the CMF were discussed. I would guess that something like that would be best for Tres's customer application as well. Philipp
Tres Seaver wrote:
Andreas Jung wrote:
--On 19. April 2006 15:30:44 -0400 Tres Seaver <tseaver@palladion.com> wrote:
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
Do you say that we introduced an incompatibility in 2.9.2?
Yes. The change was introduced in Five 1.3.3, revision 66191:
http://svn.zope.org/Products.Five/branches/1.3/?rev=66191&view=rev
The discussion on the list of the "fix" didn't take into account all the usage patterns.
Some people with certain usage patterns participated in the discussion and adjusted their applications. The "fix" was under discussion for quite some time before it was put into a release.
I would vote to delay a release until we find a way to restore the broken functionality. Could we perhaps provide an alternate implementation with the original lookup order, and make it pluggable?
Yes, we could perhaps make it pluggable. Then again, the rationale behind the fix is that Zope 2 traversal (regarding views) should essentially be very much like Zope 3 traversal. The fix guarantees that. One could argue that an application relying on the opposite behaviour is relying on undocumented and essentially unexpected behaviour. Philipp
Tres Seaver wrote at 2006-4-19 15:30 -0400:
...
Is Alec's traversal patch or Dieter's alternative being considered?
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
I would like to stress that "my alternative" does not change traversal semantics but provides a way for "knowing" component's "__bobo_traverse__" to tell the enclosing framework that "__bobo_traverse__" wants to use the default (and not do anything special). Nothing is changed until a given component uses the feature. -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dieter Maurer wrote:
Tres Seaver wrote at 2006-4-19 15:30 -0400:
...
Is Alec's traversal patch or Dieter's alternative being considered?
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
I would like to stress that "my alternative" does not change traversal semantics but provides a way for "knowing" component's "__bobo_traverse__" to tell the enclosing framework that "__bobo_traverse__" wants to use the default (and not do anything special). Nothing is changed until a given component uses the feature.
I think the only impact on a site without software which used the feature would be a tiny performance ding (having to wrap the '__bobo_traverse__' call with a 'try:...except:' block). OTOH, since the contract for '__bobo_traverse__' is already insane (it *has* to behave differently for publishing traversal than for "normal" traversal), perhaps this change would reduce that insanity. We need to tweak OFS.Traversable as well, given that it calls '__bobo_traverse__' too. +1 for including the patch in the release tree. 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 iD8DBQFESD65+gerLs4ltQ4RAok2AJ46fLtHeKrVXhHLToawDHaPd3TpyACgkc36 ONg0Bshqri5i8EyQPbZXmbA= =PB1B -----END PGP SIGNATURE-----
On 4/20/06, Dieter Maurer <dieter@handshake.de> wrote:
Tres Seaver wrote at 2006-4-19 15:30 -0400:
...
Is Alec's traversal patch or Dieter's alternative being considered?
I'll note that I have a client who can't move forward from 2.9.1 to 2.9.3 because the changes to traversal semantics in that release break every view lookup in the application (which was originally built on 2.8.x, and works fine on 2.9.1.
I would like to stress that "my alternative" does not change traversal semantics but provides a way for "knowing" component's "__bobo_traverse__" to tell the enclosing framework that "__bobo_traverse__" wants to use the default (and not do anything special). Nothing is changed until a given component uses the feature.
And I'll stress that my change doesn't change traversal behavior either for any case that didn't emit and Unauthorized error previously. It is also completely compatible with Dieter's proposal, which is worthwhile because it could allow many existing __bobo_traverse__ methods to be greatly simplified. I've applied my patch to 2.8, 2.9, and trunk because a Zope release appears to be imminent, and there's no way we can release a new Plone until we have a Zope/Five which can handle acquisition properly (I'm pretty sure that this will bite other projects as well). Alec
participants (7)
-
Alec Mitchell -
Andreas Jung -
Dieter Maurer -
Lennart Regebro -
Philipp von Weitershausen -
Tres Seaver -
Wichert Akkerman