Thanks Vil, we might have to go for something like this too, but I think the current default behaviour is not very user friendly and should be changed generally.
Question to Reinhard: we are using a fd:range validation based on the integer datatype, I have not come across an example how I can combine this with a fd:regexp validation as this is based on a string datatype. How do you do this? Thanks all and best regards Cassie --- Vilya Harvey <[EMAIL PROTECTED]> wrote: > Reinhard Poetz wrote: > > > Murray Cassie wrote: > > > >> Problem: when we enter something like "3abc" this > is > >> treated like a correct entry. All characters > after the > >> first that is no number are cut off and only the > first > >> numbers are evaluated. > >> > >> This might be wanted behaviour, but not according > to > >> our spec. > >> > >> Any suggestions how we can change this??? > > > > > > As a workaround, add a regexp validation that > makes sure that only > > [0-9] is allowed. But the behaviour is strange > because the datatype > > "integer" should make sure that only an integer is > valid. > > I've just had to deal with exactly the same issue on > my project at work. > The problem is actually the NumberFormat class which > does the parsing. > The JavaDocs don't make it very clear, but what it > does is parse only > the leading digits in the string rather than the > whole string. The same > problem applies with decimal, float and double > datatypes as well. > > I worked around the problem by implementing my own > converter classes and > changing the cocoon.xconf file to use those by > default instead. Each of > the new converters uses the NumberFormat.parse() > method which takes a > ParsePosition as well as a String; after parsing, > they simply check that > the ParsePosition is at the end of the input string. > > The only problem I encountered with doing this is > that the NumberFormat > used by the existing converter infrastructure is a > wrapper around the > JDK one and doesn't expose the parse(String, > ParsePosition) method. The > two options are: switch to using only the JDK > NumberFormat class, or add > the method to the interface. I went for the former, > as it meant the > smallest impact on the Cocoon code. > > Hope that helps, > > Vil. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
