This article details Java.
TM Java
The TM Standardization Request for the Java Portlet specification (hereinafter referred to as JSR 168) and IBM WEBSPHERE Portal Version 5.0 supports similarities and differences between IBM portlet APIs. Some basic concepts and features of JSR 168 are explained, and they compare them with the IBM Portlet API and provide an example portlet for each of the two portlet programming interfaces. This article is preparing for portlet developers and Portal architects for basic knowledge of Java programming, servlet, or portlets and portal.
Introduction As more and more business portals, different vendors have created a variety of APIs (called portlets) for Portal components. There are a variety of incompatible interfaces that produce problems between application providers, Portal consumers, and Portal server vendors. Java Portlet Specifications (JSR 168) defined by Java Community Process (JSR 168) provide interoperability between portlets and portals. It will solve these problems in time.
The purpose of this document is to compare the JSR 168 and WebSphere Portal V5.0 Portlet API, and some examples have been given.
Important: In order to provide customers and partners with a convenient porting window, the next version of WebSphere Portal will still support the IBM Portlet API.
JSR 168 Introduction Java Standardization Request 168 (JSR 168) defines a portlet specification, including contracts between portlet containers and portlets. JSR 168 is defined by Java Community Process (JCP). JSR 168 is commonly led by IBM and Sun, and has a large Expect group to help create the final version currently available. This expert group consists of Apache Software Foundation, Art Technology Group Inc. (ATG), BEA, BOEING, BORLAND, CITRIX SYSTEMS, Fujitsu, Hitachi, IBM, Novell, Oracle, SAP, SAS INSTIS, Sun, Sybase, Tibco, and Vignette. More information about this JSR can be found on http://jcp.org/en/jsr/detail?id=168.
Important: The information provided in this analysis does not assume any responsibility for the guarantee of the nature. This analysis is intended to provide readers with an indicative tool.
JSR 168 defines that this part provides basic JSR 168 definitions to help you understand how JSR 168 integrates into the entire Portal architecture.
Portal and Portlet container portal is a web application that provides personalization of different sources, single-point login content collection, and hosts representation of different backend systems.
The main task of Portal is to set different applications to a page, the appearance of this page is Portal users. Portal also has complex personalized features that provide users with custom content. Portal page can have different portlet sets to create content for different users.
Figure 1 shows the portal architecture, such as a portal that serves service by WebSphere Portal. The client request is processed by the Portal web application, which retrieves the Portlet on the current page for the current user. The Portal web application then calls the portlet container for each portlet to retrieve its content via the Container Invoker API. The portlet container calls the portlet via the portlet API. Container Provider Service Provider Interface (SPI) allows the portl to retrieve information through Portal. Figure 1. Basic Portal architecture
The portlet container runs the portlet, providing them with the required runtime environment and manages their life cycle. It provides persistent storage for the portlet preference item, which enables custom output to different users.
Portal Pages and Portlet FIG. 2 show the basic Portal page components. Portal page represents a complete tag document and aggregates several portlet windows; that is, it combines different application user interface to a unified representation. Portal page enables users to verify their identity to Portal via the login dialog box to access personalized Portal views. Most Portal pages include some navigation mechanisms to allow users to navigate to other Portal pages.
Figure 2: Portal page
The portlet window includes:
The title bar, the title of the portlet, including buttons (such as maximizing or minimizing portlet) for changing portlets, buttons for changing the mode of the portlet (such as display help or editing a predefined portlet setting) The content generated by the portlet (also known as a tag).
Figure 3 shows a portlet window on a different browser. As you can see, the portlet generated by the portlet is not limited to HTML, but can be any tag.
Figure 3: Portlet displayed in the HTML browser (top) and WML browser (bottom)
Portlet lifecycle basic portlet life cycle must:
Initialization, use the initialization class to initialize the portlet and put it in the service. Processing requests to handle different types of action and present content. Complete, remove the portlet using the destruction class.
The portlet receives the request based on the user interaction with the portlet or portal page. Request processing is divided into two phases:
Action Process If the user clicks on the link on the portlet, the action will be triggered. The action process must end before any portlet presentation on the page. In the action phase, the portlet can change the status of the portlet. The presentation content is in the presentation phase, and the portlet generates the mark to be sent back to the client. Rendering should not change any state. It allows a page to re-refresh without changing the status of the portlet. The rendering of all portlets on a page can be executed in parallel.
Figure 4 depicts the request stream from the client to the portlet, and showing the action and presentation phase in more detail. In this example, Portlet A received an action. After this action is executed, all portlets of all portlets on the page (A, B, C) are called.
Figure 4. Request stream from the client to portlet
Portlet mode portlet performs different tasks and creates content according to their current functions. Portlet mode indicates when portlet will perform a function. Portlet mode Specifies which task that the portlet should do and what kind of content should be generated. When calling the portlet, the portlet container provides the mode of the current request for the portlet. When processing actions, the portlet can be programmetively changing their portlet mode. JSR 168 defines three types of portlet mode:
Must support mode (Semantics)
Edit
Display one or more views to let users customize personalized portlet settings.help
Help
Display help view.
View
Show portlet output.
Alternative customer mode
About
Display the purpose, source, version, and other information of the portlet.
Config
Display one or more configuration views allows the admin configured portlet settings for all users.
Edit_Defaults
Set the default value of the modified preferences, these preferions can usually change in the Edit screen.
Preview
Presenting an output without a rear end connection or a user-specific data.
Display views suitable for printing.
PORTAL manufacturers' models These modes are only available for specific vendors Portal.
Window Status Window Status is an indicator that is assigned to portal page space generated by the portlet. The portlet container provides the current window state to the portlet, while the portlet determines how much information it should present through the window status. However, when processing actions, the portlet can also be configured to change their window state.
JSR 168 defines the following window status:
Normal
Portlets are shared with other portlets, which should consider this state when producing its output.
Maximized
The window has a more realistic state than the normal window state to provide its output.
Minimized
Portlets should only present the smallest output or no output.
In addition to these window states, JSR 168 allows Portal to define a custom window state.
Data mode JSR 168 defines different mechanisms for portlets to access transient data and persistence data.
Portlets can set and get transient data within the following scope:
Request request has additional data, such as request parameters and properties, similar to servlet. The request can contain some features to allow expansion; or the client header field (vice versa) from Portal to the portlet. The session portlet can store data in a session with global scope to allow other components in the web application to access these data; you can also store data in the portlet scope, this scope is the portlet private. The context portlet can store the data in the Web application context, similar to servlet.
Portlets can access persistence data within these scope:
Each portletportlet can store configuration and personal data in the portlet reference to allow portlet to create personalized output. Portlets can define that users to change those data (such as stock quotes) in editing mode, and which data can only be configured by administrators (such as stock quotation servers). Each user portlet can read the user profile to adjust its output for the user (for example, the weather conditions of the city where the user is located).
Portlet application All resources, portlets, and configuration descriptors are packaged together into a web application profile (WAR). There are two configuration descriptors:
All web application resources that are not portlets must be specified in the Web.xml configuration descriptor. All portlets and portlets related settings must be specified in the portlet.xmldeployment descriptor.
Compare JSR 168 and IBM Portlet API propolidly compared the JSR 168 Portlet API and IBM Portlet API. First explain some similar concepts, then explain the differences between the two.
Similar Points The following concepts are very similar in JSR 168 and IBM Portlet APIs.
Features Similar Points Different Point Portlet modes support basic portlet modes: Edit, Help, and View. This configuration mode is optional in JSR 168. IBM Portlet API does not support other optional JSR 168 modes (About, Edit_Defaults, Preview, Print). Window status supports the following window status: Maximized, Normal, and MinImized. SOLO window status is only IBM Portlet API support. Portlet lifecycle life cycle is the same: initialization, processing request, destruction. No request processing request processing is divided into a presented phase of the action phase and the generating tag. Both no URL encoding supports creating a URL that points to the portlet or resource. Did not include servlet / jspservlets and JSPs can be included in the portlet. There is no portlet session portlet to store transient information, which should be in the request in the session. There is no portlet application packaging through additional deployment descriptors (named portlet.xml) to package the portlet application into a WAR file. Portlet.xml format is different. Based time-based cache portlets can support caches based on expiration time. API uses different mechanisms to achieve this. The IBM Portlet API uses a polling mechanism, in which portal query portLet to obtain the valid time of the tag, and in JSR 168, the portlet can attach the expiration time on each tag created. Sharing cached entries between users can only be possible in the IBM Portlet API.
Different Point JSR 168 and IBM Portlet API have different aspects.
Features IBM Portlet APIJSR 168Portlet application entity allows you to define abstract portlet applications and their different instances by deploying descriptors as specific portlet applications. This allows reusing the settings of the abstract portlet application, while only rewriting the only part of each specific portlet application. The deployment descriptor is tight after the Web.xml deployment descriptor, it defines an application and its portlet definition. Each portlet configuration in the portlet entity web deployment descriptor has a portlet object instance. Depending on the Flyweight mode, there are many portletSettingS objects to parameterize the same portlet object (based on each request). Changes in PortletSettings are applied to all portlet instances in this specific portlet. The user can also specifically portlet, which is rendered by using a custom output portdata. PortletSettings and PortletData are merged into a object called PortletPreferences. Request / Response Object Portlet The request / response object received in the rendering call is the same as the action call received. In JSR 168, there are two different objects.
JSR 168 unique features These items are only available for JSR 168.
Feature Description Rendering Parameter Rendering Parameters Allow portlets to store its navigation status. The presentation parameters remain unchanged in the subsequent presentation request, but only changes when the portlet has received a new action. This enables bookmark function and solves the back button problem after the browser. Global HTTPSession Scope Domain Portlets can store data with portlet visibility, but also data with visibility of the entire web application. Redirect Portlets can redirect other web resources in the action phase. IBM portlet API unique features The following concepts are only available for IBM Portlet API.
Feature Description Event Event can be sent between PPortlets. Additional lifecycle listeners In addition to action and presence, lifecycle listeners (such as homepage) do not apply to the first version of JSR 168. The portlet menu allows the portlet to provide content to the menu bar to make navigation easier with the Portal page. The cache based on invalid time allows the portlet to explicitly invalidate the content of the cache.
Example Portlet This section shows a HelloWorld portlet, which has its implementation in each of the two APIs. Its main difference is highlighted in the second portlet.
These two sample portlets achieve the same functionality:
The JSP is used to present the output according to the user-specific data-defined portlet output processing action to allow the user to change these actions.
This example shows a personalized HelloWorld portlet. It identifies the user by name, and allows the user to enter the edit mode to set a new name. In the action method (called ActionPerformed in the IBM Portlet API, the portlet persisters stores the new user name entered by the portlet persistence.
Listing 1. IBM portlet API sample portlet
First take a look at the portlet implemented through the IBM Portlet API.
Public Class HelloWorld Extends AbstractPortlet IMPLEments ActionListener
{
Public Void DoView (PortletRequest Request, PortletResponse Response)
Throws portletException, IOException
{
// Get the user's name to display from Persistent Storage
PortletData portletdata = request.getdata ();
String stringtodisplay = (string) portletdata.getattribute ("UserName");
IF (StringTodisplay == Null) {
Stringtodisplay = defaultstring; // set default string
}
// add the display string to the portlet request to make it it
// Accessible by the view jsp
Request.setattribute ("UserName", StringTodisplay;
// Get a context for the capital session for invoking the jsp
PortletContext Context = getPortletConfig (). GetContext ();
Context.include (Viewjsp, Request, Response);
}
Public void doedit (PortletRequest portletRequest,
PortletResponse PortletResponse)
Throws portletException, IOException
{
// Create The Cancel Return Uri for the Edit Page
Portleturi Canceluri = PortletResponse.createreTurnURI ();
// Preserve the Cancel Uri in The Request to make it
// Accessible by the Edit JSP
PortletRequest.setttribute ("canceluri", ca Zanteuri.tostring ());
// Create the Save Uri for the Edit Page
Portleturi saveuri = portletResponse.createreeturnuri ();
// for the "save" Button The Return Uri Must Include The "Save" Action
// so the action listener for this portlet will be invoked
SimpleActionHelper.
AddSimpleportletAction (getPortletConfig (). getContext (), Saveuri, "Save");
// Preserve the Save Uri in The Request to make it it accessible by
// the Edit JSP
PortletRequest.setttribute ("Saveuri", Saveuri.toTString ());
// Get the user's name to display from Persistent Storage
String stringtodisplay = (string)
PortletRequest.getdata (). GetAttribute ("UserName");
IF (StringTodisplay == Null) {
Stringtodisplay = defaultstring; // None Found, Set Default String
}
// add the display string to the request to make it it accessible by the Request To Make It Accessible by THE
// Edit JSP as an inital value of the input field on the Edit Form
PortletRequest.setttribute ("UserName", StringTodisplay;
// Get a context for the capital session for invoking the jsp
PortletContext Context = getPortletConfig (). GetContext ();
Context.includ (EditJSP, PortletRequest, PortletResponse);
}
Public void actionPerformed (ACTIONEvent Event) {
String action =
SimpleActionHelper.getActionString (GetPortletConfig (). GetContext (),
Event);
HelloWorld Helloportlet = (HelloWorld) Event.getPortlet (); portletlog log = helloportlet.getportletlog ();
// if this is a save action, the see if the user specified a name
IF (Action! = null) {
IF (Action.equals ("Save")) {
PortletRequest Request = event.getRequest ();
Portletdata portdata = request.getdata ();
String Username = Request.getParameter ("UserName");
Try {
// save the name specified by the user
IF (username! = NULL) {
PortData.setttribute ("UserName", UserName;
Portdata.store ();
}
} catch (accessdeniedException ad) {
} catch (ioexception ie) {
Log.Error ("COULDN '' '' t user date to
");");
}
}
}
}
}
Listing 2. JSR example portlet
Now, look at the same portlet that has been modified to use JSR 168. Changed text is marked with bold.
Public Class HelloWorld Extends GenericPortlet
{
Public void doView (RenderRequest Request, RenderResponse Response)
Throws portletException, IOException
{
// Get the user's name to display from Persistent Storage
Portletpreferences portletdata = request.getpReference ();
String stringtodisplay = (string) PortletData.getValue ("UserName", DefaultString;
// add the display string to the portlet request to make it it
// Accessible by the view jsp
Request.setattribute ("UserName", StringTodisplay;
// Get a context for the capital session for invoking the jsp
PortletRequestDispatcher rd = getPortletContext (). GetRequestDispatcher (viewjsp);
Rd.includ (Request, Response);
}
Public void doedit (RenderRequest portletRequest,
RenderResponse PortletResponse)
Throws portletException, IOException
{
// Create The Cancel Uri for the Edit Page
PortletURL Canceluri = PortletResponse.createActionURL (); // Preserve The Cancel Uri in The Request To Make IT
// Accessible by the Edit JSP
PortletRequest.setttribute ("canceluri", ca Zanteuri.tostring ());
// Create the Save Uri for the Edit Page
PortletURL Saveuri = PortletResponse.createActionURL ();
// for the "save" Button The Return Uri Must Include The "Save" Action
// so the action listener for this portlet will be invoked
Saveuri.SetParameter ("Action", "Save");
// Preserve the Save Uri in The Request to make it it accessible by
// the Edit JSP
PortletRequest.setttribute ("Saveuri", Saveuri.toTString ());
// Get the user's name to display from Persistent Storage
String stringtodisplay = portletRequest.getPReference (). GetValue ("Username",
Defaultstring;
// add the display string to the request to make it it accessible by The Edit JSP
// as an inital value of the input field on the Edit Form
PortletRequest.setttribute ("UserName", StringTodisplay;
// Get a context for the capital session for invoking the jsp
PortletRequestDispatcher rd = getportletContext (). GetRequestDispatcher (EditJSP);
Rd.include (portletRequest, portletResponse);
}
Public Void ProcessAction (ActionRequest Request, ActionResponse Response)
Throws portletException, IOException
{
String action = request.getParameter ("action");
// if this is a save action, the see if the user specified a name
IF (Action! = null) {
IF (Action.equals ("Save")) {
PortletPreference.Getdata = Request.getPReference ();
String Username = Request.getParameter ("UserName");
// save the name specified by the user
IF (username! = null) {portdata.setttribute ("Username", username;
Portdata.store ();
}
}
The main difference between the IBM portlet API version of the portlet is:
Request a splitter uses a slightly different request with the JSR 168 and the IBM Portlet API. JSR 168 uses the same mechanism to obtain a request splitter from the context as a parameter of the Servlet API. JSR 168 uses the same mechanism to obtain the request splitter from the context with the path to serve as a parameter as the servlet API. Persistent PORTLET Data JSR 168 Persistent Data PortletPreference has an API similar to JDK 1.4 Preferences, and allows the default value to be specified for the GET method. No longer need to check the zero return value and explicitly set the code for default. JSR 168 only allows String and String arrays as the value of the preference; IBM Portlet API can support any object. The action processing in JSR 168 is simplified and does not require a specific action object being created. Automatically create action URLs trigger a call processAction method.
Conclusion Due to the definition of JSR 168, it ultimately has a standard portlet API, which provides a programming portlet of Portal vendors, and allows you to run the same portlet on different portals.
The concept of JSR 168 is closely related to the IBM Portlet API. Compared with the IBM Portlet API, the functionality of JSR 168 is limited because it is the first version of the portlet specification. Developers who are familiar with IBM Portlet API should learn to use JSR 168 API without difficulty.
Reference
Java Portlet Specification JSR 168 Java Community Process Web Services for Remote Portlets Specification Portlet API Javadoc for WebSphere Portal 5.0
