I filed issues to create the tags. If anyone wants to vote on the single
vs multiple detail attribute issue please do. It should be consistent
for the tags, so I will follow the current Trin conventions for the new
tags unless there are votes to use a singe detailMessage attribute on
all converters/validators.
Thanks,
Gab
Mike Kienenberger 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
>>
>>
