We're just talking about the case where a user specifies an override
message for a specific validator, yes? The standard validator
messages would be used in all other cases.
<inputComponent>
<validator message="Zip code!">
</inputComponent>
I'm sure we can come up with a case where a validator throws different
messages, but in the case above (longRangeValidator), this could be
handled by two validators (checkLowValidator, checkHighValidator) or a
setting on the validator
<longRangeValidator type="high" message="too high"/>
<longRangeValidator type="low" message="too low"/>
I'd suggest that messageDetail override any other settings, but not
necessarily be the only message-setting attribute on a validator,
unless it's a validator with only one message generated. For
longRangeValidator, provide all three: messageDetail, probably
inherited from a base clase, highMessageDetail, lowMessageDetail, with
messageDetail taking precedence over highMessageDetail which take
precedence over the message properties setting. For numberConverter,
I think you're better off with a single message attribute.
n 9/27/06, Adam Winer <[EMAIL PROTECTED]> wrote:
Well, as far as picking an API, I think the user is 99% important, the
developer 1%. It's not that hard as a devloper to support multiple
messages.
I agree that with something like convertNumber, there's
not that much utility to having different properties for each,
since it'd be incredibly rare for a user to set more than
one on any one tag - you'll never have one convertNumber
that is both a currency converter, and a percentage
converter, etc.
What I worry about a bit more
is *forcing* that onto a base implementation, because
you might have something like a validator that reports
different messages depending on the error. Like
a longRangeValidator that gave you "too high",
"too low", etc. messages, depending on the value you
enter. That would need multiple detail messages,
potentially per validator.
-- Adam
On 9/25/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
>
> I think you summed up both perfectly. That's also how I see it.
>
> As a JSF user, I'd prefer the tomahawk way -- only one attribute name
> to remember for every validator. The use case of having a customized
> per-input validator message is almost always going to encompass
> exactly one message string rather than the four possible for
> numberConverter. I don't see myself ever needing to make type
> variable. And as I said before, if I did that, it wouldn't take much
> to also make the message variable.
>
> As a JSF developer (MyFaces), it's far easier to maintain one
> ValidatorBase class that provides support for a single message
> attribute and have all validators inherit from it, rather than
> maintaining separate attributes for each individual validator. You
> can take a look at the current Tomahawk ValidatorBase class to see a
> good implementation of this (just committed last week, improving on
> the original design) that hides almost all of the message attribute
> handling code from the validator subclasses.
>
> On 9/22/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote:
> > Thanks Mike. Here's some of the pros and cons of each, if you don't mind
> > let's stick to the detail string for now.
> >
> > 1] current Trinidad way: have specific attributes for each detail
> > PROS: usual case is that user binds each detail attr to a specific
> > bundle key, the message won't be out of synch with the implementation no
> > matter how other attr's are set.
> > CONS: lots of attr's, inconsistent api
> >
> > 2] current Tomahawk way: support only detailMessage
> > PROS: one attr, consistent api, and in most cases user will just bind to
> > a specific bundle key
> > CONS: it's error prone when you need to keep multiple attributes in
> > synch to ensure proper behavior, and the value returned by the
> > detailMessage needs to be in synch with other settings
> >
> > Do you agree with these?
> >
> > Anyone have any prefs?
> >
> > Thanks,
> >
> > Gabrielle
> >
> >
> >
> > Mike Kienenberger wrote:
> >
> > > For Tomahawk, we've been supporting this as a "message" attribute for
> > > a few months.
> > > Earlier today, we changed it to "detailMessage" and "summaryMessage"
> > > attributes, with detailMessage replacing message.
> > >
> > > What about the option of using the same names between Tomahawk and
> > > Trinidad?
> > > I notice that numberConverter has 4 separate attributes even though
> > > only one of them would be used at a time. Is that really necessary?
> > > If you're going to make the type a value binding, you could make the
> > > message a value binding too. The other ones I glanced at only have
> > > one message attribute, even though the name varies from component to
> > > component.
> > >
> > > On 9/21/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote:
> > >
> > >> Hi,
> > >>
> > >> If you look at the bottom of this page, you'll see Trin supports its
> own
> > >> version of the RI converters, but not the RI validators:
> > >> http://incubator.apache.org/adffaces/trinidad-api/tagdoc.html
> > >>
> http://java.sun.com/javaee/javaserverfaces/1.1/docs/tlddocs/index.html
> > >>
> > >> Trin supports customizing the detail portion of a message on it's
> tags.
> > >> See the doc here for the RI vs Trin convertNumber tag:
> > >>
> > >>
>
http://java.sun.com/javaee/javaserverfaces/1.1/docs/tlddocs/f/convertNumber.html
> > >>
> > >>
> http://incubator.apache.org/adffaces/trinidad-api/tagdoc/tr_convertNumber.html
> > >>
> > >>
> > >> I would like to open issues to add tags for validateLength,
> > >> validateLongRange, validateDoubleRange. Agree, disagree?
> > >>
> > >> Thanks,
> > >>
> > >> Gab
> > >>
> > >>
> >
> >
>
