[Zope3-dev] Access to widget errors

[Garrett Smith]

Marius Gedminas wrote:
> On Thu, Sep 09, 2004 at 10:14:51AM -0500, Garrett Smith wrote:
>> Marius Gedminas wrote:
> More tweaking is necessary.  I want to do something like this:
> 
>   <span class="error" tal:condition="widget/error"
>         tal:attributes="title widget/error">!</span>
> 
> but I get
> 
>   <span class="error" title="&lt;span
> class=&quot;error&quot;&gt;Required input is
> missing.&lt;/span&gt;">!</span>  
> 
> 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.

> I can do instead
> 
>   <span class="error" tal:condition="widget/error"
>         tal:attributes="title widget/_error/doc">!</span>
> 
> but it is hackish.

Yes.
 
>> 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. 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.

 --Garrett