On 09/17/2009 01:48 PM, Martijn Faassen wrote:
> 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
> 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
> 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.
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
** No cross posts or HTML encoding! **
(Related lists -