Good catch. A variation of your patch is in trunk. On Sunday, 26 August 2012 18:54:23 UTC-5, Jim Karsten wrote: > > > > On Friday, August 24, 2012 4:16:30 PM UTC-4, Anthony wrote: >> >> For now, a workaround might be to subclass INPUT and replace the xml() >> method (http://code.google.com/p/web2py/source/browse/gluon/html.py#1692) >> so it doesn't check for hideerror and simply displays the widget without >> any error. >> >> Anthony >> >> On Friday, August 24, 2012 3:30:02 PM UTC-4, Jim Karsten wrote: >>> >>> I created a custom widget including an *INPUT* with a >>> *hideerror=True*parameter. It did not hide error messages. >>> >>> To simulate: >>> >>> in model: >>> class >>> SimpleWidget(FormWidget): >>> _class = >>> 'string' >>> >>> >>> >>> >>> @classmethod >>> def widget(cls, field, value, >>> **attributes): >>> default = >>> dict( >>> _type = >>> 'text', >>> value = (not value is None and str(value)) or >>> '', >>> >>> ) >>> attr = cls._attributes(field, default, >>> **attributes) >>> >>> >>> >>> return INPUT(hideerror=True, >>> **attr) >>> >>> >>> >>> db.define_table('atable', >>> >>> >>> Field('afield', >>> 'string', >>> >>> widget=SimpleWidget.widget, >>> >>> requires=IS_NOT_EMPTY(), >>> >>> ), >>> >>> migrate=True, >>> >>> ) >>> >>> >>> >>> In controller: >>> >>> def >>> test_hideerror(): >>> response.generic_patterns = >>> ['html'] >>> form = crud.update(db.atable, >>> request.args(0)) >>> return dict(form=form) >>> >>> Submit form with the 'afield' empty and it displays an error. >>> >>> This patch fixes it but it may change the logic in a way not originally >>> intended. In *gluon/html.py class DIV() def _traverse()*, >>> change: >>> >>> >>> >>> >>> c['hideerror']=hideerror >>> >>> >>> >>> to >>> >>> if 'hideerror' not in >>> c.attributes: >>> c['hideerror']=hideerror >>> >>> The patch only sets the hideerror attribute if it doesn't already exist. >>> With tet patch, if the widget has *hideerror=True*, if you use * >>> form.validate(hideerror=False)*, a field using the widget will still >>> hide the error. >>> >> > Do you consider it a bug or is that intended behaviour? >
--
