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