It's Javascript. So it's an array. -- Adam
On 7/20/07, Blake Sullivan <[EMAIL PROTECTED]> wrote:
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. >> > >>
