Dealing with Command objects that have java.lang.Integer as a property

The properties of a command object do not always have to be java.lang.String. For instance, when working with a number, a command object should use java.lang.Integer. Using a stronger type than a String makes the semantics stronger and validation more straight forward.

Unfortunately, it also makes binding (the act of taking the request parameters and setting them into the command object) more difficult. The Spring framework uses PropertyEditors to convert Strings to a different type. Spring provides many different property editors out of the box, but some aren't setup and ready to go.

Spring provides a CustomerNumberEditor for converting Strings to Numbers, such as java.lang.Integer. Note that CustomNumberEditor will convert to all subclasses of java.lang.Number. Spring does not wire this property editor automatically because it is meant to be configured with a Locale. Each web request may provide a different Locale (depending on the client), which forces the setup of CustomNumberEditor to be performed at request time.

You have control over how to format the numbers on display via the NumberFormat object. This comes in handy if you would like to remove commas (for instance, 2004 instead of 2,004) or other controls.

Luckily, Spring's BaseCommandController provides a nice hook to wire in CustomNumberEditor. Your controller class should override initBinder and bind a CustomerNumberEditor to the DataBinder.

An example:

protected void initBinder(HttpServletRequest request,
            ServletRequestDataBinder binder) throws Exception {
        super.initBinder(request, binder);
        NumberFormat nf = NumberFormat.getInstance(request.getLocale());
        binder.registerCustomEditor(java.lang.Integer.class,
                new CustomNumberEditor(java.lang.Integer.class, nf, true));
        
    }

This will create a NumberFormat with the request's Locale. Even though this is not automatically provided by Spring, this is actually A Good Thing.

Now, that is only half of the battle. Spring will generate an Error if CustomNumberEditor is not able to format its input (for instance, if "asdfdcc" is given as input). You are able to control the message that is generated for that error.

In your i18n translations file (usually a properties file), you can add:

typeMismatch.java.lang.Integer={0} must be a number.

Spring will put the fully qualified field name in for {0} and make it translatable. For instance, if your command object's name is 'commandObject' and field is 'firstName', then Spring will attempt to look for a message with the key 'commandObject.firstName' and place it in {0}.