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).
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 :
|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 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)
The scheme proposed to work on portlet development in WebLab consists on few steps, which can be briefly describe as:
- 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.
- 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.
- Packaging will adapt the compiled code to the web server.
- Deployment of the Portlet on the portal.
- 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.