-------------- Original message --------------
> Le 05-08-12 à 13:40, Craig McClanahan a écrit :
>
> > On 8/12/05, Romero, Ron 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 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:
>
> > server="true" client="true"
> type="mask" mask="#{regex.firstName}" />
>
> and this:
>
>
>
> 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.
Well, that's cause we already got one ( Clay :-).
> 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.
>
Clay would work very well to spice up the client view. As for the XML
configuration:
<component jsfid="commonsValidator"
componentType="org.apache.shale.ValidatorScript"/>
<component jsfid="firstNameRegExp" extends="commonsValidator" >
<attributes>
<set name="arg" value="#{msg.firstName}"/>
<set name="server" value="true">
<set name="client" value="true">
<set name="type" value="mask">
<set name="mask" value="#{regex.firstName}">
</attributes>
</component>
And, the JSP:
<clay:clay id="regexValidator" jsfid="firstNameRegExp"/>
Gary
>
> 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]
>
