On May 17, 2006, at 9:27 PM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote:
From: Gary Poster [mailto:[EMAIL PROTECTED]
On Apr 22, 2006, at 11:31 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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.


Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to