As mentioned above, it's a handler's responsibility to provide a ModelAndView instance. A typical ModelAndView holds one or more named model beans. It also contains a view name (such as "rss") or, alternatively, a view implementation (of type org.springframework.web.servlet.View).

While building the model to be rendered by the CAE view dispatcher (see below) it is necessary to consider the following: At least a model bean with the name "self" needs to be added to the ModelAndView. This bean represents the "main" or "root" object of the model and will be the used for looking up an adequate view. In addition, no View instance must be added to the ModelAndView because such an instance will be resolved automatically by the view resolving mechanism based on the type of the "self" bean in conjunction with the view name.

CoreMedia provides some convenience functions in com.coremedia.objectserver.web.HandlerHelper for building an adequate ModelAndView.

There are situations where a request must not result in a rendered page but should be answered with a special HTTP response code. E.g. a "bad request" (Status: 400) response should be returned in case that the request is malformed or a "not found" in case that the requested resource does not exist. Instead of sending such responses directly by using HttpServletResponse, it is also possible to return a ModelAndView containing a com.coremedia.objectserver.web.HttpError bean. The advantage of this approach is to let the view rendering decide how to handle a response like this. One way would be to use the programmed view (see below) com.coremedia.objectserver.view.HttpErrorView for writing the HTTP error to the response. Another approach is to render a comprehensive error page instead by using a template com.coremedia.objectserver.view/HttpError.ftl. The HandlerHelper utility provides helper methods for dealing with such situations:

Finally, a handler might decide not to render a bean directly but send a "temporarily moved" response (Status: 302) instead. This is a typical use case when dealing with POST requests: After updating the application state, the user's web browser is redirected to a result page. This case is also supported by the HandlerHelper: