Raphael,
The problem is not really fixed. Yes, parameters are copied now, but into
PortletConfig which is definitely the wrong place. The right place is the
PortletControl. Are you goint to fix the fix (;-) or do you want us to do
that?
Cheer,
Thomas
----- Original Message -----
From: "Raphael Luta" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Monday, November 13, 2000 10:11
Subject: Re: User dependent portlet parameters
Stephan Hesmer wrote:
>
> ----- 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.
>
The parameter bug was fixed yesterday.
Also, whatever system you chose for storing the PSML-related informations,
I'll most probably need to subclass RunData for keeping the template
related informations, so I think we should also use it for the PSML-related
stuff too.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
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]
--
--------------------------------------------------------------
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]
