summary
In the second part of the portlet family of Stefan Hepper and Stephan Hesmer, the author transfers the pen point from the Basic summary of the Portlet API to the details of the portlet API (Ri Reference Implementation is also a detail description of PLUTO). The author also provides a series of portlet instances to illustrate how to extend the Standle of the Portlet API.
Enterprise Portal Providers uses pluggable user interface components (portlets) to provide a representation layer. Unfortunately, the previous providers only defined their own Portlet API, which is incompatible throughout the industry. In order to standardize the entire industry process, Java group released Java specification requirements (JSR) 168: Portlet specification.
The first part of this series of articles describes the details of JSP 168. The second part focuses on the reference implementation (RI) of the Portlet API, which is PLUTO. Also provided an instance of a portlet, the reader can learn from this instance.
Article Section 1 describes the architecture of RI, including the detachable concept of portlet containers and how to reuse portlet containers in other projects. The second section describes the installation and use of RI, and how to quickly configure the portlet. The article also includes a gradual in-depth example.
Note: You can download the original code through the resource link after the article.
PLUTO architecture
Let's take a look at the PLUTO architecture and some basic concepts. Let's briefly explain the PORTAL's reference implementation and the location of the portlet container in the entire Portal architecture. Next we study the architecture of Pluto in terms of detail. Finally, let's take a look at the portlet container: Portlet Expand.
About Portal
Pluto is generally used to demonstrate how the portlet API works and provides a developer's instance platform that test portlets. However, if there is no driver to run and test the portlet container a bit troublesome. The simple portal component of Pluto is just architectural in Portlet containers, which only meets the basic requirements of JSR 168. (In contrast, Apache's open source project JetSpeed is more professional. Jetspeed will focus on Portal itself instead of portlet containers, and more considering the needs of other groups.)
Figure 1 depicts the basic architecture of Portal. Portal's network application handles client requests, gets the portlets from the user's current page, then call the portlet container to get the content of each portlet. Portal uses the invoker API of the portlet container to access the portlet container, from Portal, the main interface of the portlet container is to support the request-based method call portlets. The container user wants to obtain the relevant information of Portal, you must implement the Callback interface of the PROVIDER SPI (Service Provider Interface) of the Portlet container. Finally, the portlet container calls all portlets via the Portlet API.
Figure 1: Structure of a simple portal in Pluto
Portlet container
The portlet container is the operating environment of the portlet, as well as each portal composition core. It requires information about Portal itself, and it must reuse itself. Therefore, Portlet containers and other portal components are completely separated. That is to say, you can embed the independent portlet container in any portal, as long as you meet the conditions of the portlet container, all SPIs are implemented.
The Invoker API of the portlet container, or the entry point, played the role of the main call interface of the Portlet container. The Invoker API of the portlet container combines the living cycle of the portlet container, and the request (INITPAGE (), PerformTitle (), portletService (), etc.). Because the portlet container last calls the portlet's method name is a bit similar to the main portlet interface of the Portlet API, it is different to pass the portlet definition. It is because this additional portlet definition, the portlet container can call the portlet correctly. In addition to accessing the portlet container with an API, Portal must extend the SPI defined by the portlet container. Therefore, Ri introduces a container service: the detachable component registered in the container provides an underlying function and can be expanded. Ri contains self-built services in some containers (the first four must be implemented when running the portlet container, the last one is optional):
l Information provider: Provide portal and portal framework for portal and portal frameworks. Get information and store Portal information through this interface. This information includes the URL, Portlet context, portlet mode, and window status control in the navigation bar.
l Factory Manager: Defining how to get a specific implementation through the factory method. (A standard portal should already have an implementation.)
l Log Service: Defines a log tool (a standard portal should already have an implementation).
l Configuration Service: Define how to get configured parameters (a standard portal should already have an implementation).
l Property Manager (Optional): The implementation of the Properties Manager interface allows processing of the properties defined in the JSR168 specification.
Strictly speaking, the portlet object model is also part of the SPI, but it has a special position in SPI. The portlet object model processes all Potlet objects, which consists of a set of interfaces that are intertwined. Therefore, he cannot be considered by separating him and the container service.
Figure 2: Portlet container structure
Portlet deployment
The Portlet container architecture is above the servlet container and enhances its functionality. In order to implement it, the portlet container joins the original servlet in the WAR file of each portlet application, which we have described in Figure 3 3. When deploying the portlet component, first get the original WAR file, then join a new or modified the original Web.xml, and join a servlet as a call point to package each portlet. After that, the portlet deployment (? This original is that the portlet deployment passes the model "will pass a modified WAR file to the application server, deploy it to the application server system. During the calling process of the portlet, the portlet container calls the Added servlet as the entry point for the WAR file deploying the portlet.
Figure 3: Deployment of portlet in ri
PLUTO and WSRP standard
As described in the first part, JSR 168 is closely combined with the remote portlet network service (the Web Services for Remote Portlets (WSRP)) standard. These two standards formed almost simultaneously released an open source implementation, realizing the necessary functions in their respective specifications. As a common goal, two standard efforts can cooperate together. Now, the portlet container can run the WSRP Portlet. PLUTO can run multiple portlet containers in a portal. Thus, Pluto's portlet container can be initialized multiple times. More importantly, it can be initialized in different ways. Each portlet container can use the SPI different implementation.
Ri installation
You will find that Pluto's installation process is very simple. Perform install commands, install.bat or install.sh under the build directory / build. Next, the installer will prompt you to specify the Tomcat installation directory. (Note: The file separator under MS Windows is not a backslash.)
After this, the installation process creates ri and all portlets, install portlets to the specified Tomcat directory. After the installation is complete, check the document to determine all the necessary manual settings.
You can now start Tomcat, access RI through http: // localhost: 8080 / pluto / portal.
It is so simple!
How to deploy portlet
Deploy portlets in PLUTO and its installation. Just remember that you must first install PLUTO, it sets the preorderun.properties correctly. This is necessary for the deployment process. Go to the build directory under the command prompt, enter the command deployportlet.bat, use the portlet war file to do parameters, such as:
Deployportlet.bat c: /pluto/portlets/bookmark_04/driver/bookmark_04.war
Portlet instance
Let's take a picture of a portlet, Bookmark. It fully utilizes the Portlet API and clarifies the concept we have learned. We started with a simple example, we extend this Bookmark portlet by step by step, and finally we will almost all the portlet API, make it a senior portlet.
Bookmark portlet: version
The first Bookmark portlet uses some of the features in the Portlet API:
l Portlet API interface The portlet API Interface
l Java Server Page (JSP) JavaServer Pages (JSP) Pages
l Portlet API Tag Library The Portlet API Tag Libraries
l Deploy Descriptor Deployment Descriptors
The first Bookmark portlet is displayed and edited separately. Each JSP page is just a simple display of the current portlet mode of the portlet and the WindWOS state. In order to display this information, we use the Portlet API tag library (just part of the program code, please download all the code, or understand: Translator Note):
Public void doView (RenderRequest Request,
RenderResponse response) throws portletException, ioException {
Response.setContentType (Text / HTML ");
String jspname = getPortletConfig (). GetInitParameter ("jspview"); portletRequestDispatcher rd =
GetPortletContext (). getRequestDispatcher (jspname);
Rd.includ (Request, Response);
}
The next code is a simple JSP page in the example (ie View.jsp: Translator Note):
<% @ Page session = "false"%>
<% @ Page Import = "javax.portlet. *"%>
<% @ Page Import = "java.util. *"%>
<% @ Taglib URI = '/ Web-INF / TLD / Portlet.TLD' prefix = 'portlet'%>
Hello,
I am the bookmark portlet.
Current portlet mode: <% = portletRequest.getPortletMode ()%>
Current Window State: <% = portletRequest.getWindowState ()%>
Bookmark Portlet: Version 2
The second Bookmark portlet further deeply in the concept of portlet API. In addition to the portlet API feature used by the first example, it increases:
l Action Handling Handling
l portlet parameters portlet preferences
l Verify parameters a Preferences Validator
l Predefined Preference Description in the Deployment Descriptor Predefined Preferences in the Deployment Descriptor
In the second Bookmark example, two new JSP pages replace version one. First, edit.jsp allows you to add and delete bookmarks via portlet action. The bookmarks entered in this JSP page will be stored as portlet parameters. Second, view.jsp displays a bookmark stored as a portlet parameter by hyperlink.
Bookmark portlet: version of the version
Newly added features:
l Regional Deployment Descriptor Localizable Deployment Descriptor
l resource package resourcebundles
The deployment descriptor and JSP page are now available from the resource package (ResourceBundles) to get the displayed character set, they can support English and German.
Bookmark portlet: version four
The final portlet example demonstrates the Navigation of the Navigational State Concept through the Portlet API. There are seven bookmarks in the version, but the default page only shows four, as shown in Figure 4. By clicking on Next and Back hyperlinks, users can navigate to five bookmarks forward or backward. The initial point will be initialized to submit parameters such that the user can use the browser's refresh, backward and forward buttons.
Bookmark portlet version of the interface
Portlet review
As you can see, the reference implementation of the Portlet specification includes two parts: Portal and Portlet containers. Portal is a test drive for a simple running portlet container. The portlet container acts as a regular component that can quickly use other portals. This portlet instance uses a lot of important concepts in many portlet APIs. You can extend this instance with all portlet APIs and Servlet APIs. For example, you can use a servlet to output other useful information in a new window, such as a print preview. You can also interact with the portlet via the HTTP session. In fact, because portlets are a powerful technology, the function that can be implemented is endless.
