[This is the first mail of (hopefully) a series whose purpose is
to define a new layout system for jetspeed, compatible with the
current project goals. These mails will try to provide a basis
for comments and discussion which should ultimately deliver a
workable implementation prposal]
Context
-------
The current layout model is currently based on the Portlet class
which has a dual purpose: "plugin" component model root class and
layout component root class. This lead to the Portlet class to
define both "plugin" oriented methods and layout oriented model,
creating a complex class hierarchy and tying the 2 models together.
Jetspeed 1.3 wants to provide a portal implmentation independant
plugin component model (the new Portlet API) and thus we need to
completely rethink the layout model.
Characteristics of the current system
-------------------------------------
This is for the benefit of the people on the list who never tried
to look into the org.apache.jetspeed.portal package. It lists a few
characteristics/shortcomings of the currrent model that may be useful
to carry other/fix in the new model.
[ All design patterns I'll refer to are those defined by the GO4 book
"Design Patterns", Gamma and al. If you haven't read it yet, you
should.]
- The model is based on a Composite pattern, Portlet being the root
component.
- It uses 4 classes:
* Portlet: root component element defining the getContent(RunData)
"draw" method.
* PortletSet: base portlet container class. Each portlet is associated
with a set of layout constraints (stored in the PortletConfig object
of the Portlet: very bad). The actual layout of these elements is
delegated to a PortletController class, in a classic "strategy"
pattern implementation.
* PortletController: defines the layout strategy for a collection
of Portlets contained in a PortletSet. (very similar to the
Container/Layout relation in AWT)
* PortletControl: this class is where the ambiguity of the model shows.
It is both a wrapper around portlet element providing control, state
and meta-data information (mainly because of historical reasons)
and a "decorator" around the portlet. Its implementation is very
awkward.
- The lifecycle of all the layout objects is request based (except
Portlet because it's also part of the plugin component model). This
leads to a lot of object instanciation/destruction and poor performance.
- The layout description is easily customizable because the
PortletController classes handle all the aggreagation logics. However the
lack of unique identifiers in the layout components makes it difficult to
link customization information with a given component (the request based
lifecycle doesn't help neither).
- The layout is driven by a PSML file, which is persisted description of
the layout object hierarchy. The description is currently only expressed
in XML. The reconstruction process is the following:
* The PSML XML description file
| (Castor unmarshalling)
v
* The Castor generated API (autogenerated from /src/xml/psml.xsd into
org.apache.jetspeed.xml.api.portletmarkup.*)
| (org.apache.jetspeed.factory.*)
v
* The Portlet object hierarchy.
This is complicated by the fact that Portlet objects are created from
the system registry definitions (which is part of the plugin component
mode, not the layout) is a similar but more complex fashion:
* The JetspeedConfig XML descrioption file
| (Castor unmarshalling)
v
* The Castor generated API (from /src/xml/jetspeeed-config.xsd) into
org.apache.jetspeed.xml.api.jetspeedconfig
| (org.apache.jetspeed.om.registry.peer.*)
v
* A special peer class hierarchy with specific inheritance between
classes that Castor could not automatically generate. Maybe new
version can generate these relations now
| (org.apache.jetspeed.factory.PortletFactory)
v
* An instanciated Portlet.
Again the duality of purpose of Portlet leads to unecessary
complications.
- PSML can be thought out of a "pull" templating system in Turbine
where org.apache.jetspeed.portal is the template engine
implementation
(see http://java.apache.org/turbine/ or Turbine mailing-list
for more info on "pull" vs "push").
The main shortcoming of this template engine is that its display
element are not easily configurable (ECS encoded layouts in the
different PortletControllers, PortletControls).
The Profiler is sort of a smarter RunData.getTemplateInfo().
Design goals for the new system
-------------------------------
- Independent of the Portlet component model
- Customizable
- Multi-device support (with either spatial or temporal
aggregation)
- Fully leverage Turbine layout features, especially
template support
- High performance
[To be continued, I think I'll have part 2 completely written
tomorrow evening]
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
