> I'm doing some clean-up of the client-side validation routines (e.g.
> _multiValidate, _validateAlert, _validateInline, etc.) in preparation
for
> integrating tr:messages into the inline validation. Previously,
> _multiValidate called the validators and convertors and grabbed the
detail
> string from the thrown TrFacesMessage's, therefore there wasn't access
to
> the full TrFacesMessage object ext from _validateAlert or
_validateInline.
> Now with a client-side tr:messages component, I need access to the
summary
> text. Therefore I'd like to propose a few tweaks to our client-side
> validation code:
>
> * Introduce a public js class TrLabeledFacesMessage (mirrorring the
> server-side LabeledFacesMessage class) which adds a label attribute to
the
> parent class of TrFacesMessage. This would reduce repeated calls to
> _getLabel().
Hrm, -1, I think: _getLabel() isn't that expensive, and I'd rather avoid
the bonus API. The server-side class is kind of a hack, but there's
no other way (on the server).
OK, no problem. It just kept my TrMessageBox class cleaner as it didn't
require calls back into Core global JS API's.
* Have _multiValidate return an array of id & FacesMessage entries, and
> allow _validateInline and _validateAlert to decide what information they
for
> their particular method of display.
Instead of an array, how about a map. id -> FacesMessage?
Couldn't there potentially be multiple FacesMessage objects per id.
Although map of id -> FacesMessage[] could be cleaner.
* Fix the order of output messages. Currently messages output by the
above
> methods appear in the order of required errors, convertor errors,
validator
> errors. Rather than the order in which the fields are displayed
on-screen.
That'd be an excellent improvement.
