Controller implementation which creates an object (the command object) on receipt of a request and attempts to populate this object with request parameters.
This controller is the base for all controllers wishing to populate JavaBeans based on request parameters, validate the content of such JavaBeans using {@link org.springframework.validation.Validator Validators}and use custom editors (in the form of {@link java.beans.PropertyEditor PropertyEditors}) to transform objects into strings and vice versa, for example. Three notions are mentioned here:
Command class:
An instance of the command class will be created for each request and populated with request parameters. A command class can basically be any Java class; the only requirement is a no-arg constructor. The command class should preferably be a JavaBean in order to be able to populate bean properties with request parameters.
Populating using request parameters and PropertyEditors:
Upon receiving a request, any BaseCommandController will attempt to fill the command object using the request parameters. This is done using the typical and well-known JavaBeans property notation. When a request parameter named {@code 'firstName'} exists, the framework will attempt to call{@code setFirstName([value])} passing the value of the parameter. Nested propertiesare of course supported. For instance a parameter named {@code 'address.city'}will result in a {@code getAddress().setCity([value])} call on thecommand class.
It's important to realise that you are not limited to String arguments in your JavaBeans. Using the PropertyEditor-notion as supplied by the java.beans package, you will be able to transform Strings to Objects and the other way around. For instance {@code setLocale(Locale loc)} isperfectly possible for a request parameter named {@code locale} havinga value of {@code en}, as long as you register the appropriate PropertyEditor in the Controller (see {@link #initBinder initBinder()}for more information on that matter.
Validators: After the controller has successfully populated the command object with parameters from the request, it will use any configured validators to validate the object. Validation results will be put in a {@link org.springframework.validation.Errors Errors} object which can beused in a View to render any input problems.
Workflow (and that defined by superclass):
Since this class is an abstract base class for more specific implementation, it does not override the handleRequestInternal() method and also has no actual workflow. Implementing classes like AbstractFormController, {@link AbstractCommandController AbstractcommandController}, SimpleFormController and {@link AbstractWizardFormController AbstractWizardFormController}provide actual functionality and workflow. More information on workflow performed by superclasses can be found here.
Exposed configuration properties (and those defined by superclass):
| name | default | description |
| commandName | command | the name to use when binding the instantiated command class to the request |
| commandClass | null | the class to use upon receiving a request and which to fill using the request parameters. What object is used and whether or not it should be created is defined by extending classes and their configuration properties and methods. |
| validators | null | Array of Validator beans. The validator will be called at appropriate places in the workflow of subclasses (have a look at those for more info) to validate the command object. |
| validator | null | Short-form property for setting only one Validator bean (usually passed in using a <ref bean="beanId"/> property. |
| validateOnBinding | true | Indicates whether or not to validate the command object after the object has been populated with request parameters. |
Note: From Spring 3.2.3, was removed in Spring 4.0.
@author Rod Johnson @author Juergen Hoeller @deprecated as of Spring 3.0, in favor of annotated controllers | |
| |