+1 for Gabrielle's latest suggestion. Then the only thing I need to remember while writing the tag is that a messageDetail attribute starts with me...., rest will be done by code-complete.
regards, Martin On 9/27/06, Gabrielle Crawford <[EMAIL PROTECTED]> wrote:
Adam Winer 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. So does that mean you like the Trin way of multiple detail attr's because the user shouldn't see a message that's flat out wrong? > > 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. If we did keep it Trin's way it might be a good idea if the message attribute names were changed to have "messageDetail" first. That way they would be grouped together in the doc, and would have a similar name from one converter/validator to another, which would make them easier to find. For example here are a few attr's from various converter/validators: noMatchMessageDetail maximumMessageDetail minimumMessageDetail convertTimeMessageDetail would become messageDetailNoMatch messageDetailMaximum messageDetailMinimum messageDetailConvertTime Thanks, Gab > > -- 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 >> > >> >> > >> >> > >> > >> >
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
