DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26151 Optionally specify patterns for byte, short, int, long, float, double validation [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From [EMAIL PROTECTED] 2004-01-16 15:05 ------- Following discussion and comments on the list, I'm dropping this enhacement request - it needs to be re-thought and I may re-submit something at a later date. A summary of the points raised were: 1) Specifying a RegExp mask validation can do a similar job (I accept this but also think DecimalFormat's style patterns are eaier and more intuitive). 2) Existing JavaScript validation would need to be changed to cater for patterns, otherwise it would reject valid input in the pattern format. 3) There are limitations with the DecimalFormat.parse() method. 3.1) It always accepts decimals whatever the pattern specified. This was "got round" in this enahacement by checking the returned value was not a Double type (for byte, short, integer & long) - but the javadoc for DecimalFormat says that this shouldn't be relied on for future versions. 3.2) Once it reaches non-numeric data after parsing a number, then DecimalFormat just stops so if someone enters "123x456" by mistake, it would be parsed as "123" and accepted as valid, rather than rejected as an error. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
