📄 integrate.xml.svn-base
字号:
<?xml version="1.0" encoding="UTF-8"?><!-- Licensed to the Apache Software Foundation (ASF) under one or morecontributor license agreements. See the NOTICE file distributed withthis work for additional information regarding copyright ownership.The ASF licenses this file to You under the Apache License, Version 2.0(the "License"); you may not use this file except in compliance withthe License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express orimplied.See the License for the specific language governing permissions andlimitations under the License.--><document> <properties> <title>Integrating Pluto Into Your Container</title> </properties> <body> <section name="Integrating Pluto Into Your Container"> <subsection name="1 Introduction"> <p> <a href="http://portals.apache.org/pluto/">Pluto</a> is a project at Apache Portals (http://portals.apache.org/pluto) that provides the reference implementation of the Java Portlet Specification. The first version of this specification is available as <a href="http://jcp.org/en/jsr/detail?id=168">JSR 168</a>. The pluto project contains two parts: the portlet container and a simple test portal driver. This document is about how to use the pluto portlet container and replace the sample portal driver with your own portal. </p> <div align="center"> <p> <a href="../../images/v101/jw-0801-portal_arch.jpg"> <img src="../../images/v101/jw-0801-portal_arch.jpg" alt="Portal Architecture" width="500"/> </a> </p> <p> <b><i>Figure 1. Basic portal architecture. Click on the picture to enlarge it</i></b> </p> </div> <p> Figure 1 depicts a portal's basic architecture. The portal's web application processes the client request, retrieves the portlets on the user's current page, and then calls the portlet container to retrieve each portlet's content. The portal accesses the Portlet Container by using the Portlet Container Invoker API. This interface represents the main interface of the portlet container supporting request-base methods to call portlets from a portal's point of view. The Container Provider SPI (Service Provider Interface) is a callback interface of the Portlet Container which needs to be implemented by the portal to get portal related information, the container cannot know about, like URL creation. Finally, the portlet container calls all portlets via the Portlet API. </p> </subsection> <subsection name="2 Portlet container pluto"> <p> The portlet container provides the runtime environment for the portlets. It is a core component of each portal, requires knowledge about the portal itself and has a need to reuse common code of the portal. Due to these requirements the pluto portlet container is built in a manner that completely separates the container from every other portal component. Said that, the portlet container is a standalone component that can be embedded in any portal by complying with the requirements of the portlet container, such as implementing all SPIs. The interfaces of the portlet container and its internal components are described in more detail in the next paragraphs. </p> <div align="center"> <p> <a href="../../images/v101/jw-0801-pluto_arch.jpg"> <img src="../../images/v101/jw-0801-pluto_arch.jpg" alt="Pluto Architecture" width="500"/> </a> </p> <p> <b><i>Figure 2. The portlet container's architecture. Click on the picture to enlarge it</i></b> </p> </div> <p> The Portlet Container Invoker API, also called entrance point, is the main calling interface of a portlet container. It combines the lifecycle (init, destroy) of a portlet container as well as the request based calling methods (processAction, render). Due to its nature of calling a portlet in the end, the method signature looks similar to the main portlet interface of the Portlet API except that a portlet identifier needs to be passed additionally. With this additional parameter the container is able to determine the portlet and call it accordingly. </p> <p> Besides of the application programming interfaces the portlet container can be instrumented by providing different implementations through service provider interfaces. Therefore, the reference implementation introduces a concept called Container Services. This concept will be described in more detail in a later chapter. </p> </subsection> <subsection name="3 How to integrate pluto with a portal framework"> <p> This section covers in detail how the portal can call the container and which SPIs needs to be implemented by the portal in order to re-use pluto. The portal calls the pluto container via the portlet container entrance point and needs to provide implementations for the SPIs container services and the portlet object model. </p> <subsection name="3.1 Portlet Container Entrance Point"> <p> The portlet container entrance point <code>org.apache.pluto.PortletContainer</code>, is the main interface between the portal's framework / aggregation and the portlet environment. This interface is used to call the portlet environment and execute portlets. It doesn't match exactly to the Portlet API methods (init, processAction, render, destroy) but generalizes the interface wherever possible. </p> <p> The entrance point has methods with different scopes: <ul> <li> <p>Lifecycle methods are called only <b>once</b> (init/shutdown).</p> <p>These methods are normally called directly from the service interfaces.</p> </li> <li> <p>Request-based methods are called for each request, but only once for all portlets (portletLoad).</p> <p>These methods must be called before the page aggregation actually starts and after aggregating the page, affecting all portlets being rendered on the page. Currently the only method in this category is portletLoad that ensures that the portlet is loaded and initialized before the request processing starts.</p> </li> <li> <p>Request-based methods are called for each request and for each portlet (processPortletAction, renderPortlet).</p> <p>These methods are normally called during the page aggregation as each portlet is being rendered.</p> </li> </ul> </p> <p> The contract defined by this interface must be fulfilled by the calling party to guarantee that the portlet environment will work correctly. </p> </subsection> <subsection name="3.2 Container Services"> <p> ContainerServices are a generic plug-in concept for extending the core portlet container with additional functionality. A ContainerService is defined by an interface, accessed by the portlet container and provided by the calling party (mostly⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -