[Zope3-dev] Formlib error handling

Gary Poster gary at zope.com
Thu May 18 10:12:32 EDT 2006


On May 17, 2006, at 9:27 PM, <dev at projekt01.ch> <dev at projekt01.ch>  
wrote:
>> From: Gary Poster [mailto:gary at zope.com]
>> On Apr 22, 2006, at 11:31 AM, <dev at projekt01.ch> <dev at projekt01.ch>
>> wrote:
>>> The formlib.EditForm dosen't catch all errors form widgets.
>> ...
> I solve the problem and added some bugfix, see the different
> commit messages below.

Awesome.  Some comments below.

...
> Log message for revision 68157:
>   - Improve error handling in formlib:
>     Fix invariant error handling in formlib. The exception Invalid  
> raised
>     in interface invariants where end in a component lookup error  
> because
>     this exception didn't get converted to a usefull error message.
>     Now the error_views method in formlib can handle strings and i18n
>     Message based Invalid exceptions.

With your change, if the error is (or extends!) Invalid, it is  
hardcoded to assume the first argument is a string, message, or  
something with a reasonably __str__, translate if it is a message,  
and wrap the result with a <span>.  I'd much prefer it if that code  
were ripped out of error_views and made, simply, into a view for  
(Invalid, IBrowserRequest), perhaps even registered by the formlib  
zcml.  Do you see any issue with that?

Also, I don't love the 'widget_title' stuff in error_views: that  
seems to me to be the responsibility of the error view.    Is that  
new?  What's the rationale?

> Log message for revision 67278:
>   Fix error handling, please double check this!
>
>   The formlib.form.EditForm doesn't handle ValidationError in the
>   method error_views.
>   I converted ValidationError to WidgetInputError in the method
>   getWidgetsData which is responsible to catch errors raised by
>   the widget getInputValue method.

This is the place in the code that knows the widget name and label,  
so it's not unreasonable.

Thanks

Gary


More information about the Zope3-dev mailing list