We need to understand
the main difference between portlet workflow and servlet workflow.
The main difference between portlet workflow and servlet workflow is that,
the request to
the portlet can have two distinct phases: 1) Action phase 2) Render phase.
The Action phase is executed only once and is where any 'backend' changes or actions occur, such as making changes in a database.
The Render phase then produces what is displayed to
the user each time
the display is refreshed.
The critical point here is that for a single overall request,
the action phase is executed only once, but
the render phase may be executed multiple times. This provides a clean separation between
the activities that modify
the persistent state
of your system and
the activities that generate what is displayed to
the user.
The dual phases
of portlet requests are one
of the real strengths
of the JSR-168 specification. For example, dynamic search results can be updated routinely on
the display without
the user explicitly re-running
the search. Most other portlet MVC frameworks attempt to completely hide
the two phases from
the developer and make it look as much like traditional servlet development as possible - we think this approach removes one
of the main benefits
of using portlets. So,
the separation
of the two phases is preserved throughout
the Spring Portlet MVC framework.
The primary manifestation
of this approach is that where
the servlet version
of the MVC classes will have one method that deals with
the request,
the portlet version
of the MVC classes will have two methods that deal with
the request: one for
the action phase and one for
the render phase. For example, where
the servlet version
of AbstractController has
the handleRequestInternal(..) method,
the portlet version
of AbstractController has handleActionRequestInternal(..) and handleRenderRequestInternal(..) methods.
The Spring Portlet Framework is designed around a DispatcherPortlet that dispatches requests to handlers, with configurable handler mappings and view resolution, just as
the DispatcherServlet in
the Spring
Web Framework does.
Developing portlet.xml
Let's start
the sample development by creating
the portlet.xml file in
the /WebContent/WEB-INF/ folder as shown below:
<?xml version="1.0" encoding="UTF-8"?>
<portlet-app version="2.0"
xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<portlet>
<portlet-name>SpringPortletName</portlet-name>
<portlet-class>org.springframework.
web.portlet.DispatcherPortlet</portlet-class>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info>
<title>SpringPortlet</title>
</portlet-info>
</portlet>
</portlet-app>
DispatcherPortlet is responsible for handling every client request.
When it receives a request, it finds out which Controller class should
be used for handling this request, and then it calls its
handleActionRequest() or handleRenderRequest() method based on
the
request processing phase.
The Controller class executes business logic
and returns a View name that should be used for rendering markup to
the
user.
The DispatcherPortlet then forwards control to that View for
actual markup generation.
As you can see, DispatcherPortlet is
the central
dispatcher for use within Spring Portlet MVC Framework. Note that your
portlet application can define more than one DispatcherPortlet. If it
does so, then each
of these portlets operates its own namespace, loading
its application context and handler mapping.
The DispatcherPortlet is also responsible for loading
application context (Spring configuration file) for this portlet. First,
it tries to check
the value
of the configLocation portlet
initialization parameter. If that parameter is not specified, it takes
the portlet name (that is,
the value
of the <portlet-name>
element), appends "-portlet.xml" to it, and tries to load that file from
the /WEB-INF folder. In
the portlet.xml file, we did not specify
the
configLocation initialization parameter, so let's create SpringPortletName-portlet.xml file in
the next section.
Developing SpringPortletName-portlet.xml
Create
the SpringPortletName-portlet.xml file in
the /WebContent/WEB-INF folder
of your application as shown below:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<bean id="viewResolver" class="org.springframework.
web.servlet.view.InternalResourceViewResolver">
<property name="viewClass" value="org.springframework.
web.servlet.view.JstlView"/>
<property name="prefix" value="/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>
<bean id="pointManager" class="com.wlp.spring.bo.internal.PointManagerImpl">
<property name="users">
<list>
<ref bean="point1"/>
<ref bean="point2"/>
<ref bean="point3"/>
<ref bean="point4"/>
</list>
</property>
</bean>
<bean id="point1" class="com.wlp.spring.bean.User">
<property name="name" value="Murali"/>
<property name="points" value="6"/>
</bean>
<bean id="point2" class="com.wlp.spring.bean.User">
<property name="name" value="Sai"/>
<property name="points" value="13"/>
</bean>
<bean id="point3" class="com.wlp.spring.bean.User">
<property name="name" value="Rama"/>
<property name="points" value="43"/>
</bean>
<bean id="point4" class="com.wlp.spring.bean.User">
<property name="name" value="Krishna"/>
<property name="points" value="23"/>
</bean>
<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basename" value="messages"/>
</bean>
<bean name="/users.htm" id="userController" class="com.wlp.spring.controller.UserController">
<property name="pointManager" ref="pointManager"/>
</bean>
<bean name="/pointincrease.htm" id="pointIncreaseController" class="com.wlp.spring.controller.IncreasePointsFormController">
<property name="sessionForm" value="true"/>
<property name="pointManager" ref="pointManager"/>
<property name="commandName" value="pointIncrease"/>
<property name="commandClass" value="com.wlp.spring.bean.PointIncrease"/>
<property name="formView" value="pointincrease"/>
<property name="successView" value="users"/>
</bean>
<bean id="parameterMappingInterceptor"
class="org.springframework.
web.portlet.handler.ParameterMappingInterceptor" />
<bean id="portletModeParameterHandlerMapping"
class="org.springframework.
web.portlet.handler.PortletModeParameterHandlerMapping">
<property name="order" value="1" />
<property name="interceptors">
<list>
<ref bean="parameterMappingInterceptor" />
</list>
</property>
<property name="portletModeParameterMap">
<map>
<entry key="view">
<map>
<entry key="pointincrease">
<ref bean="pointIncreaseController" />
</entry>
<entry key="users">
<ref bean="userController" />
</entry>
</map>
</entry>
</map>
</property>
</bean>
<bean id="portletModeHandlerMapping"
class="org.springframework.
web.portlet.handler.PortletModeHandlerMapping">
<property name="order" value="2" />
<property name="portletModeMap">
<map>
<entry key="view">
<ref bean="userController" />
</entry>
</map>
</property>
</bean>
</beans>
The SpringPortletName-portlet.xml file is an application context
file for your MVC portlet. It has a couple
of bean
definitions:
viewController. At this point, remember that
the viewController bean definition points to
the
com.ibm.developerworks.springmvc.ViewController.java class.
portletModeHandlerMapping. As we discussed in
the last section, whenever DispatcherPortlet gets a client request, it
tries to find a suitable Controller class for handling that request.
That is where PortletModeHandlerMapping comes into
the picture.
The
PortletModeHandlerMapping class is a simple implementation
of the
HandlerMapping interface and is used by DispatcherPortlet to find a
suitable Controller for every request.
The PortletModeHandlerMapping
class uses Portlet mode for
the current request to find a suitable
Controller class to use for handling
the request.
The portletModeMap
property
of portletModeHandlerMapping bean is
the place where we map
the
Portlet mode name against
the Controller class. In
the sample code, we
show that viewController is responsible for handling View mode requests.
Developing UserController.java
In
the preceding section, you learned that
the
viewController bean is responsible for handling all
the View mode
requests. Your next step is to create
the UserController.java class as
shown below:
public class UserController extends AbstractController {
private PointManager pointManager;
public void handleActionRequest(ActionRequest request, ActionResponse response) throws Exception {
}
public ModelAndView handleRenderRequest(RenderRequest request, RenderResponse response)
throws ServletException, IOException {
String now = (new java.util.Date()).toString();
Map<String, Object> myModel = new HashMap<String, Object>();
myModel.put("now", now);
myModel.put("users", this.pointManager.getUsers());
return new ModelAndView("users", "model", myModel);
}
public void setPointManager(PointManager pointManager) {
this.pointManager = pointManager;
}
}
Every controller class in Spring Portlet MVC Framework must implement
the org.springframework.
web. portlet.mvc.Controller interface directly
or indirectly. To make things easier, Spring Framework provides
AbstractController class, which is
the default implementation
of the
Controller interface. As a developer, you should always extend your
controller from either AbstractController or one
of its more specific
subclasses. Any implementation
of the Controller class should be
reusable, thread-safe, and capable
of handling multiple requests
throughout
the lifecycle
of the portlet.
In
the sample code, we create
the ViewController class by
extending it from AbstractController. Because we don't want to do any
action processing in
the HelloSpringPortletMVC portlet, we override only
the handleRenderRequest() method
of AbstractController. Now,
the only
thing that HelloWorldPortletMVC should do is render
the markup
of
View.jsp to
the user when it receives a user request to do so. To do
that, return
the object
of ModelAndView with a value
of view equal to
View.
Developing
web.xml
According to Portlet Specification 1.0, every portlet
application is also a Servlet Specification 2.3-compliant
Web
application, and it needs a
Web application deployment descriptor (that
is,
web.xml). Let’s create
the web.xml file in
the /WEB-INF/ folder as
shown in listing 4. Follow these steps:
Open
the existing
web.xml file located at
/WebContent/WEB-INF/web.xml.
Replace
the contents
of this file with
the code as shown below:
<servlet>
<servlet-name>ViewRendererServlet</servlet-name>
<servlet-class>org.springframework.
web.servlet.ViewRendererServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>ViewRendererServlet</servlet-name>
<url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.
web.context.ContextLoaderListener</listener-class>
</listener>
The web.xml file for
the sample portlet declares two things:
ViewRendererServlet.
The ViewRendererServlet
is
the bridge servlet for portlet support. During
the render phase,
DispatcherPortlet wraps PortletRequest into ServletRequest and forwards
control to ViewRendererServlet for actual rendering. This process allows
Spring Portlet MVC Framework to use
the same View infrastructure as
that
of its servlet version, that is, Spring
Web MVC Framework.
ContextLoaderListener.
The
ContextLoaderListener class takes care
of loading
Web application
context at
the time
of the Web application startup.
The Web application
context is shared by all
the portlets in
the portlet application. In
case
of duplicate bean definition,
the bean definition in
the portlet
application context takes precedence over
the Web application context.
The ContextLoader class tries to read
the value
of the
contextConfigLocation
Web context parameter to find out
the location
of
the context file. If
the contextConfigLocation parameter is not set,
then it uses
the default value, which is
/WEB-INF/applicationContext.xml, to load
the context file.
The Portlet Controller interface requires two methods that handle
the two phases
of a portlet request:
the action request and
the render request.
The action phase should be capable
of handling an action request and
the render phase should be capable
of handling a render request and returning an appropriate model and view. While
the Controller interface is quite abstract, Spring Portlet MVC offers a lot
of controllers that already contain a lot
of the functionality you might need – most
of these are very similar to controllers from Spring
Web MVC.
The Controller interface just defines
the most common functionality required
of every controller - handling an action request, handling a render request, and returning a model and a view.
How rendering works
As you know, when
the user tries to access a page with PointSystemPortletMVC portlet on it or when
the user performs some action
on any other portlet on that page or tries to refresh that page, a
render request is sent to
the PointSystemPortletMVC portlet. In
the
sample code, because DispatcherPortlet is
the main portlet class, Weblogic Portal / Webcenter Portal calls its render() method and then
the following
sequence
of events occurs:
The render() method
of DispatcherPortlet calls
the doDispatch() method, which in turn calls
the doRender() method.
After
the doRenderService() method gets control,
first it tries to find out
the locale
of the request by calling
the
PortletRequest.getLocale() method. This locale is used while making all
the locale-related decisions for choices such as which resource bundle
should be loaded or which JSP should be displayed to
the user based on
the locale.
After that,
the doRenderService() method starts
iterating through all
the HandlerMapping classes configured for this
portlet, calling their getHandler() method to identify
the appropriate
Controller for handling this request.
In
the sample code, we have configured only
PortletModeHandlerMapping as a HandlerMapping class.
The
PortletModeHandlerMapping class reads
the value
of the current portlet
mode, and based on that, it finds out,
the Controller class that should
be used to handle this request. In
the sample code, ViewController is
configured to handle
the View mode request so that
the
PortletModeHandlerMapping class returns
the object
of ViewController.
After
the object
of ViewController is returned,
the doRenderService() method calls its handleRenderRequestInternal() method.
Implementation
of the handleRenderRequestInternal()
method in ViewController.java is very simple. It logs a message saying
that it got control, and then it creates an instance
of ModelAndView
with a value equal to View and returns it to DispatcherPortlet.
After control returns to doRenderService(),
the next
task is to figure out how to render View. For that, DispatcherPortlet
starts iterating through all
the ViewResolvers configured in your
portlet application, calling their resolveViewName() method.
In
the sample code we have configured only one
ViewResolver, InternalResourceViewResolver. When its resolveViewName()
method is called with viewName, it tries to add /WEB-INF/jsp as a prefix
to
the view name and to add JSP as a suffix. And it checks if
/WEB-INF/jsp/View.jsp exists. If it does exist, it returns
the object
of JstlView wrapping View.jsp.
After control is returned to
the doRenderService()
method, it creates
the object PortletRequestDispatcher, which points
to /WEB-INF/servlet/view – that is, ViewRendererServlet. Then it sets
the object
of JstlView in
the request and dispatches
the request to
ViewRendererServlet.
After ViewRendererServlet gets control, it reads
the
JstlView object from
the request attribute and creates another
RequestDispatcher pointing to
the /WEB-INF/jsp/View.jsp URL and passes
control to it for actual markup generation.
The markup generated by
View.jsp is returned to user.
At this point, you may question
the need for
ViewRendererServlet. Why can't DispatcherPortlet directly forward
control to View.jsp? Adding ViewRendererServlet in between allows Spring
Portlet MVC Framework to reuse
the existing View infrastructure. You
may appreciate this more when we discuss how easy it is to integrate
Apache Tiles Framework with your Spring Portlet MVC Framework.
The attached project SpringPortlet.zip should be used to import
the project in to your
OEPE Workspace. SpringPortlet_Jars.zip contains jar files required for
the application.
Project is written on Spring 2.5.
The same JSR 168 portlet should work on Webcenter Portal as well.
Downloads:
Download WeblogicPotal Project which consists
of Spring Portlet.
Download Spring Jars
In-addition to above you need to download Spring.jar (Spring2.5)
