Subclasses should set the following properties, either in the constructor or via a BeanFactory: commandName, commandClass, sessionForm, formView, successView. Note that commandClass doesn't need to be set when overriding formBackingObject, as this determines the class anyway.

This is the preferred submit callback to implement if you want to perform an action (like storing changes to the database) and then render the success view with the command and Errors instance as model. You don't need to care about the success ModelAndView here.

Gets called by suppressValidation and processFormSubmission. Consequently, this single method determines to suppress validation and to show the form view in any case.

Default implementation delegates to onFormChange(request, response, command).

Default implementation is empty.

Default implementation delegates to onSubmit(Object, BindException). For simply performing a submit action and rendering the specified success view, consider implementing doSubmitAction rather than an onSubmit version.

Subclasses can override this to provide custom submission handling like storing the object to the database. Implementations can also perform custom validation and call showForm to return to the form. Do not implement multiple onSubmit methods: In that case, just this method will be called by the controller.

Call errors.getModel() to populate the ModelAndView model with the command and the Errors instance, under the specified command name, as expected by the "spring:bind" tag.

Default implementation calls onSubmit(command), using the returned ModelAndView if actually implemented in a subclass. Else, the default behavior will apply: rendering the success view with the command and Errors instance as model.

Subclasses can override this to provide custom submission handling that does not need request and response.

Call errors.getModel() to populate the ModelAndView model with the command and the Errors instance, under the specified command name, as expected by the "spring:bind" tag.

This implementation calls doSubmitAction and returns null as ModelAndView, making the calling onSubmit method perform its default rendering of the success view.

Subclasses can override this to provide custom submission handling that just depends on the command object. It's preferable to use either onSubmit(command, errors) or doSubmitAction(command), though: Use the former when you want to build your own ModelAndView; use the latter when you want to perform an action and forward to the successView.

This can only be overridden to check for an action that should be executed without respect to binding errors, like a cancel action. To just handle successful submissions without binding errors, override one of the onSubmit methods or doSubmitAction.

Default implementation delegates to referenceData(request). Subclasses can override this to set reference data used in the view.

Default implementation returns null. Subclasses can override this to set reference data used in the view.

Can be called within onSubmit implementations, to redirect back to the form in case of custom validation errors (i.e. not determined by the validator).

Can be overridden in subclasses to show a custom view, writing directly to the response or preparing the response before rendering a view.

If calling showForm with a custom control model in subclasses, it's preferable to override the analogous showForm version with a controlModel argument (which will handle both standard form showing and custom form showing then).

Can be called within onSubmit implementations, to redirect back to the form in case of custom validation errors (i.e. not determined by the validator).

Can be overridden in subclasses to show a custom view, writing directly to the response or preparing the response before rendering a view.