----- Original Message -----
From: "ingo schuster" <[EMAIL PROTECTED]>
> Currently, portlets don't have a possiblility to "behave" according to
> parameters that are specific to a certain user. For example: a stock
> watchlist portlet needs to be customizable so that it displays those stock
> symbols that the user is interested in.
> Parameters like this could be stored in the <entry> section of user.psml
as
> name/value pairs. E.g:
>
> <entry type="ref" parent="StockWatchlist">
> <layout position="3"/>
> <parameter name="symbol1" value="SUN"/>
> <parameter name="symbol2" value="IBM"/>
> </entry>
>
> This can already be done today, the parameters also get unmarshaled
> correctly and find their way into the "Protlets-tree". However, when the
> PortletSetFactory converts this object tree into a "PortletSet-tree", the
> portlet parameters are simply ignored.
> Now, there is actually no good place to put them at the moment:
> PortletConfig shouldn't be user specific as it exists only once per
portlet
> and PortletControlConfig holds the PortletControl's parameters.
> I think, that if a PortletControl holds a portlet and not a PortletSet, it
> should store the portlets (user) parameters and pass them along with the
> getContent method.
> In more detail, this could look like follows:
> * A PortletControl has an additional field "PortletUserConfig" that holds
> the user-specific portlet settings. PortletUserConfig could be a new
object
> or just a ParameterParser.
> * When the PortletSetFactory "converts" the "Portlets-tree" into a
> "PortletSet-tree" it takes the portlet parameters and stores them in this
> PortletUserConfig.
> * The Portlet's getContent(Rundata rundata) method is changed to
> getContent(Rundata rundata, PortletUserConfig portletUserConfig);
>
> Does this sound sensible?
good, but perhaps we can derive RunData to JetspeedRunData and include the
needed data there. The JetspeedRunData idea was mentioned from Raphael to
solve problems with request-sensitive data in PortletConfig.
Stephan
--------
<snip>
> Thomas F. Boehme write:
> With regard to multi-threading issues, I think there is more than the
> caching system that needs to audited.
> Santiago removed the RunData from PortletConfig the other day, but there
is
> still stuff left in the PortletConfig
> that definitely does not belong there. Stephan Hesmer is looking into that
> right now.
>
Yes it's true. PortletConfig contains contextual informations which have
a different scope form either the request (it may persist between request),
the user session (it may be shared by several sessions) or the portlet
(it will change in the lifetime of the portlet).
One proper way to do it:
- subclass RunData in JetspeedRunData and add the contextual methods
directly in this subclass or in a context object stored in RunData
- when parsing the PSML store all the contexts in the PortletSets
in a Hashtable using the Portlet object as a key.
- in the PortletSet getContent() modify the RunData context before
calling Portlet.getContent().
This require to take some precautions in the RunData modifications and
may impose some change in the PortletControl API (which is the weakest
part of the implementation anyway).
<snip>
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
