WebLab user interfaces

In the WebLab platform, all user interfaces (GUIs) are built using Portlets. One can understand the Portlet concept as follows:

“Portlets are pluggable user interface software components that are managed and displayed in a web portal. Portlets produce fragments of markup code that are aggregated into a portal. Typically, following the desktop metaphor, a portal page is displayed as a collection of non-overlapping portlet windows, where each portlet window displays a portlet. Hence a portlet (or collection of portlets) resembles a web-based application that is hosted in a portal. Some examples of portlet applications are email, weather reports, discussion forums, and news.” (Wikipedia).

They are defined by JSR-286, the Java Portlet API 2.0[1]. The recommended portal in WebLab is Liferay[2] because of its strong reliability and compliance with the JSR.

Portals and Portlet architecture

Here is an overview of that is useful to understand the concept below:

• Portals: An HTTP-based site hosted with special portal software that allows the aggregation of several different back-end systems, processes, or sites brought together through a single portal page. Portals may provide additional services such as single sign-on security, customisation, personalisation, and back-end administrative/declarative application development.
• Content aggregation: The process of bringing together content from disjointed systems, via portlets, and controlled through the use of a portal.
• Portlet container (PC): Controls the access, lifetime, and interaction of a single portlet. Provides the content returned from a portlet back to the portal for merging with the content of other portlets.
• Portlet: Provides content to its calling portal container for the purposes of being displayed on a portal page.
• Fragments: The content generated by a portlet is known as its fragment or fragment code. This is the HTML or XML code generated from the portlet rendering code.
• WSRP : Is a technology that enable portals to access remote portlets even developed in other languages (PHP, C#, etc.) thanks to an XML serialisation/de serialisation mechanism

Portlet vs Servlets

The portlets are an extension of the servlet specification. As a consequence, it has some common part with servlets and differences :

Simple comparison servlet vs portlet

Feature	Servlet	Portlet
Are J2EE Web Component	yes	yes
Are Managed by Container	yes	yes
Generate dynamic Web content	yes	yes
Generate fragments of pages	no	yes
Are bound to an URL	yes	no
Have two phases processing scheme (action and render)	no	yes
Manage states and modes	no	yes
Alter HTTP headers	yes	no
Access the Referrer URL	yes	no
Allow advanced persistence mechanisms	no	yes
Allow access to user profile	no	yes
Manage scopes at the application and page level.	no	yes

Portlet usage

Portlet Life Cycle

Within a portal, a Portlet has a life-cycle with the following methods:

• init() called just the first time (at deployment or at portal start)
• processAction() called in response to a user action such as clicking a button, hyper-link, submitting a form. In processAction, a Portlet may modify its own state as well as persistent information about a Portlet]
• processEvent() called if there is an event pending for this portlet
• render() generate markup depending on the portlet’s current state. calls doView()
• destroy() called just the last time (at portal shutdown or when undeploying)

Portlet development

The scheme proposed to work on portlet development in WebLab consists on few steps, which can be briefly describe as:

1. UML model of Portlet (cinluding sequence diagram. This should be done as a part of the architecture design. But evolutions can be proposed and should be studied during the whole process in order to test their validity against the application architecture and components interoperability.
2. Implementation and compilation is the main development task and will be addressed by developers. As illustrated, external code and components (libraries, applications...) can be involved in the generated code. Finally, the code is compiled.
3. Packaging will adapt the compiled code to the web server.
4. Deployment of the Portlet on the portal.
5. Test of the Portlet invocation.

As explained, some steps, especially the definitions steps, are partly achieved. Then some others steps can be automated depending on the programming language used. The implementation is where the “work is done” regarding the development since this is where some programming code is written to achieved the Portlet functionality.

WebLab Portlets and WebLab Services

We are in the process of specifying a method to ease access to WebLab Services from WebLab Portlets, see WebLab_user_interfaces/Service_Access_From_WebLab_Portlets.

Exemples

This page lists the various description of existing portlets.