An incoming request is initially accepted by the DispatcherServlet and then delegated to a handler (also known as "controller") that is able to deal with the request. A handler's responsibility is to translate the request into a model and to provide a ModelAndView instance. This instance is passed to the view dispatching (or rendering engine respectively) which renders the model into some external representation such as HTML

Figure 4.5. Processing chain of DispatcherServlet, handlers and view dispatcher

There are several ways for implementing a handler, for example by implementing the interface org.springframework.web.servlet.mvc.Controller or by annotating a bean's method with @RequestMapping. Although any of these mechanisms can be used within a CAE web application, CoreMedia suggests using the @RequestMapping way because currently this is the most sophisticated way of writing handlers without the need to write reoccurring boilerplate code.

A simple content based handler might look as follows:

package com.mycompany;

import com.coremedia.objectserver.web.HandlerHelper;
import com.coremedia.objectserver.beans.ContentBean;

@RequestMapping
public class MyHandler {

  @RequestMapping(value="/content/{id}")
  public ModelAndView handleContent(
                          @PathVariable("id") ContentBean bean) {

    if( bean == null ) {
      return HandlerHelper.notFound();
    }
    return HandlerHelper.createModel(bean);
  }
}

Such a handler can be registered by simply defining it as a bean:

<beans xmlns="http://www.springframework.org/schema/beans">
  <bean id="myHandler" class="com.mycompany.MyHandler"/>
</beans>

In this example, a request with an URI like /context/servlet/content/1234 would be handled by service "myHandler" because the @RequestMapping's URI pattern /content/{id} matches the full request URI's suffix /content/1234. The URI variable {id} is automatically bound to the method parameter contentBean so that the handler code can use it without parsing the request URI by itself and without converting the URI path segments into business objects manually. As a consequence, the remaining handler code is quite simple: It wraps the content bean into a ModelAndView and passes this to the rendering engine.

In order to get a numeric ID to be converted into a ContentBean automatically (and bound to the method parameter), it is necessary to register an adequate converter as follows:

<!-- required resources -->
<bean class="com.coremedia.objectserver.web.config.CaeHandlerServicesConfiguration"/>

<customize:append id="registerIdToContentBeanConverter" bean="bindingConverters">
  <description>
    Registers a converter for transforming a
    numeric id ("1234", for instance) to a ContentBean
  </description>
  <set>
    <bean class="com.coremedia.objectserver.web.binding.GenericIdToContentBeanConverter">
      <property name="contentBeanFactory" ref="contentBeanFactory"/>
      <property name="contentRepository" ref="contentRepository"/>
      <property name="dataViewFactory" ref="dataViewFactory"/>
    </bean>
  </set>
</customize:append>

Alternatively, the id could be passed to the handler method as an Integer object (for example PathVariable("id") Integer id) that is converted "manually" into a ContentBean, for example by using a ContentBeanFactory.

See Spring Framework documentation for a list of possible argument types and different options of implementing a handler method.