[#WW-1112] XML Field Validation Required not working on Integer or Long values

WebWork

XML Field Validation Required not working on Integer or Long values

Created: 22/Jan/06 07:23 PM Updated: 14/Jan/07 11:42 AM

Component/s:

None

Affects Version/s:

2.2, 2.2.1

Fix Version/s:

2.2.1

File Attachments:

WW-1112-2.patch (5 kB)
2.

WW-1112.patch (4 kB)

Environment:

Any

Issue Links:

Duplicate

This issue is duplicated by:

~~XW-263~~ Float conversion should default to null instead of 0.0

Description

« Hide

Using the XML field validation put required on an Integer or Long field. Validation only reports an error when the value is a letter (EG: Submit with fields blank and it will fire the action instead of reporting a field error.)

Try the app at http://www.tuxbot.net/testCase2.zip and submit the form with no values, with only letters ("asdfsad") , with numbers and then letters "111asdf", adn just numbers "1111".

no values should report that the field is required.
"asdf" reports 'Invalid field value for field "personId".'
"111aaaa" reports no error and sets the value with the aaaa stripped
"111" works

I would think that the correct behavior would be...

no values reports a field error, field required
"111aasdf" reports a field error, field must be an integer

Of course I may be an idiot and doing something wrong.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

tm_jee added a comment - 24/Jan/06 03:20 AM

From what i know I think the required field validator is working.

* no values when entered (into the personId field) will generate a "personId must be an integer" error message.
* "111aaa" reported no error. I believe this is a bug on XWorkBasicConverter, which convertes "111aaa" into 111. Actually it is NumberFormat.parse("111aaa") returns 1111. We might need to take ParsePosition into account and see if all the source ( eg. "111aaa") is being used to do conversion. So if not all the ParsePosition is used, then there might be an error when converting... What do you think?
* "asdf" gives 'Invalid field Value for Field "persionId"' cause webwork failed to convert it to an Integer.

> no values reports a field error, field required
I think it is reporting an error "persionId must be an integer". Is this what you mean? or am i missing the point? Or do you mean why "invalid field value ...." message is not displayed? The "invalid field ..." message will be display only if there is a failure in the conversion.

I think you are right that there is a bug in the number conversion .... What do you think? ;-)

[ Permlink | « Hide ]

Eric Molitor added a comment - 24/Jan/06 10:18 AM

Just reran this and you are correct, the no values is working. Not sure what I had goofed up when I ran into that.

Yes, it appears to just be a number conversion error. When I submitted I didn't think to look for that so their might already be a jira. :)

[ Permlink | « Hide ]

Alexandru Popescu added a comment - 24/Jan/06 08:04 PM

I am on XWorkBasicConverter so I will take a look at this. Do we have a test case for it?

./alex
--
.w( the_mindstorm )p.

[ Permlink | « Hide ]

Eric Molitor added a comment - 25/Jan/06 01:02 AM

No, just the small app linked to in the description. I'm writing some unit tests for another issue tonight so I might get around to coding one for this.

[ Permlink | « Hide ]

Eric Molitor added a comment - 26/Jan/06 01:23 AM

This patch fixes the empty Number issues. If a value is an empty String do not attempt to use the DefaultConverter if other conversions have failed. (This was what was causing required validation not to work as OGNL was throwing an exception if the DefaultConverter was invoked with an empty string.)

[ Permlink | « Hide ]

Eric Molitor added a comment - 26/Jan/06 01:42 AM

Review the ParsePosition code carefully. That is what the code *Should* be doing to detect issues like "1111aaa" and "111.111" being submitted to Integers (and other numbers). However when the exception is thrown for some reason OGNL still attempts to invoke a method and throws an exception.

[ Permlink | « Hide ]

tm_jee added a comment - 26/Jan/06 02:15 AM

thanks for your time, effort and the patch. :-)

I think Alex will be working on this when he got time (soon).

[ Permlink | « Hide ]

Alexandru Popescu added a comment - 26/Jan/06 08:09 PM

Patches applied. Thanks.