[Zope3-dev] Access to widget errors

[Garrett Smith]

Marius Gedminas wrote:
> On Mon, Sep 13, 2004 at 10:19:12AM -0500, Garrett Smith wrote:
>> 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.
> 
> Good, I like this -- except for the view lookup part.  Use case #1 in
> my proposal: I do not want error in HTML, I want an error message in
> a tooltip. 

You're right...good thing you're paying attention :-)

> How about we make error a read-only property that returns the error
> object and do the HTML rendering in widget_macros.pt?

I considered having the widget lookup the eroor view for both the error
and the page view -- this would let you register an error view that's
specific for the page type. This flailing underscores (I think) the need
to expose the error itself and let the PT handle its rendering.

So, for the proposal, this brings back into play the need to delete the
error view facility and move the HTML into form_macros.py.

My only question is how Pythonic it is to have a read-only attr like
that, vs an accessor method like 'getError'. Whatever we do, we should
have the blessings of the Python aesthetes (Jim? Steve? Fred? anyone?
:-)

 --Garrett