Adam Winer wrote:
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.
Is this map of id->FacesMessage[] or id ->List<FacesMessage>?
-- Blake Sullivan
-- 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.
>
