We are preparing to move this Jira installation to codehaus. Please wait and don't use this version for some days.

The AndroMDA project

Long validation is ignored

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: Bpm4Struts Cartridge
  • Labels:
    None

Description

The validator "long" doesn't seem to work correctly. Indeed when a field of type Long is filled with a string, no error occurs and the field of the form is null in the controller. (cf. http://galaxy.andromda.org/forum/viewtopic.php?t=435&highlight=validation)

Issue Links

Activity

Hide
stephane le peutrec added a comment - 15/Jul/05 11:18 AM
The field of the first view of this small project is a Long. The second view displays the value written in the first view. When the value written is a string, no error occurs and the value is null in the second view.
Show
stephane le peutrec added a comment - 15/Jul/05 11:18 AM The field of the first view of this small project is a Long. The second view displays the value written in the first view. When the value written is a string, no error occurs and the value is null in the second view.
Hide
Wouter Zoons added a comment - 17/Jul/05 8:42 AM
I noticed primitive long behaves differently (the form field is pre-populated with a zero), and when you enter non-parseable data it will assume zero .. pretty bad implementation if you ask me
Show
Wouter Zoons added a comment - 17/Jul/05 8:42 AM I noticed primitive long behaves differently (the form field is pre-populated with a zero), and when you enter non-parseable data it will assume zero .. pretty bad implementation if you ask me
Hide
Walter Itamar Mourão added a comment - 18/Jul/05 1:40 PM
The "Long" behaves differently because the "default" server behavior of struts when parsing Strings to non primitive class numbers is creating the number class instance (Long in this case) with the value 0 (new Long(0)) when occurs a parsing error. To change this behavior you must use the "org.apache.commons.beanutils.converters" package and set the desired defaults instead using the Struts one.
My solution: I created a set of validators checking against a specific class instance to see if the Long instance created by the converter is valid or a is "flag", so the validator can throw the correct exception.
Show
Walter Itamar Mourão added a comment - 18/Jul/05 1:40 PM The "Long" behaves differently because the "default" server behavior of struts when parsing Strings to non primitive class numbers is creating the number class instance (Long in this case) with the value 0 (new Long(0)) when occurs a parsing error. To change this behavior you must use the "org.apache.commons.beanutils.converters" package and set the desired defaults instead using the Struts one. My solution: I created a set of validators checking against a specific class instance to see if the Long instance created by the converter is valid or a is "flag", so the validator can throw the correct exception.
Hide
Wouter Zoons added a comment - 16/Aug/05 10:20 AM
indeed, it seems Struts is designed to only validate primitive numeric types

if someone uploades a patch I'm willing to integrate it into the bpm4struts cartridge
Show
Wouter Zoons added a comment - 16/Aug/05 10:20 AM indeed, it seems Struts is designed to only validate primitive numeric types if someone uploades a patch I'm willing to integrate it into the bpm4struts cartridge
Hide
Walter Itamar Mourão added a comment - 17/Aug/05 1:58 PM
>> indeed, it seems Struts is designed to only validate primitive
>> numeric types

Not really. In fact Struts uses the org.apache.commons.beanutil.converters package to convert from one Class to another, String (from the http request) to Long (form attribute) in this case. The default behavior of the converters' classes is setting the value to null if the String cannot be converted. I changed this behavior creating converters classes with configurable error values and validators which check if the conversion error happened.
It is important to set the new conversion behavior after the default Struts configuration. To do that I extended the org.apache.struts.config.ControllerConfig class and setted the struts-config (<controller className="app.Config" />) to load the new class.
I use this approach a lot, since I don't use primitives in forms.
I will attach some files to show the idea.
Show
Walter Itamar Mourão added a comment - 17/Aug/05 1:58 PM >> indeed, it seems Struts is designed to only validate primitive >> numeric types Not really. In fact Struts uses the org.apache.commons.beanutil.converters package to convert from one Class to another, String (from the http request) to Long (form attribute) in this case. The default behavior of the converters' classes is setting the value to null if the String cannot be converted. I changed this behavior creating converters classes with configurable error values and validators which check if the conversion error happened. It is important to set the new conversion behavior after the default Struts configuration. To do that I extended the org.apache.struts.config.ControllerConfig class and setted the struts-config (<controller className="app.Config" />) to load the new class. I use this approach a lot, since I don't use primitives in forms. I will attach some files to show the idea.
Hide
Walter Itamar Mourão added a comment - 17/Aug/05 2:04 PM
Samples of converters and validators handling non primitive types.
Show
Walter Itamar Mourão added a comment - 17/Aug/05 2:04 PM Samples of converters and validators handling non primitive types.

People

Vote (1)
Watch (1)

Dates

  • Created:
    15/Jul/05 11:07 AM
    Updated:
    13/Aug/11 11:58 AM