[Zope3-dev] Access to widget errors
Garrett Smith
garrett at mojave-corp.com
Mon Sep 13 11:19:12 EDT 2004
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
More information about the Zope3-dev
mailing list