In Zope 2.10 exception views were acquisition-wrapped in the publisher context. This appears to have changed in Zope 2.12: exception views are now wrapped in the exception. This is problematic since it means you can no longer use the context when rendering an error page, so things like ++resource++ or anything else which relies on a working acquisition context, which is pretty much everything, break. Is this an unexpected regression from the acquisition changes, or a deliberate change? Wichert.
On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
In Zope 2.10 exception views were acquisition-wrapped in the publisher context.
In Zope 2.10, exception views didn't exist in Zope2. They were only introduced in Zope 2.11.
This appears to have changed in Zope 2.12: exception views are now wrapped in the exception. This is problematic since it means you can no longer use the context when rendering an error page, so things like ++resource++ or anything else which relies on a working acquisition context, which is pretty much everything, break.
Is this an unexpected regression from the acquisition changes, or a deliberate change?
The exception view support in Zope3 and Zope2 has always been a view on the exception value and the request. There's no context involved. Not sure which backport or monkey patch you have been using in 2.10 here. Hanno
On 2/23/10 11:09 , Hanno Schlichting wrote:
On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkerman<wichert@wiggy.net> wrote:
In Zope 2.10 exception views were acquisition-wrapped in the publisher context.
In Zope 2.10, exception views didn't exist in Zope2. They were only introduced in Zope 2.11.
And yet they work beautifully in a Plone 3 site.
This appears to have changed in Zope 2.12: exception views are now wrapped in the exception. This is problematic since it means you can no longer use the context when rendering an error page, so things like ++resource++ or anything else which relies on a working acquisition context, which is pretty much everything, break.
Is this an unexpected regression from the acquisition changes, or a deliberate change?
The exception view support in Zope3 and Zope2 has always been a view on the exception value and the request. There's no context involved. Not sure which backport or monkey patch you have been using in 2.10 here.
perhaps plone.app.linkintegrity did something. At any rate without being able to access the context exception views are pretty much worthless, so we'll have to figure out some way of making it accesible. Wichert.
Wichert Akkerman wrote:
On 2/23/10 11:09 , Hanno Schlichting wrote:
On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkerman<wichert@wiggy.net> wrote:
In Zope 2.10 exception views were acquisition-wrapped in the publisher context. In Zope 2.10, exception views didn't exist in Zope2. They were only introduced in Zope 2.11.
And yet they work beautifully in a Plone 3 site.
This appears to have changed in Zope 2.12: exception views are now wrapped in the exception. This is problematic since it means you can no longer use the context when rendering an error page, so things like ++resource++ or anything else which relies on a working acquisition context, which is pretty much everything, break.
Is this an unexpected regression from the acquisition changes, or a deliberate change? The exception view support in Zope3 and Zope2 has always been a view on the exception value and the request. There's no context involved. Not sure which backport or monkey patch you have been using in 2.10 here.
perhaps plone.app.linkintegrity did something.
Yes, it adds a monkey patch to enable views-on-exceptions.
At any rate without being able to access the context exception views are pretty much worthless, so we'll have to figure out some way of making it accesible.
The view definitely needs access to the exception. And it's an adapter on (exception, request), which is definitely correct. We can't change that. Other than that, making it possible to access the real context sounds useful. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 2/23/10 12:33 , Martin Aspeli wrote:
Wichert Akkerman wrote:
On 2/23/10 11:09 , Hanno Schlichting wrote:
On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkerman<wichert@wiggy.net> wrote:
In Zope 2.10 exception views were acquisition-wrapped in the publisher context. In Zope 2.10, exception views didn't exist in Zope2. They were only introduced in Zope 2.11.
And yet they work beautifully in a Plone 3 site.
This appears to have changed in Zope 2.12: exception views are now wrapped in the exception. This is problematic since it means you can no longer use the context when rendering an error page, so things like ++resource++ or anything else which relies on a working acquisition context, which is pretty much everything, break.
Is this an unexpected regression from the acquisition changes, or a deliberate change? The exception view support in Zope3 and Zope2 has always been a view on the exception value and the request. There's no context involved. Not sure which backport or monkey patch you have been using in 2.10 here.
perhaps plone.app.linkintegrity did something.
Yes, it adds a monkey patch to enable views-on-exceptions.
At any rate without being able to access the context exception views are pretty much worthless, so we'll have to figure out some way of making it accesible.
The view definitely needs access to the exception. And it's an adapter on (exception, request), which is definitely correct. We can't change that.
Other than that, making it possible to access the real context sounds useful.
It is not useful, it is critical. Without the context you can not use any browser views for example. In a Plone context that means you can not render any Plone template. The trick plone.app.linkintegrity did was to wrap the exception view in the context, which both keeps the API the same and provides the context. Wichert.
Wichert Akkerman wrote:
It is not useful, it is critical. Without the context you can not use any browser views for example.
Well, the use cases that have been to date have done without it. :) I'm not disagreeing with you, I'm just saying we need to make sure we don't break existing use cases (plone.app.linkintegrity, plone.caching to name two that I know of).
In a Plone context that means you can not render any Plone template. The trick plone.app.linkintegrity did was to wrap the exception view in the context, which both keeps the API the same and provides the context.
Makes sense, although it means __parent__ is not self.context, which may be a bit unusual. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On 2/23/10 13:22 , Martin Aspeli wrote:
Wichert Akkerman wrote:
It is not useful, it is critical. Without the context you can not use any browser views for example.
Well, the use cases that have been to date have done without it. :) I'm not disagreeing with you, I'm just saying we need to make sure we don't break existing use cases (plone.app.linkintegrity, plone.caching to name two that I know of).
As I said plone.app.linkintegrity always used this trick in Zope 2.10, so it is not something I just came up with. It is known to work :)
In a Plone context that means you can not render any Plone template. The trick plone.app.linkintegrity did was to wrap the exception view in the context, which both keeps the API the same and provides the context.
Makes sense, although it means __parent__ is not self.context, which may be a bit unusual.
I am not aware of a requirement that they have to be the same. Wichert.
On 23.02.10 13:36, Wichert Akkerman wrote:
On 2/23/10 13:22 , Martin Aspeli wrote:
Wichert Akkerman wrote:
It is not useful, it is critical. Without the context you can not use any browser views for example.
Well, the use cases that have been to date have done without it. :) I'm not disagreeing with you, I'm just saying we need to make sure we don't break existing use cases (plone.app.linkintegrity, plone.caching to name two that I know of).
As I said plone.app.linkintegrity always used this trick in Zope 2.10, so it is not something I just came up with. It is known to work :)
wichert is right, the existing use cases — or say, at least p.a.linkintegrity — have _not_ done without it. in fact, the confirmation view (i.e. "you really wanna delete this?") relies on the (acquisition) context. otherwise it could never be rendered as something that looks like a "regular" page. however, the monkey patch used here is only partly applied for zope 2.12, and the bit where the view gets aq-wrapped is not[*]. since it remains to work, though, i suspect that wichert's problem could be something else... andi [*] see http://dev.plone.org/plone/browser/plone.app.linkintegrity/trunk/plone/app/l... -- zeidler it consulting - http://zitc.de/ - info@zitc.de friedelstraße 31 - 12047 berlin - telefon +49 30 25563779 pgp key at http://zitc.de/pgp - http://wwwkeys.de.pgp.net/ plone 4.0 alpha released! -- http://plone.org/products/plone/
participants (4)
-
Andreas Zeidler -
Hanno Schlichting -
Martin Aspeli -
Wichert Akkerman