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 Validators
and use custom editors (in the form of
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
'firstName' exists, the framework will attempt to call
setFirstName([value]) passing the value of the parameter. Nested properties
are of course supported. For instance a parameter named 'address.city'
will result in a getAddress().setCity([value]) call on the
command 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 setLocale(Locale loc) is
perfectly possible for a request parameter named locale having
a value of en, as long as you register the appropriate
PropertyEditor in the Controller (see 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
Errors object which can be
used in a View to render any input problems.
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.
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 Validators and use custom editors (in the form of 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
'firstName'exists, the framework will attempt to callsetFirstName([value])passing the value of the parameter. Nested properties are of course supported. For instance a parameter named'address.city'will result in agetAddress().setCity([value])call on the command 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
setLocale(Locale loc)is perfectly possible for a request parameter namedlocalehaving a value ofen, as long as you register the appropriate PropertyEditor in the Controller (see 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 Errors object which can be used 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 , AbstractcommandController , SimpleFormController and 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):