[Zope3-dev] Access to widget errors

[Garrett Smith]

Marius Gedminas wrote:
> On Sat, Sep 11, 2004 at 10:09:31AM -0500, Garrett Smith wrote:
>> I would just update the proposal with the first part you mentioned.
>> <...> 
> 
> I updated http://dev.zope.org/Zope3/AccessToWidgetErrors
> 
> The only remaining fuzzy issue is the side effect of getInputError.
> Scenario:
> 
>   1.  view code calls getWidgetValues()
>   2. widget1.getInputError is called and sets widget1.error to None
>   3. view code does additional validation and sets widget1.error to
> err 
>   4. the page template is rendered and calls widget1()
>   5. widget1.__call__() calls _getFormValue which calls getInputValue
>      which resets widget1.error to None
>   6. the page template renders widget1/error, which is None
> 
> I see two solutions:
> 
>   - getInputValue should only set self.error if self.error is None;
>     otherwise it should not touch self.error.
> 
>   - BrowserWidget._getFormValue should save self.error and restore
>     it after calling getInputValue.
> 
> Thoughts?
> 
> Marius Gedminas

Both of these options would work, but I'm concerned that the widget
behavior is getting a bit too implicit (i.e. weird stuff/rules going on
in the background).

Let me throw out another option, which parallels the use of _data to
override form input:

1 - Leave everything as is -- i.e. error is a method that looks up a
view to _error.

2 - Add a new method 'overrideError' -- which sets attr
'_errorOverride':

  def overrideError(self, error):
    setattr(self, '_errorOverride', error)

3 - Modify error() to use _errorOverride, if it exists.

  def error(self):
    if hasattr(self, '_errorOverride')
      # lookup view on _errorOverride'
    else:
      # lookup view on _error

The new method is similar to setRenderedValue, but lets the view control
the error rather than the value.

I think treating error like label or hint is wrong because it's really
something managed internally by the widget.

 --Garrett