[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