[#XRP-121] Need more validation possibilities (was: There isn't an error when entering dates in number fields in parameters) - Cocoondev.org Issue Tracker

Issue Details [XML]

Key:	XRP-121
Type:	Feature Wish
Status:	Resolved
Resolution:	Fixed
Priority:	Minor
Reporter:	Kristof Van Cleemput
Votes:	0
Watchers:	1

Operations

If you were logged in you would be able to see more operations.

xReporter

Need more validation possibilities (was: There isn't an error when entering dates in number fields in parameters)

Created: 09/Feb/07 04:12 AM Updated: 13/Sep/07 09:30 AM

Component/s:

xReporter

Affects Version/s:

1.2.1, 1.2

Fix Version/s:

1.3

Description

Any report with a parameter that is a long or bigdecimal won't return an error when entering a data (fi 01/02/2006).
Instead the report will use the first number (fi 1) and will show you the result without giving the error that 01/02/2006 is not a number or something like that.

Problem comes from using java.text.* or com.ibm.icu.text.* for parsing for patterns and locale.
Seems to me that there is need to also have a new BigDecimal, new Long or something like that as an extra check

This piece of code show a detail of the error
> > final String s = "81/39/2006";
> >
> > //jdk
> > DecimalFormat dfj = (java.text.DecimalFormat)java.text.NumberFormat.getNumberInstance();
> > System.out.print("jdk parse of " + s + " => ");
> > try
> > {
> > System.out.println(dfj.parse(s));
> > }
> > catch (ParseException e)
> > {
> > System.out.println("parse-exception!");
> > e.printStackTrace();
> > }
> >
> > //icu4j
> > com.ibm.icu.text.DecimalFormat dfi = (com.ibm.icu.text.DecimalFormat)com.ibm.icu.text.NumberFormat.getNumberInstance();
> > System.out.print("icu parse of " + s + " => ");
> > try
> > {
> > System.out.println(dfi.parse(s));
> > }
> > catch (ParseException e)
> > {
> > System.out.println("parse-exception!");
> > e.printStackTrace();
> > }

output has no exceptions just:
> > jdk parse of 81/39/2006 => 81
> > icu parse of 81/39/2006 => 81

in icu4j version 3.6 there's a setParseStrict(boolean) maybe that can help

But in jdk 1.5 there's only DateFormat setLenient(boolean)).

Thanks to mpo for finding all this.
I hope this one goes into the next release ;-)

All

Comments

Change History

Sort Order:

Comment by Marc Portier [12/Feb/07 02:33 AM]

[ Permlink ]

Kristof,

I really can't agree with the fact that this is critical:
* this does not prevent xreporter from running correctly
* there is clear feedback to the user on the resulting pages of how values were interpreted: he should read and react!
* this leniency 'feature' has been in xreporter since 1.0, knowing its extensive use at your premises over the last x years I'ld say the fact that this got unnoticed for so long is an indication of how un-critical this is?

Nevertheless, there could be a valuable new feature in this of course.

Finally: I have to state that the suggested solution for using setLenient or setParseStrict is not the best way of solving IMHO.

1. the jdk setLenient is only on available on dateparsing (and your problem here is about numberparsing)
2. it's not verified what the icu4j implementation actually does
3. since xreporter uses a fallback strategy to choose between icu4j and jdk parsing we can only rely on the least common denominator

a better approach IMHO would be to extend the set of available validation elements in the report-definition-xml. (e.g. something to match a regex expression)

(hence the renaming of the 'issue')

Comment by Bruno Dumon [13/Sep/07 09:30 AM]

[ Permlink ]

Fixed in SVN rev 718.

If there is non-parsed input after the parsed number, validation will fail.