index.xml - portals-pluto - Git at Google

 <?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 H. DeWolf</author>
     <title>Differences Pluto 1.1 vs Pluto 1.0.1</title>
   </properties>

 <body>
 <section name="Document Overview">
 <P>
     This document attempts to describe the differences between
     Pluto 1.0.x and Pluto 1.1.  It seeks to define both the
     architectural and design changes along with the reasons why
     each decision was made.

 <subsection name="Table of Contents">
 <P>
     <ul><li><A href="#Overview_of_Changes">Overview of Changes</A></li>
         <li><A href="#Project_Modules">Changes by Project Module</A>
             <ul><li><A href="#Embedder_Interface">Embedder Interface</A></li>
                 <li><A href="#Container_Simplification">Container Simplification</A></li>
                 <li><A href="#Portal_Driver">Portal Driver</A></li></ul>
             </li></ul>
 </P>
 </subsection>
 </P>
 </section>

 <section name="Overview of Changes">
 <P>
     The Pluto 1.1 branch is a refactoring and reimplementation of the
     originally donated codebase (which was originally released as
     Pluto 1.0).  While this codebase met the requirements of Portlet
     Specification, it was found by the community to be clumzy and
     complex.  As a result, Pluto 1.1 aims to take a semi-revolutionary
     approach which follows best practices and a more traditional design.
 </P>
 <P>
     The semi-revolutionary approach can be considered both a refactoring
     and a rewrite due to the fact it originally leveraged Pluto 1.0.1
     implementations where-ever possible without jeopordizing the
     community's intention to simplify integration.
 </P>
 <P>
     The following are the high level considerations which were the goal
     of the development of Pluto 1.1 seed code.
     <ul><li>Simplify the container, driver, and deployer in order
             to encourage increased participation in our community.</li>
         <li>Reduce the cost of entry required to start using and developing
             portlets with pluto.</li>
         <li>Reduce the complexity of embedding pluto into a portal.</li>
         <li>Use common best practices and design patterns to reduce
             the cost of entry for contributions.</li></ul>
 </P>
 </section>

 <section name="Project Modules">
 <subsection name="Embedder Interface">
 <P>
     The simplification of the interface used to integrate pluto into
     a portal involves the following:
     <ul><li><H5>Creation of a well defined Integration Interface</H5>
             The Pluto 1.0.x Container Services interface defines a
             single method from which services can be retrieved
             (by class). This led to some confusion as to which
             services were required.</li>
         <li><H5>Usage of a Container Approach</H5>
             Instead of continually invoking pluto through a static
             interface, a container instance (which has a well
             defined interface) is created and returned upon instantiation.
             This reference is then used from there forward to invoke the
             container.  Additionally, this approach allows us to hide
             the underlying container implementation. A container now
             has the following lifecycle:
             <P>
             <pre>
 // Initialization

 String name = // the container name
 ServletContext context = // the portal's context
 PortletContainerServices services = // the portal's implementation

 PortletContainer container =
     PortletContainerFactory.createContainer(name, services);
 container.init(servletContext);


 // Action Processing
 container.doAction(portletWindow, request, response);


 // Render Processing
 container.doRender(portletWindow, request, response);


 // Destruction / Shutdown
 container.destroy();
             </pre>
             </P>
             Besides the container services, no other implementation details are needed
             by the portal.
         </li>
         <li><H5>Removal of unecessary services.</H5>
             Pluto 1.0.x allowed an overwhelming number of services/
             factories to allow for unlimited flexibility.  Some of
             these services/factories are unecessary as they allow
             for so much flexibility that in fact you are no longer
             using the container (see PortletInvoker). The removal
             of this incredible flexibility allows for a simplified
             integration AND simplification of the container.</li>
         <li><H5>Migration of Deployment Descriptor consumption to container</H5>
             By moving the responsibility of consuming the deployment
             descriptor to the container, implementers have one less
             responsibility.  Additionally, the PortletWindow interface
             is able to become much simpler.</li></ul>

 </P>
 </subsection>

 <subsection name="Container Simplification">
 <P>
     The considerations for simplifying they container are as follows:
     <ul><li><H5>Dependency Injection</H5>
             The use of dependency injection throughout the
             container will allow for the removal of several
             factories and, perhaps most importantly, the removal
             of the necessity of ThreadLocal's for lookup of
             services.</li>
         <li><H5>Usage of Internal Objects</H5>
             By removing unecessary services it becomes possible to
             pass references by specific implementation instead of
             interface. This reduces the converstions (i.e. from
             ActionRequest to InternalActionRequest) that are required
             and allows the container to be a little more intelligent
             about it's environment.
             </li></ul>
 </P>
 </subsection>

 <subsection name="Portal Driver">
 <P>
     The Pluto Portal Driver is intended to provide an example of how to
     imbed pluto and perhaps even more importantly, provide a wrapper
     which can be used to test portlets and the container. As a result
     the portal should be short on bells and whistles and have an
     extremely low cost of entry to encourage users to join the community.
     <ul><li><H5>Removal of Aggregation/Fragment frameworks</H5>
         Because the portal is not intended to be a full portal
         implementation, it is not necessary for Pluto to provide
         it's own templating implementation.  By simply allowing
         a single resource to be defined which renders the portal
         layout and renders portlets using custom tags, the driver
         is able to provide an extremely simple layout facility while
         at the same time allowing the flexibility of using a more
         complex templating agent (the single resource may be a
         servlet, jsp, etc. . .which invokes the agent).</li>
         <li><H5>Consolidation of Configuration Files</H5>
         Instead of defining configuration in several files, all
         configuration is completed through a single xml file.</li>
         <li><H5>Removal of Duplicated Configurations</H5>
         A couple of different configurations are defined in multiple
         configuration files.  The reimplementation removes these.
         </li></ul>
 </P>
 </subsection>
 </section>

 </body>
 </document>
	<?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 H. DeWolf</author>
	<title>Differences Pluto 1.1 vs Pluto 1.0.1</title>
	</properties>

	<body>
	<section name="Document Overview">
	<P>
	This document attempts to describe the differences between
	Pluto 1.0.x and Pluto 1.1. It seeks to define both the
	architectural and design changes along with the reasons why
	each decision was made.

	<subsection name="Table of Contents">
	<P>
	<ul><li><A href="#Overview_of_Changes">Overview of Changes</A></li>
	<li><A href="#Project_Modules">Changes by Project Module</A>
	<ul><li><A href="#Embedder_Interface">Embedder Interface</A></li>
	<li><A href="#Container_Simplification">Container Simplification</A></li>
	<li><A href="#Portal_Driver">Portal Driver</A></li></ul>
	</li></ul>
	</P>
	</subsection>
	</P>
	</section>

	<section name="Overview of Changes">
	<P>
	The Pluto 1.1 branch is a refactoring and reimplementation of the
	originally donated codebase (which was originally released as
	Pluto 1.0). While this codebase met the requirements of Portlet
	Specification, it was found by the community to be clumzy and
	complex. As a result, Pluto 1.1 aims to take a semi-revolutionary
	approach which follows best practices and a more traditional design.
	</P>
	<P>
	The semi-revolutionary approach can be considered both a refactoring
	and a rewrite due to the fact it originally leveraged Pluto 1.0.1
	implementations where-ever possible without jeopordizing the
	community's intention to simplify integration.
	</P>
	<P>
	The following are the high level considerations which were the goal
	of the development of Pluto 1.1 seed code.
	<ul><li>Simplify the container, driver, and deployer in order
	to encourage increased participation in our community.</li>
	<li>Reduce the cost of entry required to start using and developing
	portlets with pluto.</li>
	<li>Reduce the complexity of embedding pluto into a portal.</li>
	<li>Use common best practices and design patterns to reduce
	the cost of entry for contributions.</li></ul>
	</P>
	</section>

	<section name="Project Modules">
	<subsection name="Embedder Interface">
	<P>
	The simplification of the interface used to integrate pluto into
	a portal involves the following:
	<ul><li><H5>Creation of a well defined Integration Interface</H5>
	The Pluto 1.0.x Container Services interface defines a
	single method from which services can be retrieved
	(by class). This led to some confusion as to which
	services were required.</li>
	<li><H5>Usage of a Container Approach</H5>
	Instead of continually invoking pluto through a static
	interface, a container instance (which has a well
	defined interface) is created and returned upon instantiation.
	This reference is then used from there forward to invoke the
	container. Additionally, this approach allows us to hide
	the underlying container implementation. A container now
	has the following lifecycle:
	<P>
	<pre>
	// Initialization

	String name = // the container name
	ServletContext context = // the portal's context
	PortletContainerServices services = // the portal's implementation

	PortletContainer container =
	PortletContainerFactory.createContainer(name, services);
	container.init(servletContext);


	// Action Processing
	container.doAction(portletWindow, request, response);


	// Render Processing
	container.doRender(portletWindow, request, response);


	// Destruction / Shutdown
	container.destroy();
	</pre>
	</P>
	Besides the container services, no other implementation details are needed
	by the portal.
	</li>
	<li><H5>Removal of unecessary services.</H5>
	Pluto 1.0.x allowed an overwhelming number of services/
	factories to allow for unlimited flexibility. Some of
	these services/factories are unecessary as they allow
	for so much flexibility that in fact you are no longer
	using the container (see PortletInvoker). The removal
	of this incredible flexibility allows for a simplified
	integration AND simplification of the container.</li>
	<li><H5>Migration of Deployment Descriptor consumption to container</H5>
	By moving the responsibility of consuming the deployment
	descriptor to the container, implementers have one less
	responsibility. Additionally, the PortletWindow interface
	is able to become much simpler.</li></ul>

	</P>
	</subsection>

	<subsection name="Container Simplification">
	<P>
	The considerations for simplifying they container are as follows:
	<ul><li><H5>Dependency Injection</H5>
	The use of dependency injection throughout the
	container will allow for the removal of several
	factories and, perhaps most importantly, the removal
	of the necessity of ThreadLocal's for lookup of
	services.</li>
	<li><H5>Usage of Internal Objects</H5>
	By removing unecessary services it becomes possible to
	pass references by specific implementation instead of
	interface. This reduces the converstions (i.e. from
	ActionRequest to InternalActionRequest) that are required
	and allows the container to be a little more intelligent
	about it's environment.
	</li></ul>
	</P>
	</subsection>

	<subsection name="Portal Driver">
	<P>
	The Pluto Portal Driver is intended to provide an example of how to
	imbed pluto and perhaps even more importantly, provide a wrapper
	which can be used to test portlets and the container. As a result
	the portal should be short on bells and whistles and have an
	extremely low cost of entry to encourage users to join the community.
	<ul><li><H5>Removal of Aggregation/Fragment frameworks</H5>
	Because the portal is not intended to be a full portal
	implementation, it is not necessary for Pluto to provide
	it's own templating implementation. By simply allowing
	a single resource to be defined which renders the portal
	layout and renders portlets using custom tags, the driver
	is able to provide an extremely simple layout facility while
	at the same time allowing the flexibility of using a more
	complex templating agent (the single resource may be a
	servlet, jsp, etc. . .which invokes the agent).</li>
	<li><H5>Consolidation of Configuration Files</H5>
	Instead of defining configuration in several files, all
	configuration is completed through a single xml file.</li>
	<li><H5>Removal of Duplicated Configurations</H5>
	A couple of different configurations are defined in multiple
	configuration files. The reimplementation removes these.
	</li></ul>
	</P>
	</subsection>
	</section>

	</body>
	</document>