gridsphere

A portlet is a Java technology based web component, managed by a portlet container, that processes requests and generates dynamic content. Portlets provide a presentation layer to Information Systems.

Portlets generate fragments of markup (e.g. HTML, XHTML, WML). A portal combines markup fragments generated by different portlets into a portal page.

A portlet container manages the lifecyle of portlets. It also provides the required runtime environment.

Portlets are bundled in Portlet Applications as web applications using the WAR file format. A portlet application consists of two deployment descriptors: one to specify the web application resources (web.xml) and one to specify the portlet resources (portlet.xml).

Click here for an example of a portlet resources deployment descriptor (portlet.xml).

Portal layout components are the visual graphical components that get displayed to a client consisting of presentation information in an appropriate markup language (currently just HTML).

Portal components are typically defined in an XML schema known as layout.xml and unmarshalled to Java objects using the Castor java data binding libraries.

All layout components implement a {@link org.gridsphere.layout.ComponentRender} interface responsible for rendering the presentation content. In addition, most concrete portal components implement a {@link org.gridsphere.layout.ComponentLifecycle} interface responsible for handling all component lifecyle methods such as initialization, shutdown, and performing actions.

GridSphere supports two pluggable look and feels (PLAF)s: classic {@link org.gridsphere.layout.view.classic} and standard {@link org.gridsphere.layout.view.standard} The classic PLAF remains the old (GS 2.1.2 and earlier) look and feel using a combination of nested tables and some CSS. The current default PLAF is standard which is evolving towards a much more configurable pure CSS layout. Each PLAF supports multiple themes inside each of the PLAF subdirectories. If you are interested in developing a new theme, please use the standard PLAF and have a look at the CSS files.

The current list describes the concrete portlet components that are in use:

• {@link org.gridsphere.layout.PortletFrame}
• {@link org.gridsphere.layout.PortletTableLayout}
• {@link org.gridsphere.layout.PortletColumnLayout}
• {@link org.gridsphere.layout.PortletRowLayout}
• {@link org.gridsphere.layout.PortletContent}
• {@link org.gridsphere.layout.PortletTab}
• {@link org.gridsphere.layout.PortletTabbedPane}
• {@link org.gridsphere.layout.PortletContent}
• {@link org.gridsphere.layout.PortletTitleBar}

Just like in AWT or Swing libraries, portal layout components can receive events by implementing a listener.

The current component events are:

• {@link org.gridsphere.layout.event.PortletFrameEvent}
• {@link org.gridsphere.layout.event.PortletTabEvent}
• {@link org.gridsphere.layout.event.PortletTitleBarEvent}

The corresponding listeners are:

• {@link org.gridsphere.layout.event.PortletFrameListener}
• {@link org.gridsphere.layout.event.PortletTabListener}
• {@link org.gridsphere.layout.event.PortletTitleBarListener}

Just like in AWT or Swing libraries, portlet layout components can receive events by implementing a listener.

The current component event implementations are:

• {@link org.gridsphere.layout.event.impl.PortletFrameEventImpl}
• {@link org.gridsphere.layout.event.impl.PortletTabEventImpl}
• {@link org.gridsphere.layout.event.impl.PortletTitleBarEventImpl}

GridSphere supports two pluggable look and feels (PLAF)s: {@link org.gridsphere.layout.view.classic} and {@link org.gridsphere.layout.view.standard} The classic PLAF remains the old (GS 2.1.2 and earlier) look and feel using a combination of nested tables and some CSS. The current default PLAF used by the layout components is the 'standard' PLAF which is evolving towards a much more configurable pure CSS layout.

The PLAF interfaces define the bare minimum required by the concrete look and feel classes. The {@link org.gridsphere.layout.view.Render} interface defines 4 methods: doStart, doStartBorder, doEndBorder and doEnd as we determined that these four methods seem to satisfy the majority of our currently used layout components. Layout components that have no border would simply return empty. To make it easier, a base class {@link org.gridsphere.layout.view.BaseRender} implementing the Render interface is provided for PLAF developers to use.

The current list describes the concrete portlet components that are in use:

• {@link org.gridsphere.layout.view.Render}
• {@link org.gridsphere.layout.view.BaseRender}
• {@link org.gridsphere.layout.view.FrameView}
• {@link org.gridsphere.layout.view.TabbedPaneView}
• {@link org.gridsphere.layout.view.TableLayoutView}

The Portlet Services API is an implementation based upon the GridLab Portal Technical Specification. The Portlet Services API presented was based originally on the IBM WebSphere Portlet API 4.1 (which in turn was based on the Jakarta Turbine-2 services model).

The two primary differences in the GridSphere Portlet Service API and the WebSphere 4.1 API are:

1. The use of an XML schema for defining portlet services as opposed to a plain text properties file

An example portlet service descriptor file is the following:

<portlet-services>

<service>
    <name>Portlet Manager Service</name>
    <description>Provides Administration Capabilities for Portlet Web Applications</description>
    <interface>org.gridsphere.services.core.registry.PortletManagerService</interface>
    <implementation>org.gridsphere.services.core.registry.impl.PortletManagerServiceImpl</implementation>
    <service-config>
        <param-name>coreContext</param-name>
        <param-value>gsmanager, coreportlets, gridportlets</param-value>
    </service-config>
</service>


<service>
    <name>Login Service</name>
    <description>Provides Login Capabilities</description>
    <interface>org.gridsphere.services.core.user.LoginService</interface>
    <implementation>org.gridsphere.services.core.user.impl.LoginServiceImpl</implementation>
</service>


...

The following definitions are used in defining a portlet service:

• portlet name - the portlet name
• description - a description of the portlet service
• interface - the portlet service interface class
• implementation - the portlet service implementation class
• service-config - specifies additional configuration requirements of the portlet service
• param-name - specifies an initialization parameter name
• param-value - specifies an initialization parameter value

All interfaces in this Service Provider Interface (SPI) package are needed by all implementations of services.

The key interfaces included in the SPI API are:

• {@link org.gridsphere.portlet.service.spi.PortletServiceFactory} - provides a service factory interface
• {@link org.gridsphere.portlet.service.spi.PortletServiceConfig} - provides a service configuration interface
• {@link org.gridsphere.portlet.service.spi.PortletServiceProvider} - provides a service provider interface for service initialization and shutdown

The SPI implementation uses Castor for XML to Java data bindings.

The key interfaces included in the SPI API are:

• {@link org.gridsphere.portlet.service.spi.PortletServiceFactory} - provides a service factory interface
• {@link org.gridsphere.portlet.service.spi.PortletServiceConfig} - provides a service configuration interface
• {@link org.gridsphere.portlet.service.spi.PortletServiceProvider} - provides a service provider interface for service initialization and shutdown

The SPI implementation uses Castor for XML to Java data bindings for the following classes:

• {@link org.gridsphere.portlet.service.spi.impl.descriptor.SportletServiceCollection}
• {@link org.gridsphere.portlet.service.spi.impl.descriptor.SportletServiceDefinition}
• {@link org.gridsphere.portlet.service.spi.impl.descriptor.SportletServiceDescriptor}

The GridSphere portlet container is responsible for the dynamic management of {@link org.gridsphere.portletcontainer.PortletWebApplication}s. A portlet web application is a collection of portlets packaged as a WAR file. Portlets are defined by a portlet descriptor file, web.xml located in the WEB-INF directory of the portlet web application. The porlet descriptor file defines one or more application portlets defined in {@link org.gridsphere.portletcontainer.ApplicationPortlet} each of which may have one or more concrete portlet definitions as defined in {@link org.gridsphere.portletcontainer.ConcretePortlet}. Both the application portlet and concrete portlet have configuration settings that are defined in the {@link org.gridsphere.portletcontainer.ApplicationPortletConfig} and the {@link org.gridsphere.portletcontainer.ConcretePortletConfig} respectively.

All portlets including the portlet web applications are registered with the {@link org.gridsphere.portletcontainer.PortletRegistry}, a singleton used by other components to request information about portlets and obtain a {@link org.gridsphere.portletcontainer.impl.SportletDispatcher}, which is used to invoke a lifecyle method on a chosen portlet. To make portlet invocation easy, the {@link org.gridsphere.portletcontainer.PortletInvoker} offers static methods that are essentially wrappers around the PortletDispatcher.

The GridSphere portlet container is implemented as the master {@link org.gridsphere.servlets.GridSphereServlet} servlet which receives all requests to the portal and is responsible for generating a {@link org.gridsphere.portletcontainer.GridSphereEvent} which is passed to the layout components for rendering the portal presentation.

The {@link org.gridsphere.portletcontainer.PortletDataManager} and {@link org.gridsphere.portletcontainer.PortletMessageManager} are singletons used to manage persistent {@link org.gridsphere.portlet.PortletData} and {@link org.gridsphere.portlet.PortletMessage} information respectively.

The GridSphere portlet container implementation provides implementations of the portlet container interfaces. The implementation makes use of the Castor portlet descriptor classes found in {@link org.gridsphere.portletcontainer.impl.descriptor} and uses singleton patterns for the implemtation of the {@link org.gridsphere.portletcontainer.PortletMessageManager} and {@link org.gridsphere.portletcontainer.PortletDataManager} classes.

The visual beans library provides a collection of user interface components that wrap existing HTML elements and provides a more object oriented approach to creating web page presentations, similar to the Java Server Faces (JSF) API. The following visual beans are provided:

• {@link org.gridsphere.provider.portletui.beans.ActionParamBean}
• {@link org.gridsphere.provider.portletui.beans.ActionLinkBean}
• {@link org.gridsphere.provider.portletui.beans.ActionSubmitBean}
• {@link org.gridsphere.provider.portletui.beans.CheckBoxBean}
• {@link org.gridsphere.provider.portletui.beans.FileInputBean}
• {@link org.gridsphere.provider.portletui.beans.FrameBean}
• {@link org.gridsphere.provider.portletui.beans.HiddenFieldBean}
• {@link org.gridsphere.provider.portletui.beans.ImageBean}
• {@link org.gridsphere.provider.portletui.beans.ListBoxBean}
• {@link org.gridsphere.provider.portletui.beans.PanelBean}
• {@link org.gridsphere.provider.portletui.beans.PasswordBean}
• {@link org.gridsphere.provider.portletui.beans.RadioButtonBean}
• {@link org.gridsphere.provider.portletui.beans.TableBean}
• {@link org.gridsphere.provider.portletui.beans.TableRowBean}
• {@link org.gridsphere.provider.portletui.beans.TableCellBean}
• {@link org.gridsphere.provider.portletui.beans.TextBean}

The Model beans provide data storage classes used by the visual beans library. The following models are supported:

• {@link org.gridsphere.provider.portletui.model.DefaultListModel}
• {@link org.gridsphere.provider.portletui.model.SelectListModel}
• {@link org.gridsphere.provider.portletui.model.DefaultTableModel}

The GridSphere UI Tag Library provides a collection of visual tags used to represent stylized HTML elements. Please consult the tutorials and slides from the GridSphere website for more information. The following tags are provided:

• {@link org.gridsphere.provider.portletui.tags.ActionFormTag}
• {@link org.gridsphere.provider.portletui.tags.ActionLinkTag}
• {@link org.gridsphere.provider.portletui.tags.ActionParamTag}
• {@link org.gridsphere.provider.portletui.tags.ActionSubmitTag}
• {@link org.gridsphere.provider.portletui.tags.CheckboxTag}
• {@link org.gridsphere.provider.portletui.tags.FileFormTag}
• {@link org.gridsphere.provider.portletui.tags.FileInputTag}
• {@link org.gridsphere.provider.portletui.tags.FrameTag}
• {@link org.gridsphere.provider.portletui.tags.HiddenFieldTag}
• {@link org.gridsphere.provider.portletui.tags.ImageTag}
• {@link org.gridsphere.provider.portletui.tags.ListBoxTag}
• {@link org.gridsphere.provider.portletui.tags.ListBoxItemTag}
• {@link org.gridsphere.provider.portletui.tags.PanelTag}
• {@link org.gridsphere.provider.portletui.tags.PasswordTag}
• {@link org.gridsphere.provider.portletui.tags.RadioButtonTag}
• {@link org.gridsphere.provider.portletui.tags.TableTag}
• {@link org.gridsphere.provider.portletui.tags.TableRowTag}
• {@link org.gridsphere.provider.portletui.tags.TableCellTag}
• {@link org.gridsphere.provider.portletui.tags.TextAreaTag}
• {@link org.gridsphere.provider.portletui.tags.TextFieldTag}
• {@link org.gridsphere.provider.portletui.tags.TextTag}

The Validator classes are currently under development.

{@link org.gridsphere.services.core.mail.MailMessage} is used to construct an e-mail that may be sent using the {@link org.gridsphere.services.core.mail.impl.MailServiceImpl}.

Underlying functionality provided by Sun JavaMail API.