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