Using a handler mapping you can map incoming portlet requests to appropriatehandlers. There are some handler mappings you can use out of the box, for example, the Portlet Mode Handler Mapping, but let's first examine the general concept of a Handler Mapping.
Note: We are intentionally using the term “Handler” here instead of “Controller”.DispatcherPortlet is designed to be used with other ways to process requests than just Spring Portlet MVC’s own Controllers. A Handler is any Object that can handle portlet requests. Controllers are an example of Handlers, and they are of course the default. To use some other framework with Dispatcher Portlet, a corresponding implementation of HandlerAdapter is all that is needed.
The functionality a basic Handler Mapping provides is the delivering of a Handler ExecutionChain, which must contain the handler that matches the incoming request, and may also contain a list of handler interceptors that are applied to the request. When a request comes in, the Dispatcher Portlet will hand it over to the handler mapping to let it inspect the request and come up with an appropriate Handler Execution Chain. Then the Dispatcher Portlet will execute the handler and interceptors in the chain (if any).These concepts are all exactly the same as in Spring Web MVC.
The concept of configurable handler mappings that can optionally contain interceptors (executed before or after the actual handler was executed, or both) is extremely powerful.A lot of supporting functionality can be built into a custom Handler Mapping. Think of a custom handler mapping that chooses a handler not only based on the portlet mode of the request coming in, but also on a specific state of the session associated with the request.
In Spring Web MVC, handler mappings are commonly based on URLs. Since there is really no such thing as a URL within a Portlet, we must use other mechanisms to control mappings. The two most common are the portlet mode and a request parameter, but anything available to the portlet request can be used in a custom handler mapping.
The rest of this describes three of Spring Portlet MVC's most commonly used handler mappings. They all extend Abstract Handler Mapping and share the following properties:
This is a simple handler mapping that maps incoming requests based on the current mode of the portlet (e.g. ‘view’, ‘edit’, ‘help’). An example:<bean class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
If we need to navigate around to multiple controllers without changing portlet mode, the simplest way to do this is with a request parameter that is used as the key to control the mapping.Parameter Handler Mapping uses the value of a specific request parameter to control the mapping.The default name of the parameter is 'action', but can be changed using the 'parameterName' property.
The bean configuration for this mapping will look something like this:<bean class="org.springframework.web.portlet.handler.ParameterHandlerMapping”>
The most powerful built-in handler mapping, Portlet Mode Parameter Handler Mapping combines the capabilities of the two previous ones to allow different navigation within each portlet mode. Again the default name of the parameter is "action", but can be changed using the parameterName property.
By default, the same parameter value may not be used in two different portlet modes. This is so that if the portal itself changes the portlet mode, the request will no longer be valid in the mapping. This behavior can be changed by setting the allow Dup Parameters property to true.However, this is not recommended.
The bean configuration for this mapping will look something like this:<bean class="org.springframework.web.portlet.handler.PortletModeParameterHandlerMapping">
This mapping can be chained ahead of a PortletModeHandlerMapping, which can then provide defaults for each mode and an overall default as well.
Spring's handler mapping mechanism has a notion of handler interceptors, which can be extremely useful when you want to apply specific functionality to certain requests, for example, checking for a principal.
Again Spring Portlet MVC implements these concepts in the same way as Web MVC.Interceptors located in the handler mapping must implement Handler Interceptor from the org. spring frame work. web. portlet package. Just like the servlet version, this interface defines three methods: one that will be called before the actual handler will be executed (preHandle), one that will be called after the handler is executed (post Handle), and one that is called after the complete request has finished (after Completion). These three methods should provide enough flexibility to do all kinds of pre- and post- processing.
The pre Handle method returns a boolean value. You can use this method to break or continue the processing of the execution chain. When this method returns true, the handler execution chain will continue. When it returns false, the Dispatcher Portlet assumes the interceptor itself has taken care of requests (and, for example, rendered an appropriate view) and does not continue executing the other interceptors and the actual handler in the execution chain.
The post Handle method is only called on a Render Request. The preHandle and after Completion methods are called on both an Action Request and a RenderRequest. If you need to execute logic in these methods for just one type of request, be sure to check what kind of request it is before processing it.
As with the servlet package, the portlet package has a concrete implementation of Handler Interceptor called Handler Interceptor Adapter.This class has empty versions of all the methods so that you can inherit from this class and implement just one or two methods when that is all you need.
The portlet package also has a concrete interceptor named Parameter Mapping Interceptor that is meant to be used directly with Parameter Handler Mapping and Portlet Mode Parameter Handler Mapping. This interceptor will cause the parameter that is being used to control the mapping to be forwarded from an ActionRequest to the sub sequent Render Request. This will help ensure that the RenderRequest is mapped to the same Handler as the Action Request. This is done in the preHandle method of the interceptor, so you can still modify the parameter value in your handler to change where the Render Request will be mapped.
Be aware that this interceptor is calling set Render Parameter on the ActionResponse, which means that you cannot call send Redirect in your handler when using this interceptor. If you need to do external redirects then you will either need to forward the mapping parameter manually or write a different interceptor to handle this for you.
Java-Springs Related Interview Questions
|Adv Java Interview Questions||J2EE Interview Questions|
|Core Java Interview Questions||JSP Interview Questions|
|Java-Springs Interview Questions||Java Servlets Interview Questions|
|JMS(Java Message Service) Interview Questions||Hibernate Interview Questions|
|Java applet Interview Questions||Java Interview Questions|
|Framework7 Interview Questions||Java collections framework Interview Questions|
|Java 8 Interview Questions||Java Programmer Interview Questions|
Introduction To Spring Framework
New Features And Enhancements In Spring 3.0
The Ioc Container
Validation, Data Binding, And Type Conversion
Spring Expression Language (spel)
Aspect Oriented Programming With Spring
Spring Aop Apis
Data Access With Jdbc
Object Relational Mapping (orm) Data Access
Marshalling Xml Using O/x Mappers
Web Mvc Framework
Integrating With Other Web Frameworks
Portlet Mvc Framework
Remoting And Web Services Using Spring
Enterprise Javabeans (ejb) Integration
Jms (java Message Service)
Task Execution And Scheduling
Dynamic Language Support
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.