Mailing List Archive: Zope: Dev

Redesign suggestion for IReRaiseException

Index | Next | Previous | View Threaded

ct at gocept

Sep 17, 2009, 4:00 AM

Post #1 of 5 (322 views)
Permalink

Redesign suggestion for IReRaiseException

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[at]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[at]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 )

faassen at startifact

Sep 17, 2009, 4:48 AM

Post #2 of 5 (291 views)
Permalink

Re: Redesign suggestion for IReRaiseException [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

ct at gocept

Sep 17, 2009, 12:11 PM

Post #3 of 5 (296 views)
Permalink

Re: Redesign suggestion for IReRaiseException [In reply to]

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[at]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[at]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 )

faassen at startifact

Sep 17, 2009, 1:49 PM

Post #4 of 5 (287 views)
Permalink

Re: Redesign suggestion for IReRaiseException [In reply to]

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

_______________________________________________
Zope-Dev maillist - Zope-Dev[at]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 )

ct at gocept

Sep 17, 2009, 10:41 PM

Post #5 of 5 (286 views)
Permalink

Re: Redesign suggestion for IReRaiseException [In reply to]

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[at]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[at]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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com