 | Level: Intermediate Kris Vishwanathan (v2kris@us.ibm.com), IT Architect, IBM
04 Jan 2006 One of the challenges in portlet development is dealing with data persistence. Unless data persistence is designed into the underlying application, information entered into a portlet on one page is lost when the user navigates to a new page. This is especially problematic in transactional portal applications such as those found in call centers, as well as in travel and financial industries. This article shows you a technique using IBM® WebSphere® Portal Server Version 5.1 (WebSphere Portal) to transparently persist form data while the user switches between portal pages. It is intended for portal developers who have intermediate experience developing portlets. You should have a good understanding of Java programming, Struts, the IBM Portal API, and Rational® Application Developer 6.0.x. You should also be familiar with the web clipping portlet, which is used in the example scenario. You can use a technique similar to the one illustrated here for both IBM and JSR 168 portlets. This article includes a sample download.
Introduction
WebSphere Portal aggregates and integrates disparate enterprise applications and content in order to present a single, unified application experience for end users. Vendors have developed packaged portlets to surface common applications using WebSphere Portal including ERP, CRM, host, and client/server applications.
Prior to the advent of portals, new enterprise applications were developed as client/server applications in which separate window instances provided users a means to multi-task or reference information in different systems. Each window preserved the user session and information entered. In the portal realm, these various windows would correlate to different portlets with each portlet often residing on multiple portal pages. Therefore, as a user moves between applications in an effort to multi-task or reference information, the user’s application-specific information would be lost.
Introducing the business scenario
The business scenario used in this article is based on a call center application. In a call center, customer service representatives (that is, portal users) need the ability to move between portal pages to reference information and to enter data, while maintaining application-specific context and data.
For example, the portal user accesses the portal to:
- Enter customer information on one page.
- Navigate to other portal pages (containing, portlets to web, host and client/server applications).
- Return to the initial screen.
Our challenge is to transparently store the data entered into the original portlets (from step 1), and to maintain the data while the user navigates to and from other portal pages.
To demonstrate the scenario, we use a web clipping portlet on the main page, Call Center App, to clip the legacy struts web application. Other standard installed pages are used to simulate page navigation.
Developing the example scenario
The most popular way to to store and retrieve data (persist) data has been to use cookies and JavaScript. This option does not require the browser to do a form submit because the execution processes on the client side.
The method that we have selected leverages simple JavaScript techniques that force the form submit so that the back-end application can take care of persisting the form data into a session object. In order to transparently submit the form, we chose to use the BODY tag unload() event. However, because there are no HTML or BODY tags in any of the portlet views as part of the portlet standard, we needed to add the unload() event to the theme's Default.jsp.
In the unload event we force the form submit so that the back-end application can read the form elements to persist the form data.
For your reference, the sample legacy application WAR file and Default.jsp code are provided in a download.
To develop the sample business scenario:
- Set up the back-end application.
Download and deploy the sample code,Inci2.war, into a local WebSphere Application Server 6.0. This application is a simple action class which returns control to the page. We have used a Struts application with a form bean set to session in struts-config.xml so that form data persistence is taken care by the Apache Struts framework.
Listing 1. Back-end application’s struts-config.xml file and java source file
<action path="/customerRequestAction"
type="inci.resources.customerRequestAction"
name="customerRequestBean"
validate="false"
input="/customerRequest.jsp"
scope="session">
<forward name="create" path="customerRequest.jsp"
contextRelative="true" redirect="false" />
</action>
Action class of the web app simply returns control back.
package inci.resources;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
public class customerRequestAction extends Action {
public ActionForward execute (ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws Exception {
customerRequestForm loginForm = (customerRequestForm) form;
System.out.println("Loginaction");
return (mapping.findForward("create"));
}
} |
- Validate that you are able to access the back-end application using the following url:
http://localhost:9080/Inci/customerRequest.jsp
|
- From the WebSphere Portal admin console, clip the back-end Web application as shown in Figure 1.
Web clipping is out-of-the-box function in WebSphere Portal 5.x. You can clip an entire Web page or part of it using the Web Clipping Editor. After clipping the page or portion, the editor creates a portlet which you can be place on any portal page. Figure 1 illustrates the Web clipping portlet.
Figure 1. Clip the back-end Web application
- Create a portal page and attach the Web clipping portlet created in the previous step.
- Create additional portal pages and attach any portlets. These pages will be used by the user to navigate away from the page with the Web clipping portlet.
You could either use out-of-the-box sample pages or create new pages from the WebSphere Portal Administration console. For example, you could create a new page called Switch under My Portal.
- Implement a form submit by adding the following JavaScript function to the Default.jsp of the theme that you are using.
Listing 2. JavaScript function to be added in the Default.jsp of your theme
function formSave(formName, act){
if(window.document.activeElement != "[object]"
&& window.document.activeElement != null){
// window.document.activeElement returns the name of the object clicked,
// we will be using this to capture the link/page user clicked to
// navigate after submitting the form.
if (!stopSubmits) {
stopSubmits = true;
// We are using stopSubmits as a Boolean variable to stop the form
// submission if user is intentionally performing other actions in the form.
var form = document.forms[formName];
form.all.tags("input").item("hiddenOperation").value = act;
//hiddenOperation is a hidden field used to differentiate different actions
// at the server side just in case needed.
form.elements["url"].value = window.document.activeElement;
form.submit();
window.location.href = form.elements["url"].value;
// above statement redirects to url clicked after form submit.
}
}
} |
Because the portal theme is common across all of the portal pages, you need to make sure that the form submission happens only on the page that contains the portlet. Therefore, include the conditional statement:
if document.forms['wpsFormtoSave'] != null
|
If you have a situation in which you need to save data from multiple portlets, you can do so by looping through the forms.
To make sure that this script is not triggered when the user is trying to save the form intentionally by clicking on a submit button, check the if (!stopSubmits) button action.
You can submit the Web page transparently by re-directing the user's action by clicking on any page, but the user would expect to go to the page clicked. This is achieved by reading the page clicked using the window.document.activeElement JavaScript method, and storing it into a form variable called url, which is read after the page submission is complete.
We tried another technique for redirecting the url on the server side using response.sendRedirect("<url>" ), but this resulted in opening the entire portal page in the portlet window. Therefore, we opted to redirect the url on the client side.
Alternative scenario:
In some instances you may not be clipping a back-end application but rather working with a custom developed portlet application. In this case, the data can be submitted to the portlet application by leveraging the actionPerfomed event. If this is the case, you do not need to implement the default theme code above; instead, you could leverage the following portlet application receive action:
Listing 3. JavaScript function to be added in the Default.jsp of your theme
<body marginwidth="0" marginheight="0"
<%=bidiDirAttr%> onUnload="if
(document.forms['<portletAPI:encodeNamespace
value="wpsFormtoSave"/>'] != null )
formSave(['<portletAPI:encodeNamespace
value="wpsFormtoSave"/>');">
function formSave(formName, act){
if(window.document.activeElement != "[object]" &&
window.document.activeElement != null){
if (!stopSubmits) {
stopSubmits = true;
var form = document.forms[formName];
form.all.tags("input").item("operation").value = act;
form.elements["url"].value = window.document.activeElement;
document.<portletAPI:encodeNamespace
value="wpsFormtoSave"/>.action =
"<portletAPI:createURI>
<portletAPI:URIAction name='formSaveAction'/>
</portletAPI:createURL>";
//encoding namespace and creating an action to trigger
// actionPerformed() event is required if you use custom portlets
// instead of clipped applications.
form.submit();
window.location.href = form.elements["url"].value;
}
}
}
|
- Add the unload Javascript event to the BODY tag of Default.jsp.
<body marginwidth="0" marginheight="0"
<%=bidiDirAttr%>
onUnload="if (document.forms['wpsFormtoSave'] != null )
formSave('wpsFormtoSave');">
|
- Load the portal page so you can prepare to test the scenario. You see the following portlet:
Figure 2. The completed portlet
Now that you have implemented the scenario, you can run through the usage scenario and verify that the data entered is persisted throughout the user's navigation.
 |
Testing the scenario
Now, to test the scenario, you would follow the user steps described earlier in the business scenario introduction:
- Enter information on one page.
- Navigate to another portal page.
- Return to the initial page, where the data entered early should be preserved.
To illustrate this sequence, the screen shots below show the user starting to enter data into a form; then, half way through the data entry, the user navigates to another page. When the user returns, the user finds all the data that was previously entered is still intact.
Figure 3. User starts to enter customer information on one page.
Figure 4. User navigates to another portal page.
Figure 5. User returns to the initial data entry form portlet page.
Conclusion
In this article, we demonstrated a technique to transparently submit a form to a legacy back-end application in a manner that persisted the data as the user navigated between portal pages. In addition, we showed how a similar technique can be used in a situation where a portlet application rather than a clipped legacy application is used.
Download | Description | Name | Size | Download method |
|---|
| Code samples | samples-persisting.zip | 6.6 MB | FTP|HTTP |
|---|
Resources Learn
Get products and technologies
-
Rational Application Developer V6: Download trial software from developerWorks. Includes the portal tools and a test runtime copy of portal that you can use to develop a prototype.
About the author | 
| | Kris Vishwanathan is an IT Architect who has been with IBM since 2003. He worked as a senior developer and architect for IBM Systems and Technology Group before joining IBM Software Services for Lotus at the end of 2004. He has been part of the delivery team implementing WebSphere Portal and Web Content Management (WCM) solutions. In addition to architecting solutions for clients, he also sets up portal production environments involving portal clustering, Tivoli Access Manager, LDAP, user registry configurations, and portlet development using JSR168, JSF, IBM API, and WCM API. He is an IBM Certified WebSphere Portal System Administrator and Solution Developer. |
Rate this page
| |
