Thanks Martin for responding. But I am afraid we probably are talking of two different things. Unless I am missing some point somewhere. I am referring to regular expressions in the context of validator framework. (entries in validation.xml).
The tags that you provided a reference to, are useful in the JSPs to do comparisions. I am not too sure if I can use these tags in the validation.xml. Thanks & Best Regards, Raghu On 11/27/05, Martin Gainty <[EMAIL PROTECTED]> wrote: > > Raghu- > Have you looked at implementing with conditional struts-logic lessEqual > Taglib? > > http://struts.apache.org/struts-doc-1.2.7/userGuide/struts-logic.html#lessEqual > HTH, > M- > ----- Original Message ----- > From: "Raghu Kanchustambham" <[EMAIL PROTECTED]> > To: "Struts Users Mailing List" <user@struts.apache.org> > Sent: Sunday, November 27, 2005 3:43 AM > Subject: Re: conditional validation > > > > ...(educationDetails[0].marks le 100)... > > Doesnt work... le/ge/gt/lt is not recognized. > > I worked around the problem by enforcing through floatRange to be between > 35 > and 100. Note that floatRange validations work perfectly fine. I wanted to > allow either a "0" (to stand for a 'dont care') and a range between 35 and > 100. This condition necessarily meant I had to write regular expressions > ... > that way I thought I could avoid the need for "String" counterparts of > these > parameters for validation to work on them. (Strings get converted to a 0 > even before the validator acts on them). > > Now I allow a blank for dont care and the number (if entered) has to be > between 35 and 100. I can now use the floatRange for this but as a > side-effect I had to introduce the "String" counterpart on which > floatRange would work and also would let you have a blank input (which now > doesnt get converted to a 0). But the benefit of this is that you dont > "loose" the "wrong input" that user entered (as Laurie suggested in the > previous post). > > I was wondering if it is possible to use validwhen in conjunction with > another validation. I should be able to say "validwhen" through some > expression followed by "floatRange" validation etc... currently I am > using regular expressions to mimic the floatRange when used on a > conditional > basis. If it doesnt exist already, is it very difficult to build it? > > Thanks. > Regards, > Raghu > > > > > > > > > On 11/26/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > > Raghu Kanchustambham wrote: > > >> Second, shouldn't you allow an empty value for marks if degree.idisn't > > > set, > > >> rather than forcing the user to enter numeric data that's going to be > > >> ignored? > > > > > > I really dont care about what the user enters for marks if he chooses > > "none" > > > for the degree. I dont care even if he enters a alpha-numeric .. > because > > > that would get converted to a zero before the validator acts on it. > > > > That is true assuming your form property is of type float, not String. > > The disadvantage of doing that is that if the user enters non-numerical > > data you can't redisplay it after failing validation. If you don't care > > about being able to redisplay invalid data for the user to correct, you > > can get away with using a float-typed property and not worry about this. > > > > >> What makes you think the validator is doing a string rather than > > numeric > > > comparison? > > > > > > Lets do a small change to illustrate that it is indeed doing a string > > > comparision....(may be its doing something else but not numeric > > comparision! > > > ) > > > > > > Reconsider the following (with changed values just to illustrate the > > point): > > > > > > I changed the max value to 500 from 100 and I have removed the > redundant > > > "100>=" check as you pointed out. When I choose the degree and enter > 36 > > for > > > marks.. there is no validation error (which is expected). However, > when > > I > > > enter 123, which is numerically greater than 35 but "stringically" > > lesser > > > than 35, then it throws up a validation error. Similarly 349 fails > the > > > validation but 351 passes it! Similarly 7 passes the validation test > > inspite > > > of it being less than 35 numerically ! > > > > > > What I see is that when I enter 65 which is "stringically" greater > than > > 500 > > > ... it passes the validation as if to suggest it is a numerical > > comparision > > > indeed! But note that this check is being performed by the floatRange > > > validation and not the validwhen rule. So I guess floatRange and > > intRange > > > work as expected but validwhen does a string comparision. In theory > (at > > > least) I dont see any reason why validwhen cant do a more semantically > > > correct comparision. > > > > OK, so it does look like you're getting a string comparison. Was my > > assumption right above that your form property's type is float? I would > > think this was a bug (I would expect a comparison between an unquoted > > number and a property of numeric type to work as you're expecting). > > > > Try this as an alternative (untested): > > > > ...(educationDetails[0].marks le 100)... > > > > > And on a side note.. cant I specify a "lesser than" operation in my > > checks > > > ... should i always have to work around by swapping the numbers and > > convert > > > the expression to "greater than" ... bcoz my IDE seems to be > complaining > > abt > > > the DTD mismatch when I try the "lesser than" operation. I hope I am > > using > > > the right DTD: > > > > > > <!DOCTYPE form-validation PUBLIC > > > "-//Apache Software Foundation//DTD Commons Validator Rules > > > Configuration 1.1.3//EN" > > > "http://jakarta.apache.org/commons/dtds/validator_1_1_3.dtd > "> > > > > This isn't a DTD issue, it's an XML syntax issue. Remember that '<' is a > > special character in XML. The write the litteral character '<' you have > > to use an entity escape (usually '<'). As an alternative, validator > > also recognizes the textual operators ('lt', 'gt', etc.) which may be > > easier to read/write. > > > > L. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
