Request Handling by Spring
The client requests for a resource in the Web application. As seen in earlier section, the web container directs all MVC request to the Spring DispatcherServlet. The Spring Front controller will intercept the request and will find the appropriate handler based on the handler mapping (configured in Spring configuration files). In other words the handler mapping is used to map a request from the client to the handler. With the help of Handler Adapter, the Spring Front controller will dispatch the request to the handler.
In Windchill we use two handler mappings
• DefaultAnnotationHandlerMapping, which maps handlers based on HTTP paths expressed through the RequestMapping annotation at the type or method level.
• SimpleUrlHandlerMapping which maps from the URLs to request handler beans. Mappings are specified in the properties files at <Windchill>\codebase\config\mvc\
e.g /servlet/WizardServlet* = wizardController
Once the handler is found, it will find the suitable handler adapter from the configured adapters. In Windchill we use three types of handler adapters
• SimpleControllerHandlerAdapter, an adapter to use the plain Controller
• AnnotationMethodHandlerAdapter which maps handler methods based on HTTP paths, HTTP methods and request parameters expressed through the RequestMapping annotation.
• GwtHandlerAdapter, an adapter to handle GWT client requests (handler is RemoteServiceServlet)
Handlers
They are beans that can handle a request. An OOTB handler has been provided to handle requests to build components - com.ptc.mvc.components.ComponentController. It prepares a ModelAndView (org.springframework.web.servlet.ModelAndView) which can be handled by the DispatcherServlet
To build a component, we need its description and the data to be presented. We have introduced the concept of builders, which will provide these artifacts. Component description will be represented via ComponentConfig and a ComponentConfigBuilder provides them. Component data will be represented via ComponentData and a ComponentDataBuilder provide them.
ComponentConfig and ComponentData together define the component information to be shown in the UI and will be represented by ComponentDefintion. It is the Model in MVC paradigm, where as the ComponentController is the Controller.
How find a builder?
A typical MVC resource to build a component will be ptc1/<handler_key>/<componentId> where
• handler_key is used to map the request to a handler.
• componentId represent the component to be build.
ComponentController is injected with a ComponentBuilderResolver, which will find the respective builders for the given componentId.
Internal artifacts of ComponentController
Few notable internals of a ComponentController
• ComponentBuilderResolver, finds the ComponentConfigBuilder and ComponentDataBuilder for the componentId specified in the resource
• defaultMappings defines the default views for different ComponentConfig.
• ComponentParamsFactory create ComponentParams from request and response that will be made available in the builders.
The builders provide ComponentConfig and ComponentData, from which the Model, ComponentDefinition is made. ModelAndView is populated with ComponentDefinition and the view information comes either from the ComponentConfig or from the defaultMapping provided.
The artifacts that are in green are Windchill Client Architecture (e.g JCA) specific ones. The black ones are the ones provided by the component owners.
