Ho-Ho - I never used the VI - I thought that was Adam's way of coding?
regards, Martin On 9/27/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
same here Gab's last sug. On 9/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > +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. when did you get rid of the vi ? :) > 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 > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
