> ...(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.id isn'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] > >
