[Zope3-dev] Access to widget errors

[Marius Gedminas]

On Thu, Sep 09, 2004 at 11:28:17AM -0500, Garrett Smith wrote:
[snip example of rendering error messages as tooltips]
> > because widget/error returns HTML, and not just the error message.
> 
> Sigh...I knew we were going to run into this. This was the motivation
> for making label and hint non-UI specific, to let the PT/macro specify
> the HTML. But we didn't apply it to errors.
> 
> I think the proper solution is to make 'error' an attribute that
> provides IWidgetInputError and specify it in IInputWidget.
> I dont care for error_object -- I hope we can avoid it.
> We will have backward compatibility issues, but I'd prefer to make the
> proper change with deprecation warnings as needed.

That seems fine.

> >> As to goal 3, we will be implementing subscription based form
> >> validation (at some point...see Jim) as defined here:
> >> 
> >>   http://dev.zope.org/Zope3/NoMoreSchemaBinding
> > 
> > Consider the example from this wiki page:
> > 
> >   Suppose we have two fields, `max` and `min`. We want to assure that
> >   the `max` field value is not less than the `min` field value.
> > 
> > When a subscription based form validator finds out that `max` is less
> > than `min`, it should be able to cause the `max` widget to say so,
> > when the widget is rendered.
> 
> The validator/subscriber should really handle this by raising the
> appropriate field-specific error, which the widget displays like any
> other.

I misunderstood.  I initially thought that the subscriber would be used
to validate the whole form, and not each field.  Now I looked at the
example on that wiki page more closely:

  for validator in zapi.subscribers((field, context), IValidator):
      validator.validate(value)

What is 'context'?  In my application I build a "schema" (really, a dict
that contains fields) on the fly, and then I call getWidgetsData to get
a dict of values.  I perform cross-field validation on this dict, and if
everything's all right, I apply the values to several content objects.

In the subscriber example above, how would the subscriber know the
values of all other fields in the form?  I think this particular
proposal (NoMoreSchemaBinding) is solving the problem of
context-sensitive validation, but it still requires the fields to be
validatable in isolation.  I want to solve the problem of error
reporting in cross-field validation.

> This is a bit moot since we dont support this now.

> So, my suggestion would be to modify the proposal to redefine error as
> an attribute of IInputWidget and move the error rendering implementation
> to widget_macros.pt.
> 
> This will allow us to delete IWidgetInputErrorView and its only
> implementation (exception.WidgetInputErrorView). I think this is
> overkill and won't be used anyway. The only justification for such a
> facility is to handle yet-to-be-defined error types, which is probably
> YAGNI and is certainly WHUI.
> 
> I realize this is a bigger change than your initial proposal, but i
> think it's the right thing to do. I'd hate to see the widget API
> deteriorate before we even release.

Do you think I should split my proposal into two?  One would deal with
rendering widget errors without mandatory HTML -- we both agree on this
part.  The other proposal would deal with errors and cross-field
validation.  I'm still not sure if I've explained the second problem
well enough.

Marius Gedminas
-- 
F U cn rd dis U mst uz Unix.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20040910/fef3beb3/attachment.bin