Le 05-08-12 à 13:40, Craig McClanahan a écrit :
On 8/12/05, Romero, Ron <[EMAIL PROTECTED]> wrote:
[snip]
This would also mean you don't need a new tag ... the existing Shale
tags for integrating validators would work.
Ah, but I want a new tag! :-) Seriously, a new tag would make it
easier to use --- it's simpler to code and to understand. True, it
would hide the flexibility and power of the commonsValidator tag, but
we don't need or want that additional flexibility, and we'd like to
hide it from everyone else.
And here's where the suggested approach isn't as appealing to me.
Once you open the floodgates of creating a new tag for *this* sort of
a validator, you likely end up where you need a tag for *every* sort
of validator. To the maximum degree possible, I'd prefer to stick
with just one tag <s:commonsValidator> that can call any of them. We
only need to ensure that there is a way to set all the needed
configurable properties such a validator would need.
At the same time, having predefined patterns with easy to use names is
exactly the sort of enhancement that *should* be made at the C-V
level, so that everyone can benefit from it, rather than hiding it
inside Shale :-).
Sorry I'm so late to the party. I've been out of town and I'm
catching up on email.
Anyway, I agree with Craig. I really like the simplicity of a single
tag and the
difference between this:
<s:commonsValidator arg="#{msg.firstName}"
server="true" client="true"
type="mask" mask="#{regex.firstName}" />
and this:
<s:regexValidator type="firstName" />
Is nowhere near compelling enough to introduce a new tag. And the
benefits
of introducing yet another XML configuration file that encapsulates the
validation specifics of individual fields is dubious at best.
Personally, I like
being able to see exactly what the validation entails without having
to go
pawing through a config file, but I know not everyone has that
preference.
david
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
