The parser for the validators: string is not very powerful. You are better off using a <bean> to define the validator. It can handle more awkward syntax and you can use OGNL inside a <set> element.
You can then reference the bean, by name, using a '$', i.e. <bean name="pattern" ... validators:required,minLength=10,$pattern On 11/1/05, Eric Williams <[EMAIL PROTECTED]> wrote: > I just tested this with beta 12 -- same behavior. > > -----Original Message----- > From: Eric Williams [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 01, 2005 10:50 AM > To: Tapestry users > Subject: Problems with pattern and numeric translation/validation in > T4-beta-11 > > I'm running into some trouble with the validation system in 4.0-beta-11. > > The first is with regex pattern validation. If I want to enforce a > pattern of at least 3 but no more than 5 digits, I'd use a regex like > the following: > > <binding name="validators" value="validators:pattern=\d{3,5}"/> > > This returns the error "No validator named '5' has been defined." How > can I tell Tapestry that I'm not trying to define another validator with > this comma? > > The second problem is with server-side validation/translation of > numerical input. I have the following in a .page file: > > <binding name="translator" value="translator:number"/> > > If I provide input like "1asdf" I see two different behaviors: With > client-side validation on, I get the error "[field name] must be a > numeric value". This is the correct behavior. But with client-side > validation off, it just hacks the non-numeric characters off the end of > the string. "1asdf" would return 1 without complaint. > > I found the following thread in the list archive: > > Kent Tong <kent <at> cpttm.org.mo> writes: > > > >Shing Hing Man <matmsh <at> yahoo.com> writes: > > > > > On a form, when I input "123.fff" in numberTF and then > > > submit the form, I get numberTF=123.0 in my form > > > listerner method and no validation error. I was > > > expecting a validation error. Should 123.fff fail the > > > validation ? > > > > This is the behavior of the Format class hierarchy in Java. > > They don't necessarily use all the available characters in > > the string. To solve this problem, I'd suggest that you > > add a feature request to enhance the FormatTranslator class > > to support a "strict" option. When it's on, it should check > > if the entire string has really been used (probably skipping > > white spaces at the end). > > Is any such feature planned? I personally see this behavior as a bug in > Tapestry. > > Any help with these issues would be greatly appreciated. > > Thanks, > Eric > > > --------------------------------------------------------------------- > 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] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
