类 MultiActionController

  • 所有已实现的接口:
    Aware, ApplicationContextAware, ServletContextAware, Controller, LastModified

    @Deprecated
    public class MultiActionController
    extends AbstractController
    implements LastModified
    已过时。
    as of 4.3, in favor of annotation-driven handler methods
    Controller implementation that allows multiple request types to be handled by the same class. Subclasses of this class can handle several different types of request with methods of the form
    public (ModelAndView | Map | String | void) actionName(HttpServletRequest request, HttpServletResponse response, [,HttpSession] [,AnyObject]);
    A Map return value indicates a model that is supposed to be passed to a default view (determined through a RequestToViewNameTranslator). A String return value indicates the name of a view to be rendered without a specific model.

    May take a third parameter (of type HttpSession) in which an existing session will be required, or a third parameter of an arbitrary class that gets treated as the command (that is, an instance of the class gets created, and request parameters get bound to it)

    These methods can throw any kind of exception, but should only let propagate those that they consider fatal, or which their class or superclass is prepared to catch by implementing an exception handler.

    When returning just a Map instance view name translation will be used to generate the view name. The configured RequestToViewNameTranslator will be used to determine the view name.

    When returning void a return value of null is assumed meaning that the handler method is responsible for writing the response directly to the supplied HttpServletResponse.

    This model allows for rapid coding, but loses the advantage of compile-time checking. It is similar to a Struts DispatchAction, but more sophisticated. Also supports delegation to another object.

    An implementation of the MethodNameResolver interface defined in this package should return a method name for a given request, based on any aspect of the request, such as its URL or an "action" parameter. The actual strategy can be configured via the "methodNameResolver" bean property, for each MultiActionController.

    The default MethodNameResolver is InternalPathMethodNameResolver; further included strategies are PropertiesMethodNameResolver and ParameterMethodNameResolver.

    Subclasses can implement custom exception handler methods with names such as:

    public ModelAndView anyMeaningfulName(HttpServletRequest request, HttpServletResponse response, ExceptionClass exception);
    The third parameter can be any subclass or Exception or RuntimeException.

    There can also be an optional xxxLastModified method for handlers, of signature:

    public long anyMeaningfulNameLastModified(HttpServletRequest request)
    If such a method is present, it will be invoked. Default return from getLastModified is -1, meaning that the content must always be regenerated.

    Note that all handler methods need to be public and that method overloading is not allowed.

    See also the description of the workflow performed by the superclass (in that section of the class level Javadoc entitled 'workflow').

    Note: For maximum data binding flexibility, consider direct usage of a ServletRequestDataBinder in your controller method, instead of relying on a declared command argument. This allows for full control over the entire binder setup and usage, including the invocation of Validators and the subsequent evaluation of binding/validation errors.

    作者:
    Rod Johnson, Juergen Hoeller, Colin Sampaleanu, Rob Harrop, Sam Brannen
    另请参阅:
    MethodNameResolver, InternalPathMethodNameResolver, PropertiesMethodNameResolver, ParameterMethodNameResolver, LastModified.getLastModified(javax.servlet.http.HttpServletRequest), ServletRequestDataBinder