You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by "Luta, Raphael (VUN)" <Ra...@groupvu.Com> on 2002/11/04 20:00:41 UTC
[Proposal] PortletTool and changes in Registry format.
[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 jetspeed-dev@jakarta.apache.org*]
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 - raphael.luta@groupvu.com
Principal Consultant - Technology and New Initiatives
Vivendi Universal Networks - Paris
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] PortletTool and changes in Registry format.
Posted by Mark Orciuch <ma...@ngsltd.com>.
Raphael,
Is there any special reason to include this in the release? I don't think
this functionality was "promised" on the TODO list so we wouldn't be
excluding anything we planned for the release.
I agree with David on the issue of backwards compatibility but I do like
your *elegant* idea of "conversion" service (we should create a pattern
here). Still we would be introducing a risk factor 6 days before target date
so my vote is to wait.
Other than that, I think it is a much needed feature and I can't wait to see
some working examples.
Best regards,
Mark C. Orciuch
Next Generation Solutions, Ltd.
e-Mail: mark_orciuch@ngsltd.com
web: http://www.ngsltd.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Proposal] PortletTool and changes in Registry format.
Posted by David Sean Taylor <da...@bluesunrise.com>.
> -----Original Message-----
> From: Luta, Raphael (VUN) [mailto:Raphael.Luta@groupvu.Com]
> Sent: Monday, November 04, 2002 11:01 AM
> To: 'jetspeed-dev@jakarta.apache.org'
> Cc: 'jetspeed-user@jakarta.apache.org'
> Subject: [Proposal] PortletTool and changes in Registry format.
>
>
> 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.
Why is that?
>From VelocityPortlets, as we know the wall between actions and portlets
creates great difficulties for developers.
Are we going to create the same kind of problem here?
>
> 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.
-1
IMO, No backward compatibility issues should be introduced at this time
Couldn't you achieve the same goal by not invalidating the old format?
> 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.
>
I guess the first question that comes to mind is will this impact the
release schedule.
Do you plan on getting these features in by Nov.11?
If existing registries will be invalidating, -1 on including this in the
next release.
Otherwise, it seems like a lot of work and possible destablilization.
I would like to hear more about how this fits into the release schedule.
Mark has contributed a lot feature work in this last iteration. I think we
should put out a stable release concentrating on his contributions, the
migration to Torque and Turbine releases, bug fixes, better docs and as you
mentioned, a better out-of-the-box website.
Portlet Applications and sharable Portlet Tools are very much needed
additions. I could see how this would make Database browsers/edit forms a
lot easier.
Do you think these features should go into the next release?
What do others think, do we need a release by next week or do we want to
push back the release to give Raphael time to finish the Portlet Tool and
Portlet Application features....
David
David
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>