:) that was more a joke...
I know your ide ... :)
On 9/27/06, Martin Marinschek <[EMAIL PROTECTED]> wrote:
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
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
