UI Frameworks 

Table of Contents | Previous Page | Next Page

---

This page describes the primary server side frameworks that can be used for designing a portlet application for IBM WebSphere Portal. The main focus will be frameworks supported by IBM tooling that are based on IBM WebSphere Portlet Factory, Struts and Java Server Faces.

Generally, WebSphere Portal doesn't depend on a particular User Interface (UI) framework. So, Portal developers are always driving hard to live up to the hype that new technologies claim to provide. The fact is that no single framework provides the solution for all requirements. Having a strong knowledge of the various frameworks is important before initiating the development process. Portal specialists are always weighing the merits and demerits of one framework over another framework. WebSphere Portal supports many different frameworks such as Struts, JavaServer Faces, Spring and others.

The portlet development frameworks are based on a portlet/servlet Bridge/Portal Bridge implementation. These bridges comply to portlet APIs such as JSR 168 or JSR 286. Pure servlet based frameworks like Struts are very difficult to use in a Portlet environment because they only support and understand a single request event. For a Portlet, the request processing has to be handled in two separated action and render events. Furthermore, the Portlet specification doesn't allow servlet access during the action request event.

A distinctive feature of the Portal Bridge is that it removes these barriers and thereby allows the mapping of an action request event to the underlying servlet handler implementation.

The importance of frameworks

Development frameworks have evolved over a period of time based on the best practices of enterprise application development. They use well known design patterns and wrap them with appropriate classes that are shipped with the frameworks. Therefore, application developers need not worry about the low level implementation details of the objects and can focus on the high end design aspects such as the required business logic, user interface and so on.

A framework also clearly identifies the discrete areas of focus for the application development. For example, using the well known Model-View-Controller (MVC) architecture, user interface developers can focus on the view aspect of the application using UI-related technologies such as JSP, Javascript and so n, while Java developers can focus on the model do not need to have UI development specific skills.

Moreover, there exists tooling such as IBM Rational Application Developer and IBM WebShere Portlet Factory that provide easy development with the use of known frameworks. For example, IBM RAD provide wizards for development with the use of popular frameworks and upon using these features of RAD, several key artifacts related to the frameworks are created and wired automatically by the tool. Developers then just need to customize or add additional code to an automatically generated code base created by the tool. This speeds development immensely.

IBM supported frameworks

The following is a list of the primary IBM tools that enable portlet development using the various frameworks:

• Java Server Faces (JSF) 1.1
• JavaEE standard
• IBM Rational Application Developer (RAD) v7.0 / 7.5
• Struts 1.1
• IBM Struts Portlet Framework
• IBM Rational Application Developer (RAD)v7.0 / 7.5
• IBM WebSphere Portlet Factory

WebSphere Portlet Factory

IBM WebSphere Portlet Factory (WPF) provides a development and customization tool of portlets for WebSphere Portal. It is positioned as a development environment, parallel to Rational Application Developer and it offers unique capabilities for developers to develop JSR 168 and JSR 286 compliant portlets.

The tool is based on wizards that developers need to configure to develop various pieces of application logic. These wizards are called builders in the WPF context and they are integrated block by block to fully develop the complete portlet application. Therefore, developers of all skill levels can rapidly build multi-page, complex applications without writing Java code. Java/J2EE skills are not required for developers to develop portlet applications and the engine generates J2EE compliant code behind the scenes.

Secondly, since no code is required to be written, the time to develop the portlets is reduced. Moreover, it becomes very easy to customize these portlets as developers need to tweak the builders or add more builders to get the customized portlets. A single code base creates portlets that run in WebSphere Application Server, WebSphere Portal,
Expeditor, and Lotus Notes 8 clients with very minimal changes.

Lastly, high-level design patterns are available in the Portlet Factory during automatic development of code and configuration of builders by end users. It exposes various toolkits for consuming enterprise data from various databases and expose them as services for further consumption. The presentation layer can consume these services to present data through a custom user interface.

Key concepts

The following sections describe some of the key concepts of WebSphere Portlet Factory based on the following figure.

Builders

Builders are the building blocks for creation of application elements and artifacts like pages, schemas and data, server-side and client-side actions and logic, backend connectivity, and so on. They have easy to use, wizard-like interfaces, capture design patterns and automate the creation of code. Examples include, a page builder is used to define HTML markup, a select builder for implementing the drop down menu functionality in a user interface, a service definition builder for defining a set of services and so on. New builders are constantly being added in WPF and there is a process for creating your own custom builders as well.

Models

Models are containers for aggregating builders. Developers work iteratively with builders in a model to create the presentation as well as service layer logic of the portlet. A model is typically used to create a service or presentation pages. In a typical development scenario, models are also used to organize groups of builders for implementation of a block of functionality for portlets and these models can be further integrated to achieve the complete portlet.

Profiles

Profiles enable the generation of multiple application variations from a single source model. The values of all variables in WPF can be mapped to select their values for profiles. These profiles can represent variations in roles or groups of users accessing the application, customers, partners, or regions or portlet customization by administrators or end users. For example, a common use case is to expose some variables as a configuration mode of the portlet. This enables users to customize the portlet based on values assigned in the configuration mode. WPF enables this functionality with a builder (called Portlet Adapter builder) and such functionality can be achieved very quickly without requiring additional coding by developers.

Portlet Factory support for advanced capabilities

Portlet Factory enables Web 2.0 characteristics in application development in the following ways:

1. Rich user friendly user interfaces: Portlet Factory provides extensive set of builders for generating highly customized and interactive user experiences by providing Dojo and Ajax capabilities. Here are some examples of Client side processing, thereby reducing server side requests:

• Client side sorting of table column data
• Pagination of table data
• Type-ahead options in the search text box
• Contextual pop-up windows with additional details as user hovers cursor over UI elements
• Drag and drop UI elements onto drop zones
• In-line editing of data

All of these are handled as a part of builder configuration.

To see some samples, visit this site: http://www-10.lotus.com/ldd/pfwiki.nsf/dx/ajax-type-ahead-sample-using-database-filtering


2. User participation: Leverage the social aspects of Web 2.0 provided by Lotus Connections for integrating Profiles, Blogs and Dogear in applications.

Samples can be viewed at: http://www-10.lotus.com/ldd/pfwiki.nsf/dx/ibm-lotus-connections-integration-samples

3. Data access through web services standards: REST and Web Services provide a standard method for accessing data and functions regardless of platform, operating system and programming language. WPF provides support for RSS 1.0/2.0 and ATOM 1.0 feeds. WPF provides support to consume and visualize WS-I 1.1 basic profile web services. It can also generate WS-I 1.1 basic profile web services to expose data from enterprise systems.

See samples at : http://www-10.lotus.com/ldd/pfwiki.nsf/dx/06182008070049PMWEBUZ3.htm

Integration with other IBM products and backend repositories

One of the best practices for WebSphere Portlet Factory application development is to develop different models for back end data integration (known as service provider or service model) and the front end user interface (known as service consumer or presentation model).

Service Provider: The service provider model focuses on integration with back end enterprise repositories with the help of various out-of-box integration builders such as SQL Call, SAP Function Call, Web Service Call, and others from WPF. The builders generate the Java code for integrating with these data repositories behind the scenes. If any data transformation is needed, we can make this a part of the service Model as well.

The table below shows the key data sources and services that can be integrated with WebSphere Portlet Factory by out-of-box builders.

System or Data Source	Builder
Relational databases	SQL Call
SAP	SAP Function Call
Siebel	Siebel Business Component
PeopleSoft	PeopleSoft Component Interface
IBM Lotus Domino	Domino Data Access
WSDL/SOAP Web service	Web Service Call or Web Service Multiple Operation
REST-style service, Lotus Connections, Lotus Quickr, InfoSphere MashupHub	REST Service Call
IBM WebSphere Process Server tasks	Human Task Processing Action and Human Task Query
IBM Information Server	IBM Information Service Call
XML Data	Import to XML
Java beans	Linked Java Object
EJB	EJB Call
Microsoft Excel	Excel Import
IBM Workplace Web Content Management	Lotus Web Content Management Access
IBM Lotus Forms	Lotus Forms Launch and Embed

Service Consumer: The consumer layer consumes the data returned by the services layer to present to the portal front end. This is shown in the diagram below.



The key advantages of using such a paradigm are:

• Promotes independent development and testing of front end and data layers.
• Automates back end connectivity provided by WebSphere Portlet Factory builders
• Enables reuse of assets. The service models can be reused by several presentation models as required. Also, the presentation model can be reused to retain a similar user interface pattern, while changing the consuming service model.

Support and documentation

Some key points that may be useful for customers while considering development using WebSphere Portlet Factory include:
1. WebSphere Portlet Factory provides an environment for immediate development of applications. The installer provides Eclipse and WebSphere Application Server Community Edition out of the box. WebSphere Portlet Factory includes an integrated set of tutorials including creating a Web Application Project, creating a simple portlet, creating data-driven portlets, and a quick start with WAS CE.
2. Users can leverage the expertise of the Portlet Factory community. There is a best in class wiki which provides over 50 downloadable samples and techniques. It is one of the best sources of information that developers should utilize. http://www-10.lotus.com/ldd/pfwiki.nsf
3. Users can collaborate with Portlet Factory experts via the Portlet Factory Forum. http://www.ibm.com/developerworks/forums/forum.jspa?forumID=889
4. WebSphere Portlet Factory 6.1 has increased their platform support to SUSE and Red Hat Enterprise Linux. WPF Designer can also be installed as a plugin into Eclipse 3.3.
5. WebSphere Portlet Factory has increased support to deploy JSR 286 portlets to WebSphere Portal 6.1 and deploy portlets to WAS JSR 168 containers.
6. Comprehensive information of portlet development using WPF can be found in the IBM Redbooks publication: Portal Application Development Using WebSphere Portlet Factory http://www.redbooks.ibm.com/redpieces/abstracts/sg247525.html?Open
7. A 60 day free trial version of WPF is available for download - The package contains everything needed to get started including WASCE and integrated tutorials: http://www.ibm.com/developerworks/downloads/ws/wpf/learn.html

Example implementation

The following sample uses the service provider and service consumer paradigm of WPF. This example demonstrates a simple use case of developing a form, submitting a value to the portal server and fetching values from the server, based on the submitted value. Therefore the main functions of service consumer and provider are as follows :

• Service consumer: Form UI, submitting the form input to the server and displaying the result of the form input on the UI.
• Service provider: Accepting the form input and returning data from the back end based on the form input.

Step 1

Install WPF. The default installation selection will include a supported version of Eclipse. Alternatively, WebSphere Portlet Factory can be installed into a supported version of one of the following IDE's:

• IBM Rational Application Developer
• IBM Rational Software Architect
• IBM Rational Web Developer
• Eclipse (Eclipse SDK versions only)

Prior to installation, you must install IBM WebSphere Portal or one of the supported application servers.

For WPF installation information refer to this infocenter link: http://publib.boulder.ibm.com/infocenter/wpfhelp/v6r1m2/topic/com.bowstreet.designer.doc/install/install.htm

Step 2

Creation of a WPF project. The next step is to create a WPF project that results in the creation of the portlet application. It may have several portlets and is the first step in the formation of a single application war file.

Step 3

Creation of WPF model. The next step is to create a model within the WPF project created above. Models are containers for builders. There are some template models which have typical builders populated to give developers a head start for using the model of a particular template.

Step 4

Builders can be added to a model. Here is the dialog to add a builder call to the current model:



These are some of the builders used in the example:
1. View and Form builder (Service Consumer): Used for calling a backend method and display the result on a page. It also enables creation of input form.
2. Portlet Adapter(Service Consumer): It exposes the model to be used as a portlet.
3. Service Definition (Service Provider): Creates a data service, that can be exposed as a WSDL based web service as well. operation can be added to this service definition.
4. Service Operation (Service Provider): Creates a data operation to be added to the service definition.

The following figure shows a snapshot of the WPF workspace showing the WPF project, models and builders.


1. WPF project - RiverBendSample
2. Consumer model named consumer.model
3. Provider model named data.model
4. Various builders in consumer.model
5. Service consumer builder.
6. Builder editor (This is the wizard like interface to customize builders).

Step 5

Execution of the portlet war on a portal server: The Portlet application can be automatically deployed to a pre-configured portal server. Optionally the portlet application can be extracted as a war file and can be deployed to the server through portal administration. Here is the link to the portlet war.

Below are the screenshots of the demo portlet that is deployed on WebSphere Portal 6.1. The user interface can be customized further. Note that to see the internal structure of the portlet and to customize it, the WPF archive needs to be imported in the WPF. Here is the link to the portlet archive.

Struts Portlet Framework

The Struts Portlet Framework (SPF) is a WebSphere Portal specific framework built on top of the Struts framework contributed by Apache as part of the Jakarta project. Rational tools provide Struts development tools for both Web applications and portlet applications. The primary goal of SPF is to enable Struts programmers to easily create portlets based on Struts conventions without requiring a great deal of knowledge about portlets. Struts is a popular open source project for implementing Web applications using a Model-View-Controller design pattern. Struts have an active development community and continue to evolve. The user community is equally active and many Web applications have been implemented using Struts. The Struts framework can be used to effectively design the Web application. The framework supports both large and small development teams as well as organizations that need to split the development work between specialists (for example, between user interface designers and programmers). The reasons that Struts has become popular for the servlet environment apply for portlets as well. Developers that have worked with Struts in the servlet environment should adapt easily to the Struts Portlet Framework. The packaging of a Struts portlet application is very similar to a Struts application in the servlet environment. However, WebSphere Portal also introduces additional concepts, such as portlet modes, multiple device support, and portlet communication, that might need to be addressed by the Struts application.

Runtime

Struts Portlet Framework provides modified TLD files so that appropriate classes can be referenced with in the Portlet JSP files. The implementation of these classes resides in additional JAR files included in Struts Portlet Framework. In the WebSphere Portal 6.x distribution of the Struts Portlet Framework, all of the TLD files are now contained in the wps.struts.tlds.common.jar file. You can reference these TLDs in the JSP. These taglibs will be added automatically when you use the Web Page wizard in a Struts Portlet Project containing WebSphere Portal Server v6.x Struts Portlet Framework. For adding additional taglibs, you can use the Import Custom menu option to select the TLDs available in the Page Designer’s JSP.

Toolset

The Struts Portlet Framework support in the Rational Software Development Platform simplifies the process of wiring Struts Portlet applications and eliminates the need to manage many of the underlying requirements of Portlet applications.

The Struts Portlet tooling supports development of Portlet applications based on all the JSR 168 API and IBM Portlet API. There are differences in the run-time code included with projects, tag libraries supported, Java class references, and configuration architecture, but unless otherwise noted, these differences are managed by the product tooling.

The following are the list of high level activities involved in developing Struts Portlet applications:

• Create a Struts Portlet Project
• Design the Struts Portlet application, typically using the Web diagram editor.
• Create and modify artifacts that are associated with a Struts Portlet application.

You will use various wizards to generate these artifacts, including Struts Portlet specific JSP and Java files. If you use the Web diagram editor, you can use the standard menu options and drag-and-drop from available palette drawers to create node representations of the artifact that you need. These artifacts are created for you automatically after you enter the name for the node. You will have the option to reference an existing artifact by clicking on the button that is available while you are editing the name.

When you realize a node by putting the name in Edit mode, you can press the button to launch a selection dialog launching the Create new Object wizard. You can also click Enter after you finish editing the name. This will automatically generated the artifact that you need with default options.

• Navigate to related artifacts and view the project in a logical manner, using the project explorer.
• Run and test the Struts Portlet application.
• Set up related preferences, if necessary.
• Validate that the Project is correct.

Rational tools provide a set of wizards that help you to create Struts-Portlet related artifacts. These wizards are the same wizards used to create standard Struts artifacts. Based on the development context, Portlet-specific model options are provided as defaults. However, in some cases you may need to select a model value that specifies Portlet-specific file and code-generation behaviors. To summarize how the wizard behaviors vary between Portlet and non-portlet models, see the below list:

Action Class wizard

• Provides support for the enhanced Struts Portlet Framework action class, Struts Action, that hides details of the Struts action class that do not map well to execution Portal run-time.

Action Mapping wizard

• Supports the Struts Portlet Framework changes added to the Action class wizard.

Struts Configuration Ffile wizard

• Add the required <controller> section that specifies the com.ibm.wps.portlets. struts.WpsRequestProcessor processor class when creating the configuration file (for an IBM API Portlet). For the JSR 168 API or JSR 286 API Portlet the com.ibm.portal.struts.portlet.WpsRequestProcessor processor class is used.

Struts Module wizard

• For an IBM Portlet API, the <init-param > entry that specifies a module is added under the WpsStrutsPortlet servlet entry instead of the ActionServlet servlet entry. For a JSR 168 API Portlet, the module is specified in the Portlet.xml file as part of the Struts Portlet definition.
• The Struts configuration files specified by modules include the required <controller> section.

Developing a Struts Portlet using Struts Portlet Framework

Struts portlet projects share similar functionalities with standard Portlet and Struts projects, but there are some differences that you should be aware of. The Struts portlet project structure and related resources are dictated by the Struts Portlet Framework support provided by WebSphere Portal and included in the Rational Software Delivery Platform.
You can create Struts portlet projects by using the New Portlet Project wizard. By default Struts-type portlet and a Web diagram file will be added in the process of creating the project. The wizard automatically generates Struts portlet configuration files and the necessary updates to the web.xml file, portal.xml file, and adds all of the Struts Portlet Framework tag libraries and JAR files to the project, in the directory structure that is required.

Steps to create a Struts Portlet Project using Rational Software Delivery Platform v7.5 include:

1) Select File -> New -> Project. In the New Project wizard, select Portal -> Portlet Project and then click Next. The New Portlet Project wizard opens.

2) Provide values, as appropriate, for the following fields:

• In the Project name give the name for the new portlet project.
• In the Project content section, the location in the file system where the project will be created. Accept the default workspace, or change the file system location by using Browse.
• In the Target runtime section, select the appropriate WebSphere Portal version for your portlet project. Struts portlet is available for WebSphere Portal ServerV6.1 target run-times. The SPF version will be the one distributed for WebSphere Portal server V6.1. Note: Struts portlets are not supported on the WebSphere Application Server run-times.
• In the EAR Membership section select this check box for Add project to an EAR project if you intend to deploy the Portlet as an EAR module.
• In the EAR project Name section, name of an enterprise application project (EAR project) that the portlet project should be associated with for purposes of deployment. The information used to deploy the portlet project to WebSphere Portal in the test environment will be added in this project. All portlet applications associated with a single EAR project will run on a single session at the test environment. You may separate portlet applications into multiple EAR projects. You should use the same EAR project for other projects that are related.
• In the Portlet settings section select the JSR 168 Portlet for the Portlet API.

To create a portlet with this project, select the Create a portlet checkbox. Specify a name for the portlet and choose Struts for the portlet type.


Click the Show advanced settings button to access facet and run-time options using this wizard.
Note: If you want accept the defaults associated with a portlet project, click Next, then click Finish. If you prefer to customize more project options, click Next.
3) In the Portlet Settings page, define the following:

• In the Content types and modes section, sSpecify the content type and its modes.
• Struts portlets always support html markup. You can add Compact HTML (chtml) or WML 1.3 (wml) markup support to the project. These markups are not currently supported by Rational Software Delivery Platform.
• Select the appropriate check boxes for any additional modes that you want to enable for the portlet. View mode is always provided by default.
• For Code generation options, generate a custom portlet class is not available for Struts, as the tool does not support creating additional subclasses of a Struts portlet.
• Package prefix - a combination of the default package naming preference plus the project name.
• Class prefix - a combination of the portlet-name suffixed by "Portlet".
• Super class - a base class for the portlet class being generated
• For Locale specific information, choose the default, or click Add to create a new locale. Click Next.

4) Update any Struts portlet-specific settings in the Struts Portlet Settings page. By default, the wizard will create resource bundles. The Java package name default is built using the project name that you specified.
5) Click Finish. A new portlet project is created with a Struts portlet definition in web.xml and portlet.xml.



Note: The following sample configuration and deployment descriptor file snippets show representative tagging used within Struts Portlet (JSR 168 API based) projects:

struts-config.xml

The following controller section is added to all struts configuration files:



This is an example of additional tag libraries to be added to the web.xml file:



portlet.xml

This shows a sample Struts portlet added to the portlet.xml file:

Demonstration

The following example uses the same scenario that was used to develop the sample using WPF. Here are the screenshots of the portlet that was developed using RAD 7.5 using the Struts Portlet Framework. The war file can be imported into RAD to see the file structure and the source code. Here is a link to the sample .war file.

Struts 1 x

Struts 1.x is a controller based framework. It is not a standard one. It is recommended for legacy Struts Applications. Struts 1.x do not have the following features:

• Built-in UI component model
• Built-in event model for UI components
• Built-in state management for UI components
• Built-in support of multiple renderers

Struts 2 0

The Strut 2.0 framework is designed for the compilation of the entire development cycle including building, developing and maintaining the whole application. It is very extensible as each class of the framework is based on an Interface and all the base classes are given an extra application and even you can add your own. The basic platform requirements are Servlet API 2.4, JSP API 2.0 and Java 5. Some of the key concepts of Struts 2.0 are described below.

Jsr168Dispatcher

The Controller portlet that handles all the requests to the portlet application. It is Similar to ActionServlet in Struts 1.0 framework but adjusted to a portal environment. The portlet is configured through the portlet.xml descriptor file.

Action

Action is a Combination of ActionForm, Action and Model class. Jsr168Dispatcher will pass the request to configured Action to handle request. This is also referred as a location in framework where you write your business logic.

Interceptors

Interceptors are one of the most powerful features of Struts 2.0 framework. It is similar to Filters in servlet environment, they allow you to execute your code before and after Action. In the Portlet application if you have a common functionality like setting the parameters and the workflow for validation can be implemented as interceptor.

Value stack

The Value Stack is a set of Objects. It is used for carrying data from the Action class to JSP page.
By default the Action instance is pushed on the top of the stack, because of this you can access the action instance object, along with all the HTTP objects (session, request, application, context, and so on).

The following sequence diagram shows the request flow for forwarding Action.



The following sequence diagram shows the request flow for how the forward is happening to a JSP page.



Struts also supporting different view technologies like Freemarker, Velocity, and Java Server Pages. So it will give a flexibility to choose any view technologies where the developers have the skills. It also provides additional features like type conversion and a validation framework.

Spring Framework integration

In Struts many popular optional features of the particular framework are distributed as plug-ins.
Integrating the Spring framework with Struts allows the Actions, Interceptors and Views to be created by Spring. The Objects created by Struts can be auto wired by Spring. It provides two interceptors that auto wire actions if not using the SpringObjectFactory. We can do the auto wiring by adding the StrutsSpringObjectFactory entry in the struts.properties file.



We need to keep the entries as below in the sturts-config.xml and applicationContext.xml file to map the class attribute of <action> tag with the id attribute of the <bean> tag.

Struts-config.xml



applicationContext.xml

Java Server Faces Framework

At its core, JavaServer Faces is a standard Java framework for building user interfaces for Web applications. Its key advantage is that it simplifies the development of the user interface, which is often one of the more difficult and tedious parts of Web application development. Although it is possible to build user interfaces by using foundational Java Web technologies (such as Java servlets and JavaServer Pages) without a comprehensive framework designed for enterprise Web application development, these core technologies can often lead to a variety of development and maintenance problems. JavaServer Faces avoids these problems by offering a robust, "best of breed" framework with well-established development patterns, built upon the experience of many pre-existing Java Web development frameworks.

JavaServer Faces is designed to simplify the development of user interfaces for Java Web applications in the following ways:

• Provides a component-centric, client-independent development approach to building Web user interfaces, thus improving developer productivity and ease of use.
• Simplifies the access and management of application data from the Web user interface.
• Automatically manages the user interface state between multiple requests and multiple clients in a simple and unobtrusive manner.
• Supplies a development framework that is friendly to a diverse developer audience with different skill sets.

Beyond these specifics, JSF offers another important benefit. It takes the best elements found through years of experience in Web application development and combines them into a single, comprehensive, and standard API for building Java Web application user interfaces. Furthermore, it brings unprecedented ease and productivity without sacrificing power and flexibility to J2EE Web application development.

JSF features and benefits

The following list describes the key features and benefits of using JSF for Web application design and development:

• Standards-based Web application framework:
• JSF is a standards-based Web application framework. JavaServer Faces technology is the result of the Java Community process JSR-127 and evolved from Struts. JSF addresses more of the model-view-controller pattern than Struts, in that it more strongly addresses the view or presentation layer though UI components, and addresses the model through managed beans. Although JSF is an emerging technology and is likely become a dominant standard, Struts is still widely used.
• JSF is targeted at Web developers with little knowledge of Java and eliminates much of the hand coding involved in integrating Web applications with back-end systems.
• Event driven architecture:
• JSF provides server-side rich UI components that respond to client events.
• User interface development:
• UI components are de-coupled from their rendering. This allows for other technologies such as WML to be used (for example, mobile devices).
• JSF allows direct binding of user interface (UI) components to model data.
• Developers can use extensive libraries of prebuilt UI components that provide both basic and advanced Web functionality.
• Session and object management:
• JSF manages designated model data objects by handling their initialization, persistence over the request cycle, and cleanup.
• Validation and error feedback:
• JSF allows direct binding of reusable validators to UI components. The framework also provides a queue mechanism to simplify error and message feedback to the application user. These messages can be associated with specific UI components.
• Internationalization:
• JSF provides tools for internationalizing Web applications, including supporting number, currency, time, and date formatting, and externalization of UI strings.

JSF application architecture

The JSF application architecture can be easily extended in a variety of ways to suit the requirements of your particular application. You can develop custom components, renderers, validators, and other JSF objects and register them with the JSF run-time. The focus of this section is to highlight the JSF application architecture depicted in the figure below.

• Faces: JSP pages are built from JSF components, where each component is represented by a server-side class.
• Faces servlet: One servlet (FacesServlet) controls the execution flow.
• Configuration file: An XML file (faces-config.xml) that contains the navigation rules between the JSPs, validators, and managed beans.
• Tag libraries: The JSF components are implemented in tag libraries.
• Validators: Java classes to validate the content of JSF components, for example, to validate user input.
• Managed beans: JavaBeans defined in the configuration file to hold the data from JSF components. Managed beans represent the data model and are passed between business logic and user interface. JSF moves the data between managed beans and user interface components.
• Events: Java code executed in the server for events (for example, a push button). Event handling is used to pass managed beans to business logic.

Rational Application Developer allows developers to easily use JSF components for portlet development. It enables rapid application development and standards-based code generation. The following is a list of JSF features that you can use to develop portlets in Rational Application developer:

• Visual page layout of JSF components using Page Designer
• Web Diagram Editor for defining the flow of a JSF application
• Built-in Component Property editor
• Built-in tools to simplify and automate event handling
• Page navigation defined declaratively
• Automatic code generation for data validation, formatting, and CRUD functions for data access
• Multiple faces configuration file support for different purposes, such as navigation and managed beans
• Relational database support
• EJB support
• Web services support
• Data abstraction objects for easy data connectivity using JPA
• Data objects can be bound easily to user interface components
• Support for runtime page templates with Tiles
• Creating Portlet project with JSF support
• Customizable property templates for data types (such as Date)
• 3rd party library integration with customizable palette
• Custom component library building
• Integration with JPA to easily create Web applications with persistence

Rational Application Developer has additional rich and powerful components for JSF. These components include:

• Menu Bar (displays a menu bar of buttons and/or hyperlinks)
• Panel - Dialog (creates a block panel that behaves like a modal or modeless dialog box)
• Panel - Form Box (creates a block panel that contains a header area and one or more form label/field pairs)
• Panel - Section (creates a block panel that has a header that can be used to expand/collapse the display of the panel's content)
• Select - Color (displays a drop-down combo box from which the user chooses a color)
• Select - Calendar (adds small calendar to the page)
• Progress Bar (displays an animated progress bar)
• Link - Request (generates an HTML link with a URL that can pass parameters and navigate to a page by passing a string to JSF navigation rules)
• Data Iterator (iterates over rows of model data allowing values from each row to be used in child components).

One of the most elegant design aspects of the JavaServer Faces specification is that it completely relies on existing J2EE Web technology at its foundation. This means that a JSF application is really just a standard J2EE Web application with a few specific configurations. These are

• An entry in the Web application's web.xml file, that enables the Faces Controller servlet when a certain URL pattern is specified, such as /faces/*.
• A JSF configuration file, faces-config.xml, that allows for configuration of all elements of a JSF application. This file is treated as a peer of the web.xml file and is usually located in the Web application's WEB-INF/ directory.
• A WEB-INF directory with the following Java libraries:
• The actual JSF libraries: jsf-api.jar and jsf-impl.jar.
• Additional Apache "Commons" libraries: commons-beanutils.jar, commons-collections.jar, commons-digester.jar, and commons-logging.jar. Although not part of the core JSF technology, these libraries are relied upon by JSF and are thus required to be in the application's WEB-INF/lib directory.
• JSTL jar files: jstl.jar and standard.jar.

Once a portlet is properly configured for JSF, you can construct the View using, but not limited to, JavaServer Pages. Building JSF applications with JavaServer Pages is done by using JSF-enabled JSP tag libraries. For a JSP page to be JSF-enabled, it must first contain JSF JSP taglib directives provided by a JSF implementation. The following taglib directives are for the Core and HTML libraries from Sun's reference implementation:



In the body of the portlet JSP, you must then add a <f:view> tag. This will become the base UI component of what will become a component tree in memory on the server when the page is requested for viewing. If the page processes form input, as opposed to just displaying output, you'll need to add a <h:form> tag as a child of the <f:view> tag. Subsequent children tags of the <h:form> tag will become the form elements such as <h:inputText>, that renders an input field, and <h:commandButton>, that renders a form submission button.

To understand how JavaServer Faces creates and manages a server-side tree of components in memory that directly corresponds to the components included in a page, consider the following JSF-enabled portlet JSP page:



When a JSF-enabled JSP page is requested or when the user invokes an action on a UI component in a JSF-enabled JSP page, it is important to understand the exact sequence of events that occur on the server in order to fulfill the request to view or submit a JSF page. The sequence of events that are triggered during requests to JSF pages is known as the JSF request processing lifecycle or sometimes simply as the JSF lifecycle. This is shown in below figure.



Like Struts, JSF follows a Model-View-Controller design paradigm. Recall that an MVC application is segmented into three distinct application components:

• The Model, that contains the business logic or non-UI code.
• The View, that is all the code necessary to present a UI to the user.
• The Controller, that is a front-end agent that directly handles the user's requests and dispatches the appropriate view.

These three elements, also depicted in the figure below, combine to produce an architecture that yields distinct, separately maintainable code.



The JSF Navigation Model is an elegant solution for keeping track of all navigations in the entire JSF application. This greatly improves the manageability of the application because it is easier to maintain a central navigation model rather than having to update multiple page links in multiple pages. The central location of the navigation model in an XML file is also very "tool friendly" in that Rational Application Developer offers visual ways to easily define JSF navigation models.

The navigation model is based on a set of "navigation rules," that define a "from" page (from-view-id) and one or many "to" navigation cases. Each navigation case has an associated "outcome" and "to" page (to-view-id). For example, to navigate from page1 to page2 when the outcome "success" is encountered, the following rule is specified in the faces-config.xml:



A a second navigation case can be defined for a "failure" outcome that will route the viewer to portletPage3.jsp.

JSF advantages and disadvantages

Advantgaes and disadvantgaes are sometimes based on the perspective of the individual or the functional requirements. From a portlet development perspective the main advantages are:

• JSF offers a clean separation between behavior and presentation.
• The separation of logic from presentation also allows each member of a portlet development team to focus on his or her piece of the development process, and it provides a simple programming model to link the pieces.
• It removes the whole notion of having to process incoming Web requests. Instead, the Web developer can rely on the JSF lifecycle to handle back-end plumbing automatically and can use the JSF event model to jump in and do custom processing only when needed.
• Code reusability is high.
• It is easy to upgrade.
• It has very extensible component infrastructure.
• Developing complex portlets including navigation, complex forms, validations is very easy.
• It has embedded plugin set in Rational Application Developer.

Disadvantages are:

• It adds overhead to developing simple portlets.
• The learning phase is not short. You need to create your own Ajax based components or you can use open source JSF based frameworks like icefaces.

Spring 2 0

Spring also supports JSR-168 and JSR-286 API Portlet development similarly servlet-based Web development. The Portlet MVC framework is a mirror image of the Web MVC framework, and also uses the same view abstractions and integration technology. Most other portlet MVC frameworks try to hide the two phases from the developer and make it look much like traditional servlet development. It will make you to 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.

This framework is designed around a DispatcherPortlet that dispatches requests to handlers, with configurable handler mappings and view resolution, just as the DispatcherServlet in the web framework does. The Portlet MVC does not support the local resolution and theme resolution. These two areas are in the scope of the portal/portlet-container and are not appropriate at the Spring level. Regardless, all mechanisms in Spring that depend on the locale will still function properly because DispatcherPortlet exposes the current locale in the same way as DispatcherServlet.

Model

Spring Portlet MVC supports beans whose lifecycle is scoped to the current HTTP request or HTTP Session. This is not a specific feature of Spring Portlet MVC itself, but rather of the WebApplicationContext container(s) that Spring Portlet MVC uses.

View

All the view rendering capabilities of the servlet framework are used directly via a special bridge servlet named ViewRendererServlet. By using this servlet, the portlet request is converted into a servlet request and the view can be rendered using the entire normal servlet infrastructure. This means all the existing renderers, such as JSP, can still be used within the portlet.

Controller

The default handler is a very simple Controller interface; it offers just these two methods:

• void handleActionRequest(request, response)
• ModelAndView handleRenderRequest(request, response)

The framework also includes most of the same controller implementation hierarchy, such as AbstractController, SimpleFormController, and so on. Apart from these the Data binding, command object usage, model handling, and view resolution are all the same as in the servlet framework.

The DispatcherPortlet

This is a controller portlet that handles all requests to the portlet application similar to ActionPortlet or ActionServlet in the Struts framework. Portlet MVC framework designed around a portlet that dispatches requests to controllers and offers other functionality facilitating the development of portlet applications. The DispatcherPortlet, does more than just that. This controller portlet is completely integrated with the Spring ApplicationContext and allows using every other features of the Spring.

To process the requests and render the appropriate views DispatcherPortlet using few special beans. The Spring framework includes these beans and these can be configured in the WebApplicationContext, just like any other bean would be configured. During the process of the request exceptions might be thrown. These exceptions can be picked up by any of the handler exception resolvers that are declared in the WebApplicationContext. So, by using these exception resolvers we can define custom behavior in case such exceptions get thrown. We can also customize the Spring's DispatcherPortlet by adding context parameters in the portlet.xml file or portlet init-parameters.

The ViewRendererServlet

In Portlet MVC the rendering process is a quite more complex than Web MVC. You must convert the PortletRequest and PortletResponse to HttpServletRequest and HttpServletResponse and then call the render method of the View in order to reuse all the view technologies from Spring Web MVC. To achieve this, DispatcherPortlet uses a special servlet called ViewRendererServlet.

Controllers

This is similer to the Action class in Struts. The action request and the render request are the two methods that handle the two phases of a portlet request by Portlet Controller interface. 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. Spring Portlet MVC provides a several controllers like ParameterizableViewController, SimpleFormController and AbstractWizardController which already contains lot of the functionality you might need.

Handler Mappings

The Handler Mapping will decide which Controller needs to be called. There are several out-of-the-box implementation available for this. We can map the incoming portlet requests to appropriate handlers with the help of handler mapping. A Handler can be any Object that can handle portlet requests. The Controllers are an example of Handlers, and they are the default handlers mapping. The DispatcherPortlet will hand it over the request to the handler mapping to allow inspect the request and come up with an appropriate HandlerExecutionChain. After that DispatcherPortlet will execute the handler and interceptors in the chain. The concept of configurable handler mappings that can optionally contain interceptors will be very powerful.

The most commonly used handler mapping in Spring Portlet MVC are PortletModeHandlerMapping, ParameterHandlerMapping and PortletModeParameterHandlerMapping.

ViewResolver

The Spring Portlet MVC uses the same ViewResolver implementations. If the portal expect the result of rendering the portlet to be a HTML fragment then using JSP, Freemarker, Velocity and XSLT make sense. But the views that return other document type will not make sense in the portal context. And you can not use a relative URL to access the other resources because in portlet you have no idea what the current URL looks like.

The example sequence diagram below shows how the Render works in Spring Portlet MVC



The followng sequence diagram shows how the Action works in Spring Portlet MVC



Developing a Spring Portlet using Spring MVC framework
You can create Spring Portlet projects by using the New Portlet Project wizard in Rational Software Delivery Platform. By default Rational Software Delivery Platform will not provide any specific wizard to develop the Spring Portlets, so you need to create an empty JSR 286 Portlet and on top that you need to customize the basic project structure by updating the deployment descriptor files and adding the tag libraries, JAR files to the project.

Steps to create a Spring Portlet Project using Rational Software Delivery Platform v7.5 include:

1.      Open the Rational Software Delivery Platform v7.5 and create a new Portlet Project as per the screen shot below.

      

2.      Create an Empty JSR 286 Portlet Project.

    

    Default directory structure

     

3.      You need to modify the directory structure as like the below screen shot. 

     

   You can use the resources which is available from the attachment section.

4.       Update the web.xml file with below content.

 

 
5.      Update the portlet.xml file with below content.

 

 

Demonstration 

Here are the screenshots of the Spring Portlet that was developed using Rational Software Delivery Platform v7.5. The war file can be downloaded here can be imported into Rational Software Delivery Platform v7.5 to see the file structure and the source code.

 
 

For more information see the IBM developerWorks article: Developing a Spring Portlet MVC Framework application for use inside IBM WebSphere Portal (http://www.ibm.com/developerworks/websphere/library/techarticles/0802_patil-pt1/0802_patil-pt1.html)

Adobe Flex

JSR-168 Portlet has support for using Adobe Flex. Similarly it will also support the JSR-286 API with some additional features like support for asynchronous requests, public render parameters and events. Adobe Flex is an Open Source UI framework that allows creating SWF files using XML markup and Action Script. We can also integrate the Flex controls in the Themes and Skins of WebSphere Portal. Java developers will easily become familiar with Flex Builder. The Flex Builder is the development environment used for this. The SWF file generated by the mxmlc compiler will be rendered on the client side by the Flash Player plug-in that is available in most web browsers.

To embed the Flex Control in to the application, we have to use data exchange interfaces such as Ajax bridges, HTTP services and SOAP services.

For more information and an example of using Adobe Flex, see the following link: Using Adobe Flex in JSR-286 Portlets (http://www-10.lotus.com/ldd/portalwiki.nsf/dx/17.09.2008050832WEBCQV.htm)

Deciding on the right framework

The frameworks described above are designed to let projects quickly implement the business logic of an application without worrying about the underlying plumbing of the application. All three provide similar functionality although they differ in the implementation. Both Jade and Struts are application server-independent, while WebSphere Portal simply supports WebSphere Application Server.

For a useful article on choosing the right framework, see the IBM developerWorks article: Modeling WebSphere Portal Portlets with UML -- Part 2 (http://www.ibm.com/developerworks/websphere/library/techarticles/0211_bernal/bernal.html)

---

Table of Contents | Previous Page | Next Page