On 7/20/07, Danny Robinson <[EMAIL PROTECTED]> wrote:
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).
* 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?
* 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. -- Adam
Thoughts? Danny -- Chordiant Software Inc. www.chordiant.com
