Early on it became apparent that a standard way of subscribing to content
and managing its presentation was needed.
Portlet goals:
- have multiple but small web applications available to the user.
- "skin" these web applications so that users can choose the background
color, title bar color, icons, etc.
- maintain performance across multiple Portlets by providing a caching
subsystem
- keep track of all available web applications and present them to the
user
-
Easily choosen by the user so that custom page generation is very easy. They
are very similar to Turbine Screens except that you can have muliple Portlets
within any given screen.
-
Fast with a caching subsystem. This allows even complex Portlets that use
databases to render HTML fast.
-
Easily developed and doesn't require the developer to know the implementation
details of the Engine (Jetspeed) that his Portlet is running under.
-
Portlets allow other types of content renderers. A portlet could use the
facilities of a database via JDBC or complex XML -> XSL -> HTML rendering via
something like Cocoon.
-
Portlets allow themselves to be skinned so that the user can change the
background color or the width of the Portlet or the color of the title bar.
-
Portlets are managed by a PortletController. This controller is
implementation specific and can be changed by a developer to provide custom
rendering.
-
Portlets are rendered and held by a PortletControl. A PortletControl adds
the skin to the Portlet and then returns it's content.
-
Category based subscription. The XML subscription framework within JetSpeed
will allow portlets (via Portlet Markup Language) to be organized into
categories. This allows easy management of portlets.
-
Portlets are passed a PortletConfig object which includes a URL and a
hashtable of parameters. This way a Portlet can adapt its configuration
during runtime by observing its PortletConfig.
-
Easy to write as an AbstractPortlet defines most of it's behavior in most
situations.
A example of portlet could be a small little control that runs within a web page
and allows the user to query an LDAP server for a set of phone numbers. This
could be developed outside of Jetspeed and snapped into the framework by
modifying an XML file to point in its direction. Developing your own
Portlets is easy and is really just a matter of implementing the "Portlet"
interface, providing custom implementations of the Portlet's methods.
A Portlet may also be setup so that it is a Web Applications. Portlets that
are configured as applications (getApplication() == true) only run as full
screen. You can't have multiple "Portlications" (Portlet Applications) on
screen at once. They can be accessed by the user at any time though via the
navigation features of Jetspeed.
Portles are provided with a PortletConfig that can be used from within a Portlet
to determine runtime configuration information. The Portlet can get parameters
it was given to modify its behavior. All the normal Servlet parameters
ServletRequest, ServletResponse, or Turbine RunData.
Jetspeed ships with a few Portlet implementations:
RSSPortlet -
Renders RDF Site Summary format and presents it to the user as HTML.
FileServerPortlet -
Serves up an HTML document to the user from a URL.
CocoonPortlet -
Takes a stylesheet and a url as parameters and transforms it with
Cocoon and then returns the content to the user.
PortletViewerPortlet -
Provides a way for the user to obtain additional information about
a Portlet including it's configuration options, URL, and properties.
It should also be possible to include additional options here such
as replication with 3rd party resources (currently Avantgo).