Skip to main content

skip to main content

developerWorks  >  WebSphere | Rational  >

Developing JSR168 Struts portlets: Part 1. Creating a simple portlet

developerWorks
Document options

Document options requiring JavaScript are not displayed

Sample code


Rate this page

Help us improve this content


Level: Intermediate

Sunil Patil (sdpatil@gmail.com), Software Engineer, BMC

04 Jan 2006

This article describes how to develop JSR 168 Portlet API Specification 1.0 compliant portlets using the IBM® Struts Portlet Framework 5.1.0.1. It walks through creating a simple Struts portlet using Rational® Application Developer V6.0 (hereafter called Application Developer) as the development environment. You could deploy and run this portlet to WebSphere® Portal V5.1.0.1 (hereafter called WebSphere Portal). This is the first in a two-part series on developing JSR 168 Struts portlets. In this part, you see how to create a simple Struts portlet, how to validate content (using the Validation framework), and how to display the header and footer (using the Tiles extension). In Part 2, you learn how to add additional features to the portlet.

Introduction

Apache Struts is an open source project of the Apache Software Foundation that implements the Model-View-Controller (MVC) design pattern. Struts is a powerful framework which is suitable for both small and large development teams that need to split the development work among specialists. If you want your Java™ developers to concentrate only on writing business logic, and your UI designers to create and maintain JSP pages, then you could use Struts to help organize the work for these developers.

Struts has an active development and user community. The reason for Struts popularity in the servlet environment also applies to the portal environment. You can use the IBM Struts Portlet Framework (see Resources) to create Struts 1.1.0 applications that can be deployed to WebSphere Portal. It lets you develop:

  • IBM WebSphere Portlet API compliant Struts portlets, which you can deploy to WebSphere Portal V4.2.x and V5.x
  • Portal Specification API 1.0 (JSR 168) compliant Struts portlets which you can deploy to WebSphere Portal V5.1.x

This article steps you through how to develop a simple JSR 168 compliant Struts portlet. You discover how request processing differs in the portlet Struts environment from the servlet Struts environment. You also see how to use the IViewCommand interface, and how to use popular Struts features, such as the Validation Plug-In and Tiles Plug-In, to enhance the basic portlet.

This article is not intended to be an introduction to either Struts or JSR 168. It assumes you have some experience using Struts in a Servlet environment and that you want to take advantage of this knowledge in a portlet environment. It can also be of interest to developers who already know how to use Struts to develop IBM Portal API compliant portlets. If you are new to either Struts or portlet technology, then please take a look at the Resources section for links to references which can help you get that background.



Back to top


Setting up the development environment

Rational Application Developer is a development environment for developers, including portlet developers. It supports development of IBM WebSphere Portlet API compliant JSF and Struts portlets using a wizard. Actually, it is very easy to use; all you have to do is just a few clicks and you are ready to go. Application Developer also provides wizards for creating JSR 168 Compliant JSF portlets. However, there is no built-in wizard for developing JSR 168 compliant Struts portlets built, so you need to follow these additional steps to set it up with this support.

  1. Download IBM Struts Portlet Framework 5.1.0.1 from the IBM Workplace Solution Catalog – WebSphere IBM Portal (navcode = 1WP10003N). This file contains sample applications and documentation.
  2. Extract the zip file to your machine; for example, to: C:\SampleCode.
  3. In Application Developer, import C:\SampleCode\sample\SPFStandardBlank.war as a WAR file. Use WebSphere Portal v5.1 stub. See the figure below.
    Figure 1. Importing the Struts framework sample
    Figure 1. Importing the Struts framework sample
  4. Click Finish to create a blank Struts portlet application.
  5. Right-click on the ContactMang project, and export it as WAR file.
  6. Install ContactMang.war on your WebSphere Portal server.
  7. Add this portlet to a test page, and you should see a Welcome message.

Now that you have completed setting up the development environment, you can work on the sample project using the convenience of Application Developer.



Back to top


Exploring the generated skeleton portlet

Now, let's look at the contents of ContactManag (SPFStrandardBlank.war). The first thing you might observe is that ContactManag project does not have any Java code. The index.jsp forwards control to /welcome.do, which is an instance of org.apache.struts.action.ForwardAction with /pages/Welcome.jsp as path.

You see that WEB-INF/lib contains all the required jars, and /WeB-INF/tld contains definitions for Struts tag library. This structure is very similar to the contents of strutsblank.war in the servlet environment; the only difference is that WEB-INF contains the additional portlet.xml file, and WEB-INF/lib contains few more jars.

Next, take a look at some of the content. Open web.xml. You find that it contains the welcome file list, which is /index.jsp (as expected) and declarations of tld files.

Next, open portlet.xml, where com.ibm.portal.struts.portlet.StrutsPortlet is defined as the Controller Portlet class. So every request to StrutsPortlet should go to this class, and it will take care of routing. StrutsPortlet has an init parameter with a path to struts-config file.

Finally, open struts-config.xml. When you look at it for the first time, you might not see any difference between it and the struts-config.xml file in the servlet environment. However, take a closer look and you see that the difference is in the request processor. A JSR 168 compliant Struts portlet should use the com.ibm.portal.struts.portlet.WpRequestProcessor class, or its subclass, as request processor. This class is responsible for adding portlet logic to request processing, which is the topic of the next section.



Back to top


Understanding Struts request processing

Request processing in the portlet environment is much more advanced than request processing in the servlet environment. A portlet can get a request for new content in either of these two conditions:

  • Action Request: A portlet gets an action request when some action is performed on it; for example, when a user submits a form, or clicks on a link or a button. The portlet should first perform any business logic, and then return the result UI to the user.
  • Render Request: A portlet gets a render request for more than one reason, For example, a user performed an action on another portlet on the same page, and the whole page needs to be recreated. Or, a user went to some other page, and then returned to the first page. No business logic needs to be executed; your portlet only needs to generate markup and return it to the user.

WpRequestProcessor overrides org.apache.struts.action.RequestProcessor to change how the request should be processed in the portlet environment.

Figure 2 shows a simplified version of how IBM Struts Portlet framework processes a request. Changes in request processing is much more advanced because of the IStrutsPrepareRender interface. However, let's first understand the basic concepts before moving to the advanced stuff.


Figure 2. Struts Portlet Framework simplified request-processing diagram
Figure 2. Struts Portlet Framework simplified request-processing diagram

WpRequestProcessor handles action requests differently then render requests. When it gets an action request it determines which Action class should be used to process the request. Then, it calls the execute method of that Action class. Depending on the result of Action, it creates an object of IViewCommand and stores information that is required to render the view in it. An example of information required to render the view is the path of the forward JSP, Form Bean. If you don’t understand the IViewCommand don't worry; we have a complete section devoted to it.

Once it has an object of IViewCommand, it stores it in the session, and calls its execute method. The Execute method passes control to the JSP (if control is forwarded to JSP), and the JSP will use information from Form Beans and other attributes to generate the final markup.

However, if a render request is made, then WpRequestProcessor does not call the execute() method of your action class. According to the Portlet Specification, the render view is not supposed to execute any business logic; it is only suppose to render the UI. So, WpRequestProcessor reads the object of IViewCommand from the session, and calls its execute() method. This execute() method again passes control to the JSP, which generates markup that will be displayed to the user.

As usual, there are exceptions. For example, suppose you are developing a Stock Ticker portlet which should display the latest prices of stock that a user is interested in. Now, you don’t want the user to click the portlet's Refresh button every time he or she wants to get a new price; instead, whenever the page refreshes for some reason, you want to query the Stock Update site, and display the latest prices to the user.

The Struts Portlet Framework includes an IStrutsPrepareRender interface for these types of requirements. This is a marker interface. You can implement this interface in your Action class to get special treatment from WpRequestProcessor. When the request processor gets a render request and finds that it is a target to the Action class implementing IStrutsPrepareRender interface, then it passes control to the execute method of that Action class, instead of directly executing execute() method of IViewCommand object stored in session. For a detailed discussion about the use of the IStrutsPrepareRender interface, including advanced features, see Executing Struts actions during the render phase of IBM WebSphere Portal.



Back to top


Working with the IViewCommand interface

While discussing the Struts request processing, we mentioned IViewCommand; now let's take a closer look at this interface. As described in the Struts Portlet Framework documentation (in the WebSphere Portal InfoCenter), the "IViewCommand is a command pattern interface used to provide a mechanism to encapsulate the information needed to display a view". In other words, an IViewCommand object is used to pass information to the JSP page for rendering a view.

If you look again at the Struts Portlet Framework request processing diagram, you will find that the only link between your Action class and the forward JSP is IViewCommand.

When writing a Struts application in the servlet environment, the normal design pattern is to collect data entered by the user in the ActionForm, and to pass it to the Action class. Then inside your Action class: execute the business logic; populate a view bean; set it as request attribute; and forward control to the JSP page where the Struts tag library is used to generate markup.

In the portlet environment, the IViewCommand achieves the same thing, but requires a few additional steps. The PortletRequest object that you get in the Action class is different from the one you get in a JSP page. So if you want to set a request attribute in the Action class and you want to access it in JSP page, then you have to request theIViewCommand. There are two ways to do this:

  1. Use StrutsViewCommand.addAttributeNameToSave("attributeName").

    Call this method passing the name of the attribute which you want to be carried to the JSP. For example, inside the ContactAction.java class you want to set an object of ContactVo.java type to request scope, and you want that object to be available in the JSPs. You can code this: 

    StrutsViewCommand.addAttributeNameToSave("contactVO");
request.setAttribute("contactVO",<any object>);

    Then, you can access the contactVO object in your JSP page by calling portletRequest.getAttribute("contactVO").

  2. Use StrutsViewCommand.addAttributeTypeToSave(AttributeType.class).

    Call this method passing the type of objects that you want to get carried from Java code to the JSP. For example, in the previous example, you could code this instead: 

    StrutsViewCommand.addAttributeTypeToSave( ContactVO.java);
request.setAttribute("somename",<Object of ContactVO.java type>);

The Struts Portlet Framework has different types of ViewCommand objects, and it creates objects based on the extension of the ActionForward URI.

StrutsViewJSPCommand
When the URI path is *.jsp, then a viewCommand object of StrutsViewJSPCommand is created.
StrutsViewActionCommand
If WpRequestProcessor determines that your Action class is implementing the IStrutsPrepareRender interface, then it will create a ViewCommand object of type StrutsViewActionCommand.
StrutsViewTilesCommand
If you forward control to the Tiles definition, then object of type StrutsViewTilesCommand should be created.

There are a few more types of ViewCommand, and objects of these types are created based on the extension. The important point to remember is that Struts uses com.ibm.portal.struts.plugins.ViewCommandFactory for creating objects of IViewCommand type. So, in the future, you can extend it if you want it to handle some extensions differently



Back to top


Creating a sample application

So far we've talked about some of the capabilities of the Portlet Struts Framework, including how requests are processed and what the IViewCommand interface does. Now its time to take it to the next level, in which we develop a sample Struts portlet using the framework.

In order to illustrate the concepts, we develop a sample Contact Management Portlet. This portlet lets you like add new contacts, and update or delete existing contacts. We have a dependency on a database. It could take a long time to set up your environment for a database; so, in this example we use the use DAO (Data Access Object) pattern.

First, we create an IContact.java interface in which we declare methods required for accessing the contact table. We have two options; we can either create a class which talks to the Contact Table, or we can create a class that uses a simple Hashmap for storing contacts. You can download the sample code for a class which uses a Hashmap for storing contacts.

Figure 3 shows the flow that we want to use for the Add Contact use case.


Figure 3. Contact Management Portlet, Add Contact use case flow
Figure 3. Contact Management Portlet, Add Contact use case flow

We first create AddContact.jsp which will have a form to collect inputs from the user. This form is submitted to ContactAddAction; we use ContactForm to carry the data. Inside ContactAction, we insert the contact and then create a list of all contacts from the database. This list is set in the request scope and is sent to the JSP. ContactList.jsp iterates through the list and displays it to the user as a spreadsheet.

To create the Contact Management application, using Application Developer:

  1. 1. Create the IContact.java class: 
    public interface IContact {

	public ArrayList getContacts();
	public int saveContact(ContactForm contact);
	public int deleteContact(String contactId);
	public ContactForm getContact(String contactId);
}

    IContact.java is an interface that declares methods required for manipulating data in the contact table.

  2. Create ContactForm.java which is the ActionForm used in our sample. It defines the instance variable for all the contact table columns. 
    public class ContactForm extends ActionForm{
      private String contactId;
      private String firstName;
      private String lastName;
      private String phone;

  	   public String getContactId() {
	      return contactId;
	   }
	   public void setContactId(String contactId) {
	     this.contactId = contactId;
  	   }
	
    //Similarly create getters and setters methods for other instance variables
    }

  3. Now it is time to create the Action class. In the Struts Portlet Framework, you need to choose which version of Action class you want to use. You can extend the Action class from org.apache.struts.action.Action, and override execute method like this: 
    public ActionForward execute(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response);

    Or, you can override com.ibm.portal.struts.action.StrutsAction, and override the execute method like this: 
    public ActionForward execute(ActionMapping mapping, ActionForm form,
PortletRequest request, PortletResponse response) ;

    In both these cases, the response object is not available to the Action class because these methods are called in theAction phase. However, if you implement the IStrutsPrepareRender method, then these methods are called in the render phase, and you have access to the response object.

    Extend the ContactAction class from com.ibm.portal.struts.action.DispatchAction, which is a subclass of StrutsAction class. You do this for a couple of reasons. First, we do not have much business logic in the Action class; all we want to do in the Action class is to call methods of IContact.java. Second, we can put all contact related logic in one class.

    public class ContactAction extends DispatchAction{
public ActionForward listContacts(ActionMapping mapping, ActionForm form, 
  javax.portlet.ActionRequest actionRequest, javax.portlet.ActionResponse actionResponse)throws Exception{
  IContact contactDb = new HashmapContact();
  ArrayList contactList = contactDb.getContacts();
  actionRequest.setAttribute("contactVO",contactList);
	
	return mapping.findForward("listcontact");
	}
// Methods for adding, updating, and deleting contacts.
}

  4. Now, create the struts-config.xml file: 
    <struts-config>
    <form-beans>
    	<form-bean name="contactForm" type="com.sample.ContactForm"/>
    </form-beans>
    <global-forwards>
    </global-forwards>
    <action-mappings>
        <action
            path="/deletecontact"
            type="org.apache.struts.actions.ForwardAction"
            parameter="/html/view/deletecontact.jsp"/>
        <action path="/contactAction" 
        type="com.sample.ContactAction"
        name="contactForm"
        scope="request"
        parameter="method">
        	<forward name="listcontact" path="/html/view/listcontact.jsp" />
        	<forward name="contactform" path="tiles.contact.form" />
        	<forward name="searchcontact" path="/html/view/searchcontact.jsp" />
		</action>
    </action-mappings>
  <controller processorClass="com.ibm.portal.struts.portlet.WpRequestProcessor"/>
  <message-resources parameter="nls.ContactApplication"/>
  <plug-in className="com.sample.CommandPlugIn">  </plug-in>
</struts-config>

    Creating this file is similar to any other struts-config.xml file in the servlet environment, with the difference that we are your using WpRequestProcessor as the request processor. We discussed this in the Struts Request Processing section. We also declare com.sample.CommandPlugIn as a custom plug-in. You see why that is needed in the next step.

  5. Create com.sample.CommandPlugIn class like this 
    public class CommandPlugIn implements PlugIn{
  public void destroy() {
  }
  public void init(ActionServlet arg0, ModuleConfig arg1)
    throws ServletException {
 	    StrutsViewCommand.addAttributeNameToSave("contactVO");
    }
}

    In the Contact Management application, we follow the rule that whenever the Action class wants to pass a value bean to the JSP page, it sets an attribute with the name equal to "contactVO" in the request. By calling StrutsViewCommand.addAttributeNameToSave("contactVO"), we inform the Struts Portlet Framework that we want the attribute with the name "contactVO" for the rendering view; therefore, it should be saved in the ViewCommand object and made available to the JSP.

  6. Finally, create the listContact.jsp page. We access the "contactVO" attribute saved in the request scope, and use it to display the Contact spreadsheet to the user. 
    <%@ taglib uri="http://java.sun.com/portlet" prefix="portlet"%>
<%@ taglib uri="/tags/struts-html" prefix="html" %>
<portlet:defineObjects />
<% 
  com.ibm.portal.struts.common.PortletApiUtils apiUtils = 
    com.ibm.portal.struts.common.PortletApiUtils.getUtilsInstance();
  javax.portlet.PortletRequest portletRequest = 
    (javax.portlet.PortletRequest) apiUtils.getPortletRequest(request);
  java.util.ArrayList contactList = 
    (java.util.ArrayList)portletRequest.getAttribute("contactVO");
%>

    Once you have access to the contactList object, you can iterate through it and display data in tabular format.

  7. Try running your sample application in your test environment, before we move on to add some other features of Struts Portlet Framework. If you have a problem, refer to the download sample code.



Back to top


Validate the contact – Adding support for the Validation framework

Validating user inputs is one of the very common requirements in Web applications. In our Contact Management application, we want to make sure that the user enters the contact ID, first name, and last name, and that they are entered correctly. In programming terms, that means we want to require a valid integer for contactId, and alphabetic entries for firstName and lastName.

The Struts Validation Framework, a popular sub-project of Struts, can help solve this validation requirement. It makes it easy for developers to add logic for validating user input. It was started as an Apache commons project but is now bundled with Struts. It can be divided into two parts:

  • Infrastructure: Enables you to run your validation rules before passing control to the Action class to execute the business logic. It provides two options for when to execute the validation logic.

    You can choose to run your logic on the client side using JavaScript. In this case, some JavaScript code runs in response to an "onsubmit" event. It checks to see if data entered by the user is valid; if it is not, it will not allow the user to to submit the form.

    The other option is to run your validation logic on the server side. In this case, the form is submitted to the server where the validation logic runs. If a problem occurs, error messages are displayed to the user.

    Both these methods are there to make sure that the execute() method in your business logic is run only if the user input is valid.

  • Common rules: Provides a set of common validation rules, such as checking whether a user entered data in a required field or if data entered in particular field is integer or not.

We have to make a decision about where do we want to execute our validation logic in our sample ContactManag application. We use client side validation in the Contact Management portlet because our validation logic is very simple. In order to get it working on client side we have to make some changes which are specific to the portlet environment. (If you want to run your validation logic on the server side, then it is the same as any other Servlet based Struts application.)

  1. Copy validation.xml and validator-rules.xml to the WEB-INF folder. SPFStandardBlank.war does not contain these files so you will have to copy these files from some other WAR. For example, see SPFStandardEditMode.war which is part of the IBM Struts Portlet Framework 5.1.0.1 which you downloaded earlier from IBM Workplace Solution Catalog in the Setting up development environment section.
  2. Declare validator PlugIn in your struts-config.xml by adding these lines: 
    <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
<set-property
  property="pathnames"
  value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml"/>
</plug-in>

  3. Now, declare all the validation rules you want. We will declare that contactId field in contactForm is required integer field. 
    	
<form name="contactForm">
         <field property="contactId"
                 depends="required,integer">
             <arg0   key="prompt.contactId"/>
         </field>
</form>

    This definition says several things. When user is submits a form whose name is equal to "contactForm" (<form name="contactForm">), if you find a field named contactId in that form (<field property="contactId">) then apply two validations on that field. The first validation is that the field is required; the second is that is must be an integer (depends="required,integer") . That is, you want to make sure that contactId is not blank, and that the value entered by the user is an integer. The last part, <arg0 key="prompt.contactId"> says that if you find that the value entered by the user is invalid, then go to the resource bundle defined in struts-config.xml, find the value for "prompt.contactId" key, and display that value as the error message.

  4. Next, you need to define the value of prompt.contactId key (which defines the error message to display to the user). Add this line to nls.ContactApplication.properties: "prompt.contactId= ContactId is required Integer field"
  5. Because we want to execute this validation on the client side, change contactform.jsp like this: 
          
<script language="javascript">
function Validate(form){
   return validate<portlet:namespace/>ContactForm(form);
}
</script>

    <html:javascript formName="contactForm"/>
<html:form action="/contactAction?method=saveContact" onsubmit='return Validate (this);'>

  6. In contactform.jsp, declare that when Struts generates the html for this page, it should add code to validate contactForm in it. The follow line accomplishes this: 
      
<html:javascript formName="contactForm"/>

  7. Next, we decide when this code should be executed. We want to execute the validation routine when the form is submitted. So, we call this function for onsubmit of contactForm.
  8. Now, try submitting the form with invalid data. You should see an error message like that shown in Figure 4.

Figure 4. Invalid data message
Figure 4. Invalid data message

This Javascript error message indicates you successfully integrated Struts validation into your sample application. If you do not see the error message, please go through the steps again to find out what your sample application is missing.



Back to top


Display Header and Footer – Adding support for Tiles framework

Now, we address another common Web application requirement which is adding or changing decorations. While developing a Web application, normally you would like to separate the decoration logic from your core code. For example, suppose you are developing a News Portlet. When that portlet is deployed to Company A, it should show the logo and copyright statement of Company A; when it is deployed to Company B, it should show the trademark and copyright for Company B.

The Tiles Framework, another Struts sub-project, can help you solve such a requirement. Using Tiles, you create a banner and footers separately. You then create a Tiles definition file and a layout file, which defines how the body, header, footer and (possibly) menus should be displayed. The nice part about this capability is that you only have to change one file in order to change the logo or menu, and it would be applied to all the pages.

To demonstrate how to use Tiles in a Struts portlet we will change our Contact Management portlet so that it shows a header and footer on every page. Follow these steps to make changes.

  1. Declare your intention to use the Tiles Framework to Struts by adding these lines to the struts-config.xml: 
      
<plug-in className="com.ibm.portal.struts.plugins.WpTilesPlugin">
   <set-property property="definitions-config" 
     value="/WEB-INF/conf/tiles-def.xml"/>
       <set-property property="definitions-debug" value="2"/>
       <set-property property="definitions-parser-details" value="2"/>
   <set-property property="definitions-parser-validate"
       value="true"/>    
</plug-in>

    These lines tell Struts that you want to use Tiles and tiles definitions for applications that are located in "/WEB-INF/tiles-def.xml".

  2. Next, create a banner.jsp and footer.jsp in the Web Content folder. In order to keep things simple, the banner.jsp can have a single saying "Sample Header" and the footer.jsp can have a single line saying "Sample Footer".
  3. Now, define the layout of the page. Create a ContactLayout.jsp file like this: 
     
<%@ taglib uri="/tags/struts-tiles" prefix="tiles" %>
<table>
  <tr>
	<!-- Insert content of banner.jsp -->
	<td><tiles:insert attribute="banner"/></td>
  </tr>	
  <tr>
	<!-- Content would be inserted here -->
	<td><tiles:insert attribute="body"/></td>
  </tr>	
  <tr>
	<!-- Insert content of footer.jsp  -->
	<td><tiles:insert attribute="footer"/></td>
  </tr>	
</table>

    This layout definition uses tiles tag library to say that show page in tabular format where first row should content of banner.jsp middle row should display body and last row should display content of footer.jsp.

  4. Create a tiles-def.xml file like this: 
     
<tiles-definitions>
 <definition name="tiles.contact.form" page="/ContactLayout.jsp">
    <put name="banner" value="/banner.jsp" />
    <put name="body"   value="contactform.jsp" />
    <put name="footer" value="/footer.jsp" />
 </definition>
</tiles-definitions>

    This tile definition is used for displaying the contact form. It says that ContactLayout.jsp will dictate how the content should be used. Then banner.jsp should be inserted at the place defined by <tiles:insert attribute="banner"> page and similarly with the body and footer attributes.

  5. You need to change struts-config.xml so that a forward action points to the tiles definition instead of to a JSP. So, it will look like this for contactform. 
     
    <forward name="contactform" path="tiles.contact.form" />

  6. Change CommandPlugIn.java from: 
     
StrutsViewCommand.addAttributeNameToSave("contactVO");

    to: 

     
StrutsViewTilesCommand.addAttributeNameToSave("contactVO");

    Remember from the discussion about IViewCommand interface, that the StrutsViewTilesCommand is used when forward is pointing to the Tiles definition instead of JSP page. Since we are changing our contact application to use tiles definitions, you also need to change our CommandPlugIn.java to inform the Tiles View Command that you want it to carry a "contactVO" request attribute from the Action class to JSP page.

After making these changes, export the war, and update the portlet. It should look something like this.


Figure 5. Revised portlet with header and footer
Figure 5. Revised portlet with header and footer

Now you should be able to see the header and footer for all pages in your Contact Management portlet.



Back to top


Conclusion

If you develop any industrial strength portlet application, you need to use some kind of MVC framework, and it is a good idea to use an existing framework instead of creating your own.

The Struts Portlet Framework is a powerful MVC framework because:

  • It lets you take advantage of your knowledge of the Struts framework from the servlet environment.
  • It does not prevent you from taking advantage of some of the advanced concepts from the portlet environment such as support for devices, and modes.

This part of the two-part article series introduced some popular features of the Struts Portlet Framework in the WebSphere Portal environment. In Part 2, you will see how to apply some additional features of the framework, such as support for modes and devices, and integration with the Property Broker.




Back to top


Download

DescriptionNameSizeDownload method
Code samplesjsr168-struts-samples.zip2.7 MBFTP|HTTP
Information about download methods


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

Sunil Patil is a software engineer at the IBM Lab in Pune, India. He works in the WebSphere Portal development team.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful		Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top