Hi, I'd like to suggest a redesign of the IReRaiseException. I found this when reviewing revision 103682 and stumbled over the naming of the interfaces and that the interface only mentions a __call__ to retrieve a fact. IMHO this pattern smells like we should design an interface like this: class IPublisherExceptionInfo(Interface): reraise = Attribute('A boolean indicating whether ' 'this exceptionshould be reraised') Advantage: I find it much easier to read from a conceptual level. Disadvantage: Composition of policy by bundling *many* attributes in this way will be harder. Oppinions? Christian -- Christian Theune · ct@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
Hey, Christian Theune wrote:
I'd like to suggest a redesign of the IReRaiseException.
I found this when reviewing revision 103682 and stumbled over the naming of the interfaces and that the interface only mentions a __call__ to retrieve a fact.
IMHO this pattern smells like we should design an interface like this:
class IPublisherExceptionInfo(Interface):
reraise = Attribute('A boolean indicating whether ' 'this exceptionshould be reraised')
Advantage: I find it much easier to read from a conceptual level.
Disadvantage: Composition of policy by bundling *many* attributes in this way will be harder.
This would be an interface on exceptions, right? Would it try to adapt exceptions raised to IPublisherExceptionInfo and if successful look at this attribute? So an exception can either implement this interface directly, or you could register an adapter for exceptions? In general I'm fine with modifying this behavior on trunk. We also backported this behavior to the 3.4 line of zope.publisher so we can use it with Grok, which on zope.publisher 3.4.9. I suggest we maintain the current behavior in zope.publisher 3.4 but I'm fine with changing the behavior of the trunk. When we upgrade to that version we can make the necessary adjustments in Grok too. Regards, Martijn
On 09/17/2009 01:48 PM, Martijn Faassen wrote:
Hey,
Christian Theune wrote:
I'd like to suggest a redesign of the IReRaiseException.
I found this when reviewing revision 103682 and stumbled over the naming of the interfaces and that the interface only mentions a __call__ to retrieve a fact.
IMHO this pattern smells like we should design an interface like this:
class IPublisherExceptionInfo(Interface):
reraise = Attribute('A boolean indicating whether ' 'this exceptionshould be reraised')
Advantage: I find it much easier to read from a conceptual level.
Disadvantage: Composition of policy by bundling *many* attributes in this way will be harder.
Note to self: this disadvantage isn't really a disadvantage. The publisher states what information about an exception it can deal with and policies are free to split up that interface themselves if they need fine-grained control.
This would be an interface on exceptions, right? Would it try to adapt exceptions raised to IPublisherExceptionInfo and if successful look at this attribute? So an exception can either implement this interface directly, or you could register an adapter for exceptions?
Yes, I'd say it would perform an adaptation using `IPublishExceptionInfo(exc)` so it can either implement it directly or adapt.
In general I'm fine with modifying this behavior on trunk. We also backported this behavior to the 3.4 line of zope.publisher so we can use it with Grok, which on zope.publisher 3.4.9. I suggest we maintain the current behavior in zope.publisher 3.4 but I'm fine with changing the behavior of the trunk. When we upgrade to that version we can make the necessary adjustments in Grok too.
I agree. Christian -- Christian Theune · ct@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
Hey, Christian Theune wrote:
This would be an interface on exceptions, right? Would it try to adapt exceptions raised to IPublisherExceptionInfo and if successful look at this attribute? So an exception can either implement this interface directly, or you could register an adapter for exceptions?
Yes, I'd say it would perform an adaptation using `IPublishExceptionInfo(exc)` so it can either implement it directly or adapt.
And if the adapter is not available, it'll just do the default, correct?
In general I'm fine with modifying this behavior on trunk. We also backported this behavior to the 3.4 line of zope.publisher so we can use it with Grok, which on zope.publisher 3.4.9. I suggest we maintain the current behavior in zope.publisher 3.4 but I'm fine with changing the behavior of the trunk. When we upgrade to that version we can make the necessary adjustments in Grok too.
I agree.
+1 to going to this on the trunk. Regards, Martijn
On 09/17/2009 10:49 PM, Martijn Faassen wrote:
Hey,
Christian Theune wrote:
This would be an interface on exceptions, right? Would it try to adapt exceptions raised to IPublisherExceptionInfo and if successful look at this attribute? So an exception can either implement this interface directly, or you could register an adapter for exceptions?
Yes, I'd say it would perform an adaptation using `IPublishExceptionInfo(exc)` so it can either implement it directly or adapt.
And if the adapter is not available, it'll just do the default, correct?
Yes. Which would be whatever it has been doing for the last years ... -- Christian Theune · ct@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
participants (2)
-
Christian Theune -
Martijn Faassen