[Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Danny Robinson <da...@gmail.com>]

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

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

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

Thoughts?

Danny

-- 
Chordiant Software Inc.
www.chordiant.com

Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Adam Winer <aw...@gmail.com>]

It's Javascript.  So it's an array.

-- Adam


On 7/20/07, Blake Sullivan <bl...@oracle.com> wrote:
> Adam Winer wrote:
> > On 7/20/07, Danny Robinson <da...@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.
> 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.
> >> >
> >>
>
>

Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Blake Sullivan <bl...@oracle.com>]

Adam Winer wrote:
> On 7/20/07, Danny Robinson <da...@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.
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.
>> >
>>

Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Adam Winer <aw...@gmail.com>]

On 7/20/07, Danny Robinson <da...@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.
> >
>

Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Danny Robinson <da...@gmail.com>]

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

Re: [Trinidad] Client-Side Validators/Convertors should throw TrLabeledFacesMessage (extends TrFacesMessage)

[Adam Winer <aw...@gmail.com>]

On 7/20/07, Danny Robinson <da...@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).

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