On 9/27/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
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"/>
Well, it could, but the question is why you're designing it this way? A more natural design for the user is to put this on one validator.
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.
For convertNumber and convertDateTime, where the message is only covariant with the "type" attribute on the tag itself, I agree, there's little-to-no user benefit, and a distinct user cost. My opinion is just that this should be decided tag-by-tag, not globally. If it makes sense for a tag to have only one message, do that. If it makes sense to have two, do that. Class inheritance should not be used as the reason for doing this. (Especially so for the validatiors and converters in Trinidad that already extend from JSF spec validators and converters, where the base class is out of our hands.) -- Adam
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 > > > >> > > > >> > > > > > > > > > >
