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).


OK, no problem.  It just kept my TrMessageBox class cleaner as it didn't
require calls back into Core global JS API's.

Maybe we could add a TrPage.prototype.getLabel() API, so that
we hide the calls to Core inside TrPage (and, slowly, get rid of
Core altogether).

> > * 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.

D'oh!  Of course. :)

Although map of id -> FacesMessage[] could be cleaner.

Yeah, that'd be ideal.

-- Adam


> > * 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.
>

Reply via email to