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?
No, just that I don't see our convenience as developers entering
into a decision - user convenience is the right way to decide.
>
> 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
This is definitely better, I agree.
-- Adam
> -- 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
>> > >>
>> > >>
>> >
>> >
>>
>
