myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Winer" <awi...@gmail.com>
Subject Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)
Date Fri, 20 Jul 2007 18:02:47 GMT
On 7/20/07, Danny Robinson <dannyjrobinson@gmail.com> 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.
> >
>

Mime
View raw message