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
