[This mail is a formal proposal for an idea I've already formulated
on dev@ a few days ago. I've CC'ed the user mailing-list as this change
may have a large impact on development and create a backward-compatibility
issue.
*All responses should go to [EMAIL PROTECTED]*]
Summary:
------
For legacy reasons, Jetspeed Portlet objects have a request based scope that
severaly limits their effectiveness for creating new reusable components
accessing expensive resources like databases, etc...
This proposal aims to fix this issue by promoting a new portlet development
model inspired from Turbine "pull" methodology: PortletTool.
This proposal presents several implementation options and their likely
impact
in term of backward compatibility.
PortletTool:
-----------
A PortletTool is a Java component handling a business functions that can be
used
within any Jetspeed Portlet or JetspeedController.
It's typically used in conjunction with a VelocityPortlet or JSPPortlet
instance to
provide a MVC portlet development model.
Example:
A typical Portlet using PortletTools would be composed of:
- Model: a set of PortletTool encapsulating the business logic and data
manipulated by the portlet.
- a set of Velocity/JSP templates that are used to present the data and
interact
with the user (view)
- a PortletAction that would control the interaction with the user and the
flow
of processing within a session (controller)
The Portlet itself would be defined through a Registry entry that would
declaratively
bind the different components between them.
Simple Example:
<portlet-entry name="DBVelocity" parent="CustomizerVelocity">
<template mode="normal">dbmaster</template>
<template mode="edit">dbcustomize</template>
<template mode="maximized">dbdetail</template>
<action>portlets.DBAction</action>
<tool>
<name>db</name>
<class>tools.DBTool</class>
<scope>session</scope>
<parameter name="pool" value="sampledb"/>
<parameter name="table" value="beans"/>
<tool>
<parameter name="sortOrder" value="asc"/>
<media-type ref="html"/>
<category>demo</category>
<category>velocity.demo</category>
</portlet-entry>
A PortletTool need to implement the following interface:
interface PortletTool
extends org.apache.turbine.services.pull.ApplicationTool
{
public void setConfig(ToolConfig);
public void destroy();
}
This gives the PortletTool the following lifecycle:
- instanciation
- setConfig()
- init()
- any business calls
- refresh()
- destroy()
[PortletTool = Configurable + Initable + Disposable interface in Avalon
parlance]
A PortletTool has a life scope similar to the Turbine and have the same
additionnal constraints based on these scope, ie:
- request -> no constraints
- session/persistent -> should be thread safe, must be serializable
- global -> must be thread safe
A PortletTool may only access parameters that are tied to this tool and
*may not* access portlet parameters if any.
These PortletTool components will be managed by a new PortletToolService
that
will responsible for:
- loading all the PortletTools with a "global" scope on webapp startup.
One instance of these tools will be created per registry definition
encountered
- load all the "session", "persistent", "request" tools required to process
a
specific PSML page, ensuring the "session" and "persistent" tools are
correctly
maintained though out the session and/or persisted
- refresh the relevant tools if a Registry entry has changed
- dispose/pool/recycle the tools when appropriate
Impact
------
As is, this proposal will mainly impact 3 areas of the Jetspeed:
- registry markup: to be coherent with the <tool>, it would be appropriate
to
"upgrade" the current "action" and "template" parameters as standalone
tags.
This will impact all current entry defintions relying on these parameters
- customization: since tools will have their own parameters, the customizer
must
be modified to allow customization of all parameters of user or request
scope.
However, it must *not* allow customization of "global" tools which can be
shared
by several users
- configuration: admin configuration of the Registry entries need to
recognize the
new tags <tool>, <action> and <template>.
Of all these impacts, only the first creates backward compatibility issues.
This could
be either avoided by not changing the action and template parameter format
or
OTOH, use a parameter format to codify the tools properties, ex:
<parameter name="tool.request.test" value="tools.DBTool" />
<parameter name="tool.request.test.myparam" value="param1" />
I feel this is an awkward compromise.
Note that the compatibility issue can be mitigated by providing a
"conversion" service
executed once by the RegistryService before loading a Registry fragment.
PortletApplication
------------------
To be really effective, the tools should be shared among portlets working
together
to provide a versatile base of functionality, but Jetspeed currently does
not define
any association of portlet behaving together as a "portlet application".
Such an application is only a placeholder providing a name and a set of
tools to share
between all the portlets belonging to this application.
To define such an application, it would be possible to extend the registry
markup so
that a portlet entry may be contained within a portlet application. All
portlets that are
not defined within a named application are considered to be implicitely
within their
own applications, thus sharing no information with other portlets.
ex
<registry>
<portlet-application name="myapp">
<!-- Tools shared by all portlets of application -->
<tool/>
<tool/>
<portlet-entry>
<template/>
<action/>
<tool/>
</portlet-entry>
</portlet-application>
</registry>
Any feedback appreciated.
--
Rapha�l Luta - [EMAIL PROTECTED]
Principal Consultant - Technology and New Initiatives
Vivendi Universal Networks - Paris
--
To unsubscribe, e-mail: <mailto:jetspeed-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-user-help@;jakarta.apache.org>
