[Zope3-dev] best way to deal with dependency errors

[Jim Fulton]

Casey Duncan wrote:
> On Tue, 10 Feb 2004 04:38:26 -0500
> Jim Fulton <jim at zope.com> wrote:
> 
> [..]
> 
>>The ConfirmationRequired exception has a view that:
>>
>>   - Displays the issues and a confirmation button
>>
>>   - Includes hidden fields that identify the issue.
>>     This is needed to make sure that we have confirmed all
>>     of the same issues when the application is reexecuted.
> 
> 
> This is an interesting pattern.

I think so too. In general, I thjink that the new-in-Zope-3
pattern of using views on exceptions to handle errors provides
lots of interesting opportunities.

 > Interactive exception views. Actually I
> think that in a well-mannered application, most exceptions should be
> interactive in some way.
> 
> In general application exception views are a way for the app to express
> an "Oh crap, I'm too stupid to figure this out for myself, what should I
> do now?".
> 
> A simple example would be a transitory error, like lets say a conflict
> that recurs after 3 retrys. It could perhaps have a "Try Again" button
> that lets the user replay the request.
> 
> Or let's say a user tried to delete a locked item. If the user can
> unlock the object then the exception view could have a "Delete Anyway"
> button that unlocks the object and retrys the delete.
 >
> Or let's say you are adding a new item to a folder and you choose a name
> that already exists. The exception view could provide a form where the
> user can choose a different name.

Yup

> All of these assume some way to store enough info about the previous
> request to replay it (sometimes with modifications). There are of course
> many ways to do this, but it would be nice to have this automated by the
> framework in some way since it is a common operation.

<shrug>

> We may want to think about not limiting this sort of functionality to
> events. Otherwise I see myself using events just to get this nice
> "resolve issues" functionality even if I wouldn't otherwise use them.
> OTOH, maybe that should be a reason to use events.

You can do this sort of thing without events. Events simply provide
a way to decouple things, so, for example, the application that deletes
things doesn't need to know about locks or dependencies.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org