|
AtariX PPL
Portlet Framework |
| |
Several
Portlet implementation approaches are compared. This
comparison is not comprehensive, but introduces rationale
and
This framework
is aimed at providing support to Portlet development, and
specifically to those Portlets that have a constant
variability |
| |
|
|
|
Introduction |
| |
A Portlet is a
Web component that processes requests and generates dynamic
content. Portlet consumers (e.g. a portal) use Portlets as
pluggable user interface components. Typically, a Portlet is
rendered as a window in the portal, the Portlet being a main
building block for portal construction. The recent delivery
of standards, namely,
Web Services for Remote Portlets (WSRP) and
Java
Specification Request 168 promise to bring
interoperability to the Portlet realm. Nothing is said about
how the Portlet should be implemented. However, Portlet
implementation could be quite an issue. Presentation and
even the navigation logic could need to change not only for
maintenance reasons, but also to cater for the
idiosyncrasies of distinct Portals. Therefore, variability,
and thus decoupling, is a main issue in Portlet development.
In contrast to servlet techniques (i.e. modularisation), a
single Portlet needs to implement (1)
control code to determine which action is being
requested, (2) what action
needs to occur, (3) what state
to leave the Portlet in, and (4) what
view (fragment) to render back to the user. Without
appropriate decoupling patterns,
this code can mix up different concerns, making the separate
evolution of each concern a real maintenance problem. This
work revises distinct approaches that gradually achieve
higher levels of decoupling. |
| |
|
|
|
Poster |
| |
 |
| |
This poster is
to be showed at Munich during
ICWE 2004 Poster
Presentations |
| |
|
|
|
Decoupling ...
The Action from the State |
|
Cleaner
Portlet code can be obtained by using the state pattern as
proposed in [Hani02]. A Portlet is modeled as a state
machine where a state is defined for each Portlet fragment,
and arrows are labelled with the actions that achieve the
transition between fragments. A state has an associated view
which in turn, embeds the potential set of actions.
Unfortunately, the control-flowis hard-coded in both actions
and fragments. This pattern facilitates the introduction of
states but offers no help to weave the new states into the
flow of the existing states. |
| |
|
|
|
Decoupling ...
The Action from the View |
|
A step forward
is the use of the Model-View-Controller paradigm, an
evolution of the former where the control logic is decoupled
in a new element, the controller. No information about the
Views is introduced in the action but rather on the
controller definition. Moreover, the flow is described as a
set of Frontend rules: the antecedent expresses a predicate
over the result of an action (i.e. success or error) whereas
the consequent states the next fragment to be rendered (e.g.
flight-Search.jsp). As an example, this approach is followed
by the eXo Portlet Framework (http://www.exoplatform.org).
However, the coupling between the view and the action still
exists. The view contains the distinct actions the End-user
can execute through it, but still a direct mapping from the
views to the actions exists. Indeed, the action-view
dependence is only moved to the controller, and still exists.
No real independence between the Actions and the Views
exists. |
| |
|
|
|
Decoupling ...
The View from the Action |
| |
|
For Portlets to become real components, Portlet
implementation should be engineered to cope with
the changes and variations the Portlet needs to
cope with during its life time. That is, the
Portlet should be built in such a way that the
impact and cost of performing changes will be
minimal. To attain this goal, we propose to
decouple also the view form the action. In
addition to Front-end rules, we introduce Back-end
rules that dictate the actions to be executed
based on the interaction achieved through the
previous view. The controller comprises both
Front-end and Back-end rules, which describe the
whole flow, and neither action nor view contain
a reference to each other, clarifying the
development and reducing the impact of a change. |
Figure: Proposed Model |
|
|
|
|
|
Summary |
|
In brief, as
with any other component, Portlets need to be engineered for
variability. This work describes distinct approaches that
gradually achieve higher levels of decoupling, and hence,
enhance Portlet variability. This effort is part of a wider
endeavour in attempting to apply a product-line approach to
Portlet implementation. |
| |
|
| |
|
|
|
AtariX PPL
Portlet Framework |
|
AtariX PPL
Portlet Framework borns as a natural evolution of current
Portlet development frameworks. Its objective is focused on
provide variability to Portlets. It offers an implementation
for the ideas presented previously.
Currently, there is a prototype implementation that you can
use to implement your Portlets in a very easy way, but at
the present the framework is yet not finished. |
| |
At the present, we offer you the following:
I apologize for the inexistence of proper documentation.
There are plans to overcome this in the nearest future.
However, next we explain you a very simple example for a
flight booking. |
| |
|
|
|
Example |
| |
|
A very simple example of a Portlet to book flights
is implemented with this framework. This Portlet is
maked up by several interactions: search, selection,
summary, purchase and itinerary. |
 |
|
| |
|
|
|
Example -
Structure |
|
The structure
of a JSR 168 Portlet is very similar to that of a J2EE web
application. Detailed following. |
| |
 |
- Portlet Actions: Each Portlet action is implemented by Java
classes:
this classes implements org.atarix.ppl.framework.action.jc.IJavaAction
interface (see
JavaDoc for more details). You have a very simple
action code available:
CheckSearchParams.java.
- Internationalization Properties Files:
contains property files for several locations.
- Logging configuration: log4j logging
configuration. (log4j.properties)
- Portlet Model Files: this files define the
flow control of the Portlet, the actions and the
views. At the present time, only controller and
view is shown:
-
Controller (flightBook-controllers.xml)
-
Actions (flightBook-actions.xml)
- Templates: currently, templates are JSP
pages with a custom tag library in order to
access PPL Framework functionality. They are at
WEB-INF/templates/html
- Tag Librarys: tag library defined by JSR 168
plus tag library defined by PPL Framework (ppl.tld).
- Portlet Descriptor: descriptor defined by
JSR 168 stardard (portlet.xml).
- Web Application Descriptor: descriptor defined by J2EE stardard (web.xml).
|
|
| |
|
|
|
Demo |
|
Currently, there is an
online demo available at http://158.227.114.160/portal.
This demo shows the above example Portlet for Flight Booking within an eXo Portal.
We hope it could be of interest to understand the presented framework. |
| |
|
| |
|
|
|
More
information |
|
This work is
yet being in progress. So, in the future more developments
are expected. Anyways, this is a very very initial prototype
which you can play and enjoy ;-) If you have any suggestion
or want any additional information, please contact us
struji@si.ehu.es . |
| |
|
| |
|
|
|
References |
|
|
| |
|
| |
|
