Portlets vs. Servlets: Request Processing with Web Components, Page 2
Sending requests using portlet URLs
In portlets, portlet URLs are used to send a request, of a particular request type, to portlet instances. Let's look at how portlet URLs are different from servlet URLs.
When developing Web applications using servlets, the servlet's
service method is invoked during the request handling. In the case of servlets, the HTTP method (identified by the
method attribute) is used to determine the specific method (like
doPost) of the servlet to be invoked. The
action attribute identifies the servlet that needs to be invoked when the form is submitted. A sample
form tag in an HTML page can be as follows:
<form id="myId" name="myForm" method="POST" action="/myapp/myservlet.do">
formtag shown above, the servlet mapped to the URL
/myapp/myservlet.dois called when
In the case of portlets, you don't have the option to specify the URL to which a portlet maps. In portlet applications, the portlet container provides objects that can be used by portlets to create self-referencing URLs; that is, these URLs refer to the portlet that created them. These self-referencing URLs are called portlet URLs. Figure 2 shows how portlet URLs work.
Figure 2: A portlet URL is interpreted by the container to generate the portlet request. During the request processing, the portlet sets self-referencing portlet URLs as part of the content.
At #1, request for a portlet is received by the portlet container. The portlet container invokes the portlet, which in turn generates the content in its render phase. At #2, the portlet sets portlet URL A as part of its generated content. Because requests can only be sent to a portlet using self-referencing portlet URLs, the portlet instance is responsible for setting portlet URLs as part of it generated content. At #3, the user's action results in a send request to portlet URL A, which results in an invocation of the portlet at #4. At #5, the portlet creates fresh content and sets portlet URL B as part of its content.
You may have noticed that figure 2 doesn't show how the request was received by the portlet for the first time. A question arises at this point: how does a portlet receive a request to generate the content for the first time? A portlet can display a message without requiring us to explicitly send a request to the portlet. This happens because the content generation request (called render request) is sent to the portlet by the portal server when a user adds a portlet to a portal page or visits a portal page containing portlet(s).
It is not possible for a portlet to generate URLs referring to other portlets in the portal.
Let's now look at the different URL types in portlets.
Portlet URL types
The request-processing cycle for a portlet is kicked off when the user submits a request to the portlet URL by clicking a hyperlink or submitting a form. Portlet URLs are related to the portlet request types that we discussed earlier in this article. Portlet URLs are classified by the portlet specification based on the requested action from the portal page. The three different types of portlet URLs are defined as follows.
- render URL -- intended for asking a portlet instance to generate markup (like HTML, XML, or WML) based on its current state. The request sent to the portlet by a render URL is referred to as a render request.
- action URL -- intended for action processing, which results in a state change on the server. The request sent to the portlet by an action URL is referred to as an action request.
- resource URL -- intended for rendering content or retrieving resources (like image files). Depending upon the application requirement, a resource URL may be used for updating the application state. The request sent to the portlet by a resource URL is referred to as a resource request.
Portlets don't have an event URL type for sending event requests to portlets.
A portlet URL is like any other URL but difficult to comprehend because it is generated by the portlet container for internal use. When a request is submitted from the portal (by a user's clicking of a link or a button), the portlet URL (associated with the link clicked or form submitted) is interpreted by the portlet container to identify the target portlet instance and the type of request (action, render, or resource) received from the client. The following
form tag from HTML rendered by a portlet shows portlet URL in the
<form id="search" name=" " action="http://localhost:8080/web/guest/home?p_p_id=HelloWorldPortlet_WAR_helloWorld_INSTANCE_MrP9&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&p_p_col_id=column-1&p_p_col_count=1&_HelloWorldPortlet_WAR_helloWorld_INSTANCE_MrP9_action=someAction" method="post">
It is important to understand the purpose of different portlet URLs because, based on the URL type, corresponding lifecycle methods (like
processAction) are invoked on the portlet instance.
The different lifecycle interfaces in a portlet help to separate responsibilities for generating content, processing action, handling a received event, and serving resources in your portlet class. A clear understanding of the purpose of different lifecycle interfaces and methods helps you to segregate your logic appropriately in your portlet class. For instance, the
processAction method is intended for processing action and not for generating content. If you attempt to generate content by dispatching a request to a JSP page (using
PortletRequestDispatcher) or by directly writing to the response output stream, any such effort to generate content will be ignored by the portlet container. Similarly, the
render method is for generating content and not for processing user actions. If you write action-processing logic in the
render method instead of the
processAction method, action processing will take place every time the portlet's
render method is invoked (either because the user refreshed the portal page or the action request was sent to another portlet on the same portal page), which is undesirable.
About the AuthorAshish Sarin has over 10 years of experience designing and developing Web applications and portals using Java EE and the Portlets APIs. He has authored many articles on portlets and rich Internet applications using Liferay, DWR, DOJO, JSF, and Spring Portlet MVC.
Page 2 of 2