portals-pluto-scm mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ddew...@apache.org
Subject svn commit: rev 43591 - in portals/pluto/trunk/xdocs: developer userguide
Date Thu, 09 Sep 2004 11:54:45 GMT
Author: ddewolf
Date: Thu Sep  9 04:54:45 2004
New Revision: 43591

Added:
   portals/pluto/trunk/xdocs/developer/
   portals/pluto/trunk/xdocs/developer/arch.xml
   portals/pluto/trunk/xdocs/developer/build_source.xml
   portals/pluto/trunk/xdocs/developer/index.xml
   portals/pluto/trunk/xdocs/developer/integrate.xml
   portals/pluto/trunk/xdocs/developer/subversion.xml
   portals/pluto/trunk/xdocs/userguide/
   portals/pluto/trunk/xdocs/userguide/index.xml
   portals/pluto/trunk/xdocs/userguide/portal.xml
   portals/pluto/trunk/xdocs/userguide/testsuite.xml
Log:
Preparing for release.  Reorganizing and adding documentation.

Added: portals/pluto/trunk/xdocs/developer/arch.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/developer/arch.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,177 @@
+<?xml version="1.0"?>
+<!-- 
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at 
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+  <properties>
+    <author email="unknown">Jean-Baptiste Joret</author>
+    <author email="david.AT.daviddewolf.DOT.com">David H. DeWolf</author>
+    <title>Pluto Project</title>
+  </properties>
+
+<body>
+  <section name="Architecture Overview">
+
+<p>
+    Let's begin by examining Pluto's architecture and underlying concepts.
+    First, we briefly explain the portal that runs the RI, and see where 
+    to find a portlet container inside a portal architecture. Next, we 
+    investigate Pluto's architecture in detail. Last, we look at how it 
+    solves one challenging item of the portlet container: portlet deployment.
+</p>
+
+<p><strong>The Portal</strong>
+   <blockquote>
+   Pluto normally serves to show how the Portlet API works and 
+   offers developers a working example platform from which they can test 
+   their portlets. However, it's cumbersome to execute and test the portlet 
+   container without a driver, in this case, the portal. Pluto's simple 
+   portal component is built only on the portlet container's and the JSR 
+   168's requirements. (In contrast, the more sophisticated, open source 
+   Apache Jetspeed project concentrates on the portal itself rather than 
+   the portlet container, and considers requirements from other groups.)
+   </blockquote>
+
+   <blockquote>
+   Figure 1 depicts the portal's basic architecture. The portal 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 with the Portlet Container Invoker API, representing the 
+   portlet container's main interface supporting request-based methods 
+   to call portlets from a portal's viewpoint. The container's user must 
+   implement the portlet container's Container Provider SPI (Service 
+   Provider Interface) callback interface to get portal-related 
+   information. Finally, the portlet container calls all portlets 
+   via the Portlet API.
+   </blockquote>
+
+   <blockquote>
+   <div align="center">
+        <p><a href="../images/jw-0801-portal_arch.jpg"><img src="../images/jw-0801-portal_arch-thumb.jpg" alt="Portal Architecture" height="160" width="250" border="0"/></a></p>
+        <p><b><i><font size="-1">Figure 1. The simple portal included with Pluto. Click on the picture to enlarge it</font></i></b></p>
+   </div>
+   </blockquote>
+</p>
+
+<p><strong>The Portlet Container</strong>
+   <blockquote>
+   The portlet container, the portlets' runtime environment and a core
+   component of each portal, requires knowledge about the portal itself 
+   and must reuse common code from it. Consequently, the portlet 
+   container remains completely separated from every other portal component.
+   That said, you can embed the standalone portlet container in any portal 
+   by complying with the portlet container's requirements, such as 
+   implementing all SPIs.
+   </blockquote>
+
+   <blockquote>
+   The Portlet Container Invoker API, also called an entrance point, acts 
+   as the portlet container's main calling interface. The API combines a 
+   portlet container's lifecycle (init, destroy) with request-based 
+   calling methods (initPage(), performTitle(), portletService(), and so 
+   on). Because the portlet container calls a portlet in the end, the 
+   method signature resembles the Portlet API's main portlet interface, 
+   except that a portlet identifier must be passed. With this additional 
+   portlet identifier, the container can determine the portlet and call 
+   it accordingly.
+   </blockquote>
+
+   <blockquote>
+   Besides using the APIs to access the portlet container, the portal
+   must implement SPIs defined for the portlet container. Therefore, 
+   the RI introduces container services: pluggable components that can 
+   be registered at the container to either extend or provide basic 
+   functionality. The RI includes the following built-in container services 
+   (the first four must be implemented to run the portlet container, while 
+   the fifth is optional): 
+   </blockquote>
+
+   <blockquote>
+   <ul>
+   <li> Information provider: Gives the portlet container information about 
+        the portal and its framework. Only known information or information 
+        that should be stored within the portal is present through this 
+        interface. Such information includes URL generation with navigational 
+        state, portlet context, portlet mode, and window-state handling</li>
+   <li> Factory manager: Defines how to get an implementation through a 
+        factory. (A normal portal should already own such an implementation.)</li>
+   <li> Log service: Defines a logging facility. (A normal portal should 
+        already own such an implementation.)</li>
+   <li> Config service: Defines how to get configuration values. (A normal portal 
+        should already own such an implementation.)</li>
+   <li> Property manager (optional): A property manager interface implementation 
+        lets a portal handle properties as defined in the JSR 168 specification.</li>
+   </ul>
+   </blockquote>
+
+   <blockquote>
+   Strictly speaking, the Portlet Object Model also acts as an SPI, but has an 
+   exceptional position among the SPIs. Therefore, don't consider it part of the 
+   container services as it deals with all portlet objects and comprises a collection
+   of interwoven interfaces.
+   </blockquote>
+
+   <blockquote>
+   <div align="center">
+        <p><a href="../images/jw-0801-pluto_arch.jpg"><img src="../images/jw-0801-pluto_arch-thumb.jpg" alt="Pluto Architecture" height="144" width="250" border="0"/></a></p>
+        <p><b><i><font size="-1">Figure 2. The portlet container's architecture. Click on the picture to enlarge it</font></i></b></p>
+   </div>
+   </blockquote>	   
+</p>
+<p><strong>Portlet Deployment</strong>
+   <blockquote>
+   The portlet container can leverage the servlet container's functionality, upon 
+   which the portlet container is built. To accomplish that, the portlet container 
+   must inject servlet artifacts into each portlet-application war file, as Figure 
+   3 shows. The portlet component, Deployment, takes the original war file, then 
+   injects a new or modified web.xml and a servlet to wrap each portlet and uses 
+   it as a calling point. Then the portlet deployment passes the modified war 
+   file to the application server deployment, which deploys it into the 
+   application server's system. During the portlet's invocation, the portlet 
+   container calls the injected servlet as an entrance point into the deployed 
+   portlet war file.
+   </blockquote>
+
+   <blockquote>
+   <div align="center">
+       <p><a href="../images/jw-0801-RI_deploy.jpg"><img src="../images/jw-0801-RI_deploy-thumb.jpg" alt="Deployment" height="170" width="250" border="0"/></a></p>
+       <p><b><i><font size="-1">Figure 3. Portlet deployment in the RI. Click on thumbnail to view full-size image.</font></i></b></p>
+   </div>
+   </blockquote>	   
+</p>
+
+
+<p><strong>Pluto and the WSRP standard</strong>
+   <blockquote>
+   The JSR 168 aligns closely with the Web Services for Remote Portlets (WSRP) standard. 
+   Both standards, which emerged at the same time, released open source implementations 
+   capable of all necessary functions described in the respective specifications. 
+   As a mutual goal, both standards strive to work well together. As a result, 
+   the portlet container can run WSRP portlets as a consumer as well as a producer.
+   </blockquote>
+
+   <blockquote>
+   Pluto must be able to run multiple portlet containers in one portal. Consequently, 
+   Pluto's portlet container can be instantiated multiple times and, more importantly,
+   it can be instrumented in different ways. Each portlet container, therefore, can 
+   use different implementations for SPIs.
+   </blockquote>
+</p>
+</section>
+</body>
+</document>
+

Added: portals/pluto/trunk/xdocs/developer/build_source.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/developer/build_source.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,126 @@
+<?xml version="1.0"?>
+<!-- 
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at 
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+  <properties>
+    <author email="unknown">Jean-Baptiste Joret</author>
+    <author email="david.AT.daviddewolf.DOT.com">David H. DeWolf</author>
+    <author email="nl.AT.essential.DOT.com.DOT.au">Nick Lothian</author>
+    <title>Pluto Project</title>
+  </properties>
+
+<body>
+<section name="Installation">
+<subsection name="Prerequisites">
+<p>It is expected that the user is familiar with the <a href="http://maven.apache.org">Apache
+  Maven</a> project tool.</p>
+</subsection>
+<subsection name="Requirements">
+<ul>
+  <li><a href="http://maven.apache.org/start/download.html">Maven 1.0</a>
+    or higher</li>
+  <li>Java 1.3 or higher</li>
+  <li>Servlet 2.3:<br/>
+    Tomcat 4.1.18-LE w/JDK 1.4<br/>
+    <b>or</b> <br/>
+    Tomcat 4.1.24 w/ JDK 1.3</li>
+</ul>
+</subsection>
+<subsection name="Get Maven Ready">
+<p>If you have not already done so, download and install Maven.</p>
+<p>2. build.properties settings:</p>
+<p>Please set these values in your <code>build.properties</code>
+  file:</p>
+<table width="650" border="1" cellspacing="0" cellpadding="3">
+  <tr>
+    <th width="134">property</th>
+    <th width="229">example</th>
+    <th width="261">what is it?</th>
+  </tr>
+  <tr>
+    <td width="134">maven.tomcat.home</td>
+    <td width="229">/tomcat</td>
+    <td width="261">location of the Tomcat install where you want to deploy Pluto</td>
+  </tr>
+  <tr>
+    <td width="134">maven.tomcat.version.major</td>
+    <td width="229">4</td>
+    <td width="261">Major version number (4 or 5) of the Tomcat install where you want to deploy Pluto</td>
+  </tr>
+</table>
+<p>You can copy the <code>build.properties.sample</code> file and name it
+	<code>build.properties</code> and use this is a starting point.</p>
+</subsection>
+<subsection name="Building and deploying">
+
+<ul>
+  <li>change your directory to root of the Pluto project.</li>
+  <li>maven fullDeployment</li>
+  <li>This will take care of everything for you including copying shared jars,
+    and deploy the base Pluto portal along with the Portlet Test Suite</li>
+</ul>
+</subsection>
+<subsection name="Start Tomcat">
+<p>Run Tomcat, go to http://localhost:8080/pluto/portal.</p>
+</subsection>
+</section>
+
+<section name="What if I just want the Pluto container jar (like for Jetspeed 2)?">
+<ol>
+  <li>cd to /container directory</li>
+  <li>maven jar:install</li>
+</ol>
+<p>This will create the container jar in /container/target and also copy into
+  you maven repository.</p>
+ </section>
+
+<section name="What if I just want to deploy the Pluto portal without the test suite?">
+<ol>
+  <li>Follow all the steps from &quot;<i>What if I just want the Pluto container
+    jar (like for Jetspeed 2)?</i>&quot;</li>
+  <li>cd to the /portal directory.</li>
+  <li>maven (with no goal)</li>
+</ol>
+<p>This will invoke the default maven goal for the /portal sub-project, deployPlutoToTomcat.
+  This will build and deploy the Pluto portal minus the test suite into
+  tomcat.</p>
+</section>
+
+<section name="What if I decide I want to deploy the test suite portlets after I deploy the Pluto portal by itself?">
+<ol>
+  <li>Follow all the steps from &quot;<i>What if I decide I want to deploy the
+    test suite portlets after I deploy JUST the Pluto portal?</i>&quot;</li>
+  <li>cd to the /testsuite directory.</li>
+  <li>maven (with no goal)</li>
+</ol>
+<p>This will invoke the default maven goal for the /testsute sub-project, deployTestsuite.
+  This will build and deploy the test suite portlets into your already deployed
+  Pluto portal.</p>
+</section>
+
+<section name="Install Portlets">
+   <p>
+    <ul>To install portlets after you successfully installed Pluto, 
+       invoke Maven to deploy the portlet's war by executing:
+		<code>maven deploy -Ddeploy=FULL_PATH_TO_YOUR_PORTLET_WAR</code>
+    </ul>
+   </p>
+</section>
+
+</body>
+</document>
+

Added: portals/pluto/trunk/xdocs/developer/index.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/developer/index.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,28 @@
+<?xml version="1.0"?>
+<!-- 
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at 
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+	<properties>
+		<author email="ddewolf@apache.org">David DeWolf</author>
+		<title>User Guide: Developing with Pluto</title>
+	</properties>
+<body>
+  <section name="Pluto Developer Guide">
+
+  </section>
+</body>
+</document>

Added: portals/pluto/trunk/xdocs/developer/integrate.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/developer/integrate.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,224 @@
+<?xml version="1.0"?>
+<!-- 
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at 
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+	<properties>
+		<author email="sthepper@apache.org">Stefan Hepper</author>
+		<author email="shesmer@apache.org">Stephan Hesmer</author>
+		<title/>
+	</properties>
+	<body>
+		<section name="Integrating Pluto Into Your Container">
+			<p align="center">Stefan Hepper (sthepper@apache.org)</p>
+			<p align="center">Stephan Hesmer (shesmer@apache.org)</p>
+			<subsection name="1 Introduction">
+				<p>
+					<a href="http://jakarta.apache.org/pluto">Pluto.</a> is a project at Apache Jakarta (http://jakarta.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/jw-0801-portal_arch.jpg">
+							<img src="../images/jw-0801-portal_arch-thumb.jpg" alt="Portal Architecture" border="0"/>
+						</a>
+					</p>
+					<p>
+						<b>
+							<i>
+								<font size="-1">Figure 1. Basic portal architecture. Click on the picture to enlarge it</font>
+							</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/jw-0801-pluto_arch.jpg">
+							<img src="../images/jw-0801-pluto_arch-thumb.jpg" alt="Pluto Architecture" height="144" width="250" border="0"/>
+						</a>
+					</p>
+					<p>
+						<b>
+							<i>
+								<font size="-1">Figure 2. The portlet container's architecture. Click on the picture to enlarge it</font>
+							</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/>
+				<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 org.apache.pluto.PortletContainer, 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/>
+					<p>The entrance point has methods with different scopes:</p>
+					<ul>
+						<li>
+							<p>Lifecycle methods are called only <strong>once</strong> (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>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 portal / framework). In some cases the flow goes in the other direction, from container to portal. The nature of a service can be viewed as a service made available for the portlet container: The container needs it to run, but cannot implement the service itself.</p>
+					<p/>
+					<p>The Container Service concept makes the portlet container independent of portal functions so that it can be used by different portals and furthermore new services can be plugged in to get a richer portlet container experience. A ContainerServiceEnvironment describing all services must be created and passed to the portlet environment during initialization.</p>
+					<p/>
+					<p>Container Services can be split into two different categories:</p>
+					<ul>
+						<li>
+							<p>
+								<strong>Mandatory Base Services</strong>
+							</p>
+							<p>ContainerServices that must be provided by the calling party so that the portlet container is able to run.</p>
+							<ul>
+								<li>
+									<p>Information Provider Service</p>
+									<p>described in the next sub section</p>
+								</li>
+								<li>
+									<p>Factory Manager Service</p>
+									<p>Factory Service enables the portlet container to get implementation objects through a factory concept.</p>
+								</li>
+								<li>
+									<p>Log Service</p>
+									<p>This interface defines a logging facility.</p>
+								</li>
+							</ul>
+						</li>
+						<li>
+							<p>
+								<strong>Optional Base Services</strong>
+							</p>
+							<p>ContainerServices that can be provided by the calling party, but the container can run without it.</p>
+							<ul>
+								<li>
+									<p>Property Manager Service</p>
+									<p>The implementation of the Property Service interface enables a portal to deal with properties as defined in the JSR 168 specification.</p>
+								</li>
+								<li>
+									<p>DynamicTitleService</p>
+									<p>Allows to support dynamic titles.</p>
+								</li>
+							</ul>
+						</li>
+					</ul>
+					<subsection name="3.2.1 Information Provider Service">
+						<p>The Information Provider is a callback mechanism for the portlet environment into the calling party (mostly framework), to get hold of necessary information that can only be known by the portal, like hostname and URL generation. To differentiate between the scopes of the requested information, the portlet environment defines two interfaces: the DynamicInformationProvider and the StaticInformationProvider.</p>
+						<p>The DynamicInformationProvider provides request-based information, which changes for each request. Consequently a new DynamicInformationProvider needs to be passed to the portlet environment for each request. Typical information provided by this Information Provider is a URL to a portlet. Additional provider interfaces retrieved via getter methods of the DynamicInformationProvider are PortletURLProvider and PortletActionProvider.</p>
+						<p/>
+						<p>The StaticInformationProvider on the other hand provides non-request-based information, which is constant across all requests. Therefore only one StaticInformationProvider needs to be provided to the portlet environment (singleton). Typical information provided by this Information Provider is the root context of the portal. An additional provider interface retrieved via a getter method of the StaticInformationProvider is the PortalContextProvider that contains further information about the portal, which need to be provided to the portlet.</p>
+						<p/>
+						<p>Both Information Providers are not actively passed by the calling party to the environment. Instead they are made available to the portlet environment through the Container Service mechanism described in the next section. Basically, the portlet environment asks the calling party for an instance of one of the Information Providers and the calling party returns the correct Information Provider.</p>
+					</subsection>
+					<subsection name="3.3 Portlet Object Model">
+						<p>The Portlet Object Model interfaces are defined in the package org.apache.pluto.om. These interfaces should be seen as an internal interface that can be used by other components of the portal. The portlet environment only defines the interfaces that are necessary to execute the object model the portal that uses the portlet environment must implement the object model. </p>
+						<p>The object model represents the information available on different levels about portlets and the portlet application, like the deployment descriptors and customization data. </p>
+						<p>The following definitions are used to represent the different levels of information:</p>
+						<ul>
+							<li>
+								<p>
+									<strong>WebApplicationDefinition</strong> represents the context for the Portlet Application defined in the web.xml deployment descriptor.</p>
+							</li>
+							<li>
+								<p>
+									<strong>PortletApplicationDefinition</strong> describes a set (either all or a subset) of portlets that participate all in the same WebApplicationDefinition.</p>
+							</li>
+							<li>
+								<p>
+									<strong>PortletApplicationEntity</strong> is an instantiation of a PortletApplicationDefinition that is bound to a portal resource. It contains a set (either all or a subset) of portlets that participate all in the same PortletApplicationDefinition.</p>
+							</li>
+							<li>
+								<p>
+									<strong>ServletDefinition</strong> describes the portlet and its initial read-only properties that is not bound to any portal resource.</p>
+							</li>
+							<li>
+								<p>
+									<strong>Portlet Definition</strong> basic settings defined in the portlet.xml or set by administrators (read-only for users).</p>
+							</li>
+							<li>
+								<p>
+									<strong>Portlet Entity</strong> is a parameterized portlet definition, belonging to a user. </p>
+							</li>
+							<li>
+								<p>
+									<strong>Portlet Window</strong> is part of an aggregation tree that contains the portlet markup. The portlet window has navigational state attached to it.<!--&#11;-->
+								</p>
+							</li>
+						</ul>
+						<p>Figure 3 depicts the relation between the different definitions and their hierarchical structure. The servlet definitions are embedded in the web application definition. From a web application definition several portlet application definitions can be created that may consist of portlet definitions based on the servlet definitions defined in the web application definition. Using the portlet application definition several portlet application entities can be created that include portlet entities that are based on the corresponding portlet definitions. Finally the portlet windows of a portlet entity are linked to their corresponding portlet entity.</p>
+						<div align="center">
+							<p>
+								<a href="../images/Relations.jpg">
+									<img src="../images/Relations.jpg" alt="Portal Architecture" height="144" width="250" border="0"/>
+								</a>
+							</p>
+							<p>
+								<b>
+									<i>
+										<font size="-1">Figure 3. Relations between the different application and portlet representations</font>
+									</i>
+								</b>
+							</p>
+						</div>
+						<p>The portlet object model represents these different layers allowing the portlet container to access the information layer-based.</p>
+						<p>The object model is split into four different sub-packages:</p>
+						<ul>
+							<li>
+								<p>common</p>
+								<p>contains generic interfaces that can be reused</p>
+							</li>
+							<li>
+								<p>window</p>
+								<p>contains all interfaces handling with portlet windows</p>
+							</li>
+							<li>
+								<p>entity</p>
+								<p>contains all interfaces handling with portlet application entities and portlet entities</p>
+							</li>
+							<li>
+								<p>portlet</p>
+								<p>contains all interfaces handling with portlet application definitions and portlet definitions</p>
+							</li>
+							<li>
+								<p>servlet</p>
+								<p>contains all interfaces representing the web application definitions and servlet definitions</p>
+							</li>
+						</ul>
+						<p>For the implementation of the different artifacts in the object model the model-view-controller pattern is used and for each artifact a read-only interface exists, and if required an interface with the setter methods and the ending Ctrl is provided.</p>
+					</subsection>
+				</subsection>
+			</subsection>
+		</section>
+	</body>
+</document>

Added: portals/pluto/trunk/xdocs/developer/subversion.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/developer/subversion.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,62 @@
+<?xml version="1.0"?>
+<!-- 
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at 
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+<properties>
+  <author email="ddewolf@apache.org">David DeWolf</author>
+  <title>Developer Guide: Obtaining the Source Code</title>
+</properties>
+
+<body>
+  <section name="Developer Guide: Obtaining the Source Code">
+  <p>
+    There are several reasons why you may want to have access to
+    the pluto source code.  Some may want to participate in 
+    the development of Pluto by submiting patches.  Others may want
+    to utilize Pluto as a reference implementation to clarify
+    the Portlet Specification.  Whatever the reason, there are two
+    ways to access the source code.
+  </p>
+
+  <p>
+    <A href="#Downloading_the_Source_Distribution">Downloading the
+    most recent Source Distribution</A> is the easiest
+    way to access the source.  Of course, because this method is 
+    reliant on realeases, you may not have the most recent source.
+    That said, you do have a better chance at recieving a more
+    stable codebase if you are using a distiribution.
+  </p>
+
+  <p>
+    <A href="#Using_Subversion">Using Subversion</A> to checkout the
+    absolute up-to-date version of the code is the best way to
+    retrieve the source code.  If you plan to submit patches, 
+    we ask that you use the Subversion Trunk to create your
+    diffs.
+  </p>
+    
+    <subsection name="Downloading the Source Distribution">
+
+    </subsection>
+
+    <subsection name="Using Subversion">
+
+    </subsection>
+
+  </section>
+</body>
+</document>

Added: portals/pluto/trunk/xdocs/userguide/index.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/userguide/index.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,87 @@
+<?xml version="1.0"?>
+<!--
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+  <properties>
+  <author email="ddewolf.AT.apache.D0T.org">David DeWolf</author>
+  <title>Pluto User Guide</title>
+</properties>
+
+<body>
+<section name="User Guide">
+<subsection name="Prerequisites">
+  <p>It is expected that the reader of the user guide documentation
+     should has an understanding of Java Web Application development, and 
+     Java Portlet Development.</p>
+</subsection>
+
+<subsection name="Pluto - The Pluto Container">
+<p>
+   Pluto is the reference implementation of the Portlet Specification.
+   It is a portlet container which manages the lifecycle and request
+   processing of portlets which adhere to the specification.
+</p>
+   
+<p>
+   In an of itself, Pluto is not very usefull to the end user.
+   As a container, it does not have any understanding of portlet
+   invocation, portlet aggregation or other portal specific features. 
+</p>
+
+<p>
+  For more information on how to integrate Pluto into your portal, 
+  please see the <A href="../developer/integration.html">developer guides</A>.
+</p>
+
+</subsection>
+
+<subsection name="Pluto Portal Driver - The Test Portal">
+<p>
+  The Pluto Portal Driver is a simple portal implementation that
+  is provided for convenience sake. It's purpose is to provide
+  aggregation support so that Pluto may be easily tested, and
+  portlets may be easily developed.
+</p>
+
+<p>
+  For information on how to use, configure, and customize the 
+  Portal Driver, please see the 
+  <A href="portal.html">Portal Driver User Guide</A>.
+</p>
+
+</subsection>
+
+<subsection name="Pluto TestSuite - The Test Portlet Application">
+<p>
+  The Pluto TestSuite is a Portlet Application which can be used to test
+  Portlet Implementations.  The TestSuite tests several basic portlet
+  functions and is a quick and dirty way to test for Portlet Specification
+  compliance.  While a quick test of a portal using the testsuite won't 
+  garuntee compliance, it will help flag any notable incompliance.
+</p>
+
+<p>
+  For information on how to use and configure the TestSuite, please see
+  the <A href="testsuite.html">TestSuite User Guide</A>
+</p>
+</subsection>
+
+</section>
+
+</body>
+</document>
+

Added: portals/pluto/trunk/xdocs/userguide/portal.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/userguide/portal.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,429 @@
+<?xml version="1.0"?>
+<!--
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+<properties>
+  <author email="nlothian.AT.apache.DOT.org">Nick Lothian</author>
+  <author email="ddewolf.AT.apache.DOT.org">David DeWolf</author>
+  <title>User Guide: Pluto Portal Driver</title>
+</properties>
+
+<body>
+<section name="User Guide: Pluto Portal Driver">
+  <p>
+  <ul>
+  <li><A href="#Limitations">Limitations</A></li>
+  <li><A href="#Configuration">Configuration</A></li>
+  <li><A href="#Layout_and_Aggregation">Layout and Aggregation</A></li>
+  <li><A href="#Customization">Advanced Customization</A></li>
+  <li><A href="#Internationalization">Internationalization</A></li>
+  <li><A href="#Further_Informaion">Further Information</A></li>
+  </ul>
+  </p>
+</section>
+
+
+<section name="Limitations">
+    <p>
+       The Pluto Portal is intended to provide an example implementation of
+       how to integrate Pluto into a portal. Additionally, it may be used for
+       the development of compliant portlets.  In some places it lacks the 
+       flexibility a true portal supplies. The portal is not designed for 
+       maximum performance, but rather simplicity.
+     </p>
+
+     <p>
+       To learn how to embed Pluto in your own portal, see the
+	   "<a href="Howto_use_the_Pluto_container.html">Pluto in your portal</a>" document.</p>
+</section>
+
+<section name="Configuration">
+  <subsection name="Default Configuration">
+    <p>
+      Upon installation of the binary distribution of Pluto, the portal
+      driver is made available at <code>http://localhost/pluto/portal</code>.
+      The default installation is configured with a single portal page which
+      contains two instances of the testsuite portlet.  This configuration 
+      is also the default for installations completed from the source distribution
+      (or Subversion repository) and deployed using the Pluto deploy tool.
+    </p>
+    <p>
+      <table>
+      <caption><B>Default Configuration for Binary Distributions:</B></caption>
+      <tr><th>Configuration</th>
+          <th>Platform</th>
+          <th>Value</th><th>Description</th></tr>
+      <tr><td>Installation Directory</td>
+          <td>All</td>
+          <td>&lt;PLUTO_HOME&gt;</td>
+          <td>The directory to which you unarchived the distribution</td></tr>
+      <tr><td>Startup Scipts</td>
+          <td>*nix</td>
+          <td>&lt;PLUTO_HOME&gt;/bin/startup.sh</td>
+          <td>The script used to startup the portal driver</td></tr>
+      <tr><td>Startup Scipts</td>
+          <td>Windows</td>
+          <td>&lt;PLUTO_HOME&gt;/bin/startup.bat</td>
+          <td>The script used to startup the portal driver</td></tr>
+      <tr><td>Context Configuration</td>
+          <td>All</td>
+          <td>&lt;PLUTO_HOME&gt;/conf/Catalina/localhost/pluto.xml</td>
+          <td>The Tomcat Context Configuration file</td></tr>
+      </table>
+    </p>
+
+    <p>
+      <table>
+      <caption><B>Default Configuration for Source Distributions:</B></caption>
+      <tr><th>Configuration</th>
+          <th>Platform</th>
+          <th>Value</th><th>Description</th></tr>
+      <tr><td>Installation Directory</td>
+          <td>All</td>
+          <td>${maven.tomcat.home}</td>
+          <td>The tomcat installation directory to which pluto has been installed</td></tr>
+      <tr><td>Startup Scipts</td>
+          <td>*nix</td>
+          <td>${maven.tomcat.home}/bin/startup.sh</td>
+          <td>The script used to startup the portal driver</td></tr>
+      <tr><td>Startup Scipts</td>
+          <td>Windows</td>
+          <td>${maven.tomcat.home}/bin/startup.bat</td>
+          <td>The script used to startup the portal driver</td></tr>
+      <tr><td>Context Configuration</td>
+          <td>Tomcat 5</td>
+          <td>${maven.tomcat.home}/conf/Catalina/localhost/pluto.xml</td>
+          <td>The Tomcat Context Configuration file</td></tr>
+      <tr><td>Context Configuration</td>
+          <td>Tomcat 4</td>
+          <td>${maven.tomcat.home}/webapps/pluto.xml</td>
+          <td>The Tomcat Context Configuration file</td></tr>
+      </table>
+    </p>
+
+    <p>When the Pluto Portal is first installed, it is made available at 
+       the address http://localhost/pluto/portal/.</p>
+
+				<p>This location can be customized, using standard Tomcat functionality. To modify the <i>pluto</i> part of the
+				location, alter the path mapping in pluto's context configuration file <i>pluto.xml</i></p>
+
+				<p>Under Tomcat 4.1, pluto.xml will be created in the ${TOMCAT_HOME}/webapps/ directory. Under Tomcat 5, pluto.xml will be created
+				in the ${TOMCAT_HOME}/conf/Catalina/ directory. </p>
+
+				<p>In order to modify the context Pluto is running under, modify the <i>path</i> attribute:</p>
+				<p>
+				<b>Before:</b>
+				<source>
+	&lt;Context path="/pluto" docBase="pluto" crossContext="true"&gt;
+	&lt;/Context&gt;
+				</source>
+				</p>
+				<p><b>After:</b>
+				<source>
+	&lt;Context path="/newlocation" docBase="pluto" crossContext="true"&gt;
+	&lt;/Context&gt;
+				</source>
+				</p>
+
+				<p>After this modification (and restarting Tomcat),
+				the Pluto Portal will be available at the address http://servername/newlocation/portal/.
+				Further information on customizing the context configuration is available for
+				<a href="http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html">Tomcat 4.1</a>
+				and <a href="http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/context.html">Tomcat 5</a>.
+				</p>
+
+				<p>To modify the <i>portal</i> part of the location, alter the <i>url-pattern</i> for the
+				<i>pluto</i> servlet. This mapping can be found in the <i>web.xml</i> configuration file
+				for the Pluto web application.</p>
+				<p>
+				<b>Before:</b>
+				<source>
+    &lt;servlet-mapping&gt;
+       &lt;servlet-name&gt;pluto&lt;/servlet-name&gt;
+       &lt;url-pattern&gt;/portal/*&lt;/url-pattern&gt;
+    &lt;/servlet-mapping&gt;
+				</source>
+				</p>
+				<p>
+				<b>After:</b>
+				<source>
+    &lt;servlet-mapping&gt;
+       &lt;servlet-name&gt;pluto&lt;/servlet-name&gt;
+       &lt;url-pattern&gt;/app/*&lt;/url-pattern&gt;
+    &lt;/servlet-mapping&gt;
+				</source>
+				</p>
+				<p>After this modification (and restarting Tomcat),
+				the Pluto Portal will be available at the address http://servername/newlocation/app/
+				(assuming that the previous modification was also applied).
+				</p>
+			</subsection>
+
+			<subsection name="Registering Portlets for use">
+				<p>In order to use a Portlet in the Pluto Portal it needs to be registered. The Pluto Portal
+				keeps page registrations in a file named <i>portletentityregistry.xml</i> in the directory
+				${TOMCAT_HOME}/webapps/pluto/data.</p>
+
+				<p>By default, this file looks like this:
+				<source>
+&lt;?xml version="1.0" encoding="UTF-8"?&gt;
+&lt;portlet-entity-registry&gt;
+    &lt;application id="3"&gt;
+        &lt;definition-id&gt;testsuite&lt;/definition-id&gt;
+        &lt;portlet id="1"&gt;
+            &lt;definition-id&gt;testsuite.TestPortlet1&lt;/definition-id&gt;
+            &lt;preferences&gt;
+                &lt;pref-name&gt;TestName4&lt;/pref-name&gt;
+                &lt;pref-value&gt;TestValue4&lt;/pref-value&gt;
+                &lt;read-only&gt;true&lt;/read-only&gt;
+            &lt;/preferences&gt;
+        &lt;/portlet&gt;
+    &lt;/application&gt;
+    &lt;application id="4"&gt;
+        &lt;definition-id&gt;testsuite&lt;/definition-id&gt;
+        &lt;portlet id="1"&gt;
+            &lt;definition-id&gt;testsuite.TestPortlet2&lt;/definition-id&gt;
+            &lt;preferences&gt;
+                &lt;pref-name&gt;TestName4&lt;/pref-name&gt;
+                &lt;pref-value&gt;TestValue4&lt;/pref-value&gt;
+                &lt;read-only&gt;true&lt;/read-only&gt;
+            &lt;/preferences&gt;
+        &lt;/portlet&gt;
+    &lt;/application&gt;
+&lt;/portlet-entity-registry&gt;
+				</source>
+				</p>
+				<p>Each &lt;application&gt; tag defines one application (corresponding to one web-app on the
+				portal container), which can contain multiple &lt;portlet&gt; tags.
+				The "id" attribute in this tag identifies the application, and it does not need to be numeric.</p>
+
+				<p>The &lt;definition-id&gt; tag within the &lt;application&gt; refers to the name of the
+				web-app that contains the portlets in this application.</p>
+
+				<p>Each &lt;portlet&gt; tag defines one portlet. The "id"
+				attribute in this tag identifies the portlet. Note that the application id concatenated with the portlet
+				id will be mapped to the "value" attribute in the &lt;proprety&gt; tag in pageregistry.xml
+				(which is explained later).</p>
+
+				<p>Each &lt;preferences&gt; tag within the &lt;portlet&gt; tag defines name/value pairs for
+				the PorletPreferences.</p>
+
+				<p>In the example above two Portlet applications are made available to the portal with the
+				ids of "3" and "4". Both happen to point to the same webapp (<tt>&lt;definition-id&gt;testsuite&lt;/definition-id&gt;</tt>).
+				Both applications define a single Portlet each. Application id 3 uses the Portlet <i>TestPortlet1</i>
+				(<tt>&lt;definition-id&gt;testsuite.TestPortlet1&lt;/definition-id&gt;</tt>), while Application id 4 uses
+				the Portlet <i>TestPortlet2</i>	(<tt>&lt;definition-id&gt;testsuite.TestPortlet2&lt;/definition-id&gt;</tt>).
+				Note that prefixing the name of the Portlet with the name of web application (<i><b>testsuite</b>.TestPortlet1</i>)
+				is required.
+				</p>
+
+				<p>The Portlets themselves are defined in the portlet.xml configuration file within the
+				testsuite web application.	In that file there are two Portlets defined,
+				<i>TestPortlet1</i> and <i>TestPortlet2</i>, both of which point to the same
+				portlet class (<tt>org.apache.pluto.portalImpl.portlet.TestPortlet</tt>).
+				See the javax.portlet specification (JSR-168) for futher details on using the portlet.xml file.
+				</p>
+			</subsection>
+
+			<subsection name="Defining the Portal Layout">
+				<p>Once the Portlets available have been defined the Portal layout needs to be defined.	In the
+				Pluto Portal the file <i>pageregistry.xml</i> in the directory ${TOMCAT_HOME}/webapps/pluto/data defines this layout.</p>
+
+				<p>When Pluto is first installed, pageregistry.xml looks like this:
+			<source>
+&lt;?xml version="1.0"?&gt;
+&lt;portal&gt;
+    &lt;fragment name="navigation" class="org.apache.pluto.portalImpl.aggregation.navigation.TabNavigation"&gt;
+    &lt;/fragment&gt;
+
+    &lt;fragment name="test" type="page"&gt;
+        &lt;navigation&gt;
+            &lt;title&gt;Test&lt;/title&gt;
+            &lt;description&gt;...&lt;/description&gt;
+        &lt;/navigation&gt;
+
+        &lt;fragment name="row" type="row"&gt;
+            &lt;fragment name="col1" type="column"&gt;
+
+                &lt;fragment name="p1" type="portlet"&gt;
+                    &lt;property name="portlet" value="3.1"/&gt;
+                &lt;/fragment&gt;
+                &lt;fragment name="p2" type="portlet"&gt;
+                    &lt;property name="portlet" value="4.1"/&gt;
+                &lt;/fragment&gt;
+
+            &lt;/fragment&gt;
+        &lt;/fragment&gt;
+    &lt;/fragment&gt;
+&lt;/portal&gt;
+			</source>
+				</p>
+
+				<p>This configuration results in the Portal being displayed
+				(from the url http://servername/pluto/portal/test/) as Figure 1 shows.</p>
+
+				<div align="center">
+					<p>
+						<a href="images/defaultPortalLayout.gif"><img src="images/defaultPortalLayoutThumb.gif" alt="Default Portal Layout" border="0"/></a>
+					</p>
+					<p>
+						<i><b><font size="-1">Figure 1. Default Portal Layout. Click on the picture to enlarge it</font></b></i>
+					</p>
+				</div>
+
+				<p>Working from the top of pageregistry.xml down, the first important section we come to is:
+				<source>
+&lt;fragment name="navigation" class="org.apache.pluto.portalImpl.aggregation.navigation.TabNavigation"&gt;
+&lt;/fragment&gt;
+				</source>
+				</p>
+				<p>This section tells the Portal to add a navigation menu to the user interface. Each fragment of
+				type <i>page</i> will be displayed in the navigation menu, provided the fragment has a &lt;navigation&gt;
+				sub-element. Removing the <tt>&lt;fragment name="navigation" ...&gt;&lt;/fragment&gt;</tt> section
+				will result in no navigation menu being displayed.
+				</p>
+
+				<p>
+				The next section is:
+				<source>
+    &lt;fragment name="test" type="page"&gt;
+        &lt;navigation&gt;
+            &lt;title&gt;Test&lt;/title&gt;
+            &lt;description&gt;...&lt;/description&gt;
+        &lt;/navigation&gt;
+		...
+		...
+    &lt;/fragment&gt;
+				</source>
+				</p>
+				<p>
+				This section defines a Portal "page", which is simply a container for one or more Portlets. The <i>name</i>
+				attribute must be unique within the pageregistry.xml file (if this constraint is not met an error
+				message <i>Fragment with this name &lt;duplicated name&gt; already exists in the pageregistry.xml.</i> will be written to your
+				log and your Pluto web application will fail to load).
+				</p>
+				<p>
+				The navigation subsection is used by the navigation menu (discussed previously). The &lt;title&gt;...&lt;/title&gt;
+				defines the label that will be shown in the navigation menu. The &lt;description&gt;...&lt;/description&gt;element
+				is not used.
+				</p>
+
+				<p>Inside the <tt>&lt;fragment type="page" .... &gt;&lt;/fragment&gt;</tt> elements we find
+				<source>
+    &lt;fragment name="row" type="row"&gt;
+        &lt;fragment name="col1" type="column"&gt;
+
+            &lt;fragment name="p1" type="portlet"&gt;
+                &lt;property name="portlet" value="3.1"/&gt;
+            &lt;/fragment&gt;
+            &lt;fragment name="p2" type="portlet"&gt;
+                &lt;property name="portlet" value="4.1"/&gt;
+            &lt;/fragment&gt;
+
+        &lt;/fragment&gt;
+    &lt;/fragment&gt;
+				</source>
+				</p>
+				<p>This defines the layout of the Portal "page". In this case two Portlets will be laid out in two columns,
+				nested inside a single row.
+				</p>
+				<p>The configuration below will give the page a layout of two rows, with a Portlet in each. Note that the names of all fragments
+				need to be unique.
+				<source>
+	&lt;fragment name="row1" type="row"&gt;
+	    &lt;fragment name="col1" type="column"&gt;
+	        &lt;fragment name="p1" type="portlet"&gt;
+	            &lt;property name="portlet" value="3.1"/&gt;
+	        &lt;/fragment&gt;
+	    &lt;/fragment&gt;
+	&lt;/fragment&gt;
+	&lt;fragment name="row2" type="row"&gt;
+	    &lt;fragment name="col2" type="column"&gt;
+	        &lt;fragment name="p2" type="portlet"&gt;
+	            &lt;property name="portlet" value="4.1"/&gt;
+	        &lt;/fragment&gt;
+	    &lt;/fragment&gt;
+	&lt;/fragment&gt;
+				</source>
+				</p>
+				<p>The section
+				<source>
+    &lt;fragment name="p1" type="portlet"&gt;
+        &lt;property name="portlet" value="3.1"/&gt;
+    &lt;/fragment&gt;
+    			</source>
+    			</p>
+    			<p>defines which portlet to display. <tt>&lt;property name="portlet" value="3.1"/&gt;</tt> tells the Portal
+				to lookup the Portlet "3.1" and display it in this location. The value "3.1" means refers to the ids given
+				in <i>portletentityregistry.xml</i> (discussed previously). In this case, it mean application id "3",
+				portlet id "1".
+				</p>
+			</subsection>
+		</section>
+
+		<section name="Advanced Customization">
+			<subsection name="JSP Templates">
+				<p>It is possible to customize the JSP templates Pluto uses. This is beyond the scope of this document,
+				but a brief outline follows to get you started.</p>
+
+				<p>By default, Pluto uses JSP templates from the directory
+				${TOMCAT_HOME}/webapps/pluto/WEB-INF/aggregation directory. This can be overridden by
+				adding a line like
+				<source>
+aggregation.base.dir=/WEB-INF/templates/
+				</source>
+				to the file ${TOMCAT_HOME}/webapps/pluto/WEB-INF/config/services/ConfigService.properties.
+				</p>
+				<p>The following JSP files are used by the Portal:
+					<ul>
+						<li>Banner.jsp - The blue title bar which says "Pluto - Reference Implementation". Only called from RootFragment.jsp</li>
+						<li>ColumnFragment.jsp - Called for each column fragment.</li>
+						<li>Head.jsp - The HTML header. Only called from RootFragment.jsp</li>
+						<li>PageFragment.jsp - Called for each Portal page displayed.</li>
+						<li>PortletFragmentFooter.jsp - The footer of each Portlet.</li>
+						<li>PortletFragmentHeader.jsp - The header of each Portlet.</li>
+						<li>RootFragment.jsp - Defines the layout of the Portal. This is the file to modify if you need
+							to modify the width of the navigation bar, for instance.</li>
+						<li>RowFragment.jsp - Called for each row fragment.</li>
+						<li>TabNavigation.jsp - Displays the navigation menu.</li>
+					</ul>
+				</p>
+				<p>
+				Most customization of the Portal can be done in RootFragment.jsp,
+				PortletFragmentHeader.jsp and PortletFragmentFooter.jsp.
+				</p>
+			</subsection>
+			<subsection name="Internationalization">
+				<p>The Pluto portal supports non latin-1 character-sets in its output. To enable this, uncomment the section
+				<source>
+	 &lt;init-param&gt;
+	     &lt;param-name&gt;charset&lt;/param-name&gt;
+	     &lt;param-value&gt;utf-8&lt;/param-value&gt;
+	 &lt;/init-param&gt;
+				</source>
+				from the "pluto" Servlet section in the file ${TOMCAT_HOME}/webapps/pluto/WEB-INF/web.xml.</p>
+			</subsection>
+			<subsection name="Further information">
+				<p>
+				Further information can be found in the <a href="faq.html">FAQ</a>, on the <a href="mail-lists.html">Mailing Lists</a>
+				and on the <a href="wiki.html">Wiki</a>
+				</p>
+			</subsection>
+		</section>
+	</body>
+</document>
+

Added: portals/pluto/trunk/xdocs/userguide/testsuite.xml
==============================================================================
--- (empty file)
+++ portals/pluto/trunk/xdocs/userguide/testsuite.xml	Thu Sep  9 04:54:45 2004
@@ -0,0 +1,34 @@
+<?xml version="1.0"?>
+<!--
+Copyright 2004 The Apache Software Foundation
+Licensed  under the  Apache License,  Version 2.0  (the "License");
+you may not use  this file  except in  compliance with the License.
+You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing, software
+distributed  under the  License is distributed on an "AS IS" BASIS,
+WITHOUT  WARRANTIES OR CONDITIONS  OF ANY KIND, either  express  or
+implied.
+
+See the License for the specific language governing permissions and
+limitations under the License.
+-->
+<document>
+<properties>
+  <author email="ddewolf@apache.org">David DeWolf</author>
+  <title>User Guide: Testsuite</title>
+</properties>
+
+<body>
+<section name="Testsuite Overview">
+<p>
+
+</p>
+</section>
+
+
+</body>
+</document>
+

Mime
View raw message