At 10:11 2000-11-13, you wrote:
>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.
Ok, we can also subclass RunData and provide a PortletUserConfig field
there. I don't like the idea that this field will be set for every
getContent call so much (this makes it essentially an indirect parameter
passing), however I can see that we save work if we leave the
getContent(RunData) signature unchanged.
ingo.
>--
>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]
