[EMAIL PROTECTED] wrote:
> Hi folks,
>
> I would like to add my two cents....
>
> A portlet should do what it has to do based on three things:
>
> 1. the porlet configuration
> 2. the user-specific configuration of the portlet
> 3. the specific request that led to display the portlet
>
> Obviously, these things are very distinct and have different life-time. The
> portlet configuration is loaded at initialization time (or when the first
> user wants to display the portlet). It can stay in memory for as long as
> the system lives. The user-specific configuration (not there yet in
> Jetspeed as far as I can see) is loaded when the user logs and lives while
> the session is active. Lastly, the request has its natural life-time...
> Therefore all three need to be different classes should be stored as
> appropriate: the portlet configuration held by a portlet instance, the
> user-specific configuration in the session and somehow passed to the
> portlet in some portlet context. And the request when the rendering is
> required. The request should *not* be stored in the portlet as is the case
> with RunData at the moment. User-specific configuration and request could
> be passed as part of the same portlet context.
>
> The user-specific configuration needs to be some general purpose object,
> because Jetspeed cannot possibly foresee the configuration that a portlet
> may want to store as part of its configuration. I therefore suggest some
> sort of memento mechanism (see GOF patterns). A portlet that wants to store
> user-specific configuration has to derive for
> org.apache.jetspeed.portal.Memento (for example) and can then set and get
> the momento in the portlet context as it is being passed to the rendering
> call.
>
I wanted to comment here that there are already two different places where the
user configuration information is taken into account:
- The user psml file. Here, the user can specify layout, but also skin and
content properties, like how many items to show, or whether we like images in
channels or not, through portlets parameters. The system will cache the
portlets on a key that takes parameters into account, so there are no issues
WRT this parameters, except for repetition of entries..
- The user session. There is currently no wrapping of the session object in
Jetspeed. But you can use it when we solve the issues around thread safety.
>
> Speaking of which, are there any plans to remove the depency on ECS and
> have people write directly to the stream? To me ECS (as nice as it is)
> seems like a big overhead with all its transient objects being created for
> each request. I would like to write the output stream directly, and if I
> choose to use ECS then that's fine too - I just have to stream the tree at
> the end. One could also think of a default implementation of the rendering
> call that calls getContent() and performs the streaming of the ECS tree on
> behalf of the derived portlet class.
>
> Any comments?
>
> Thomas Boehme
>
> burtonator <[EMAIL PROTECTED]> on 09/08/2000 02:16:37
>
> Please respond to "JetSpeed" <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Thomas Boehme/Germany/IBM)
> Subject: Re: multithreading problems in the portlet drawing?
>
> Neeme Praks wrote:
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, September 07, 2000 2:29 AM
> > > To: JetSpeed; [EMAIL PROTECTED]
> > > Subject: Re: multithreading problems in the portlet drawing?
> >
> > [snip]
> >
> > > > I think we should keep passing the rundata down in every
> > > getContent(),
> > > > or else, passing a new
> > > PortletConfig/PortletControllerConfig down with
> > > > every request. If we do not do so, there is a risk we mix
> > > up sessions.
> > > > THis is if I understand correctly the code and the sobject model, of
> > > > which I'm not completely sure.
> > >
> > > I would vote for passing RunData. This means less object generation.
> > >
> > > > I know that is a major change, but we should make sure we are doing
> > > > things right.
> > >
> > > *totally* +1
> >
> > I remember you having a idea of abstracting away the current Turbine
> > infrastructure...? This is what PortletConfig is meant for? I would vote
> to
> > pass PortletConfig...
>
> Yes... probably PortletConfig... Should we separate this out into
> PortletRunData (or PortletRequest?) and PortletConfig? PortletRunData
> being information that changes on each request? There is other
> information that never really changes in PortletConfig and it wouldn't
> be good to add this to the class... would take a performance hit over
> time.
>
> > but maybe we need to change the implementation of
> > PortletConfig so it doesn't wrap RunData, but rather copies the relevant
> > parts (like parameterparser)...?
>
> It already has ParameterParser.... getRunData is deprecated. We still
> need RunData for the Cocoon integration
>
> > And Jetspeed should have it's own ParameterParser also, that would allow
> us
> > to guarantee non-conflicting fieldnames for portlet forms... I wrote
> about
> > it in a thread in Avalon list, probably should forward that post to this
> > list also...
>
> I don't think I like this. The problem is that where to we namespace
> the properties... there is no central way to control this :(
>
> Kevin
> --
> ** Should SUN Open Source Java? Please Vote:
> http://relativity.yi.org/java **
>
> Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
> burtonator)
> http://relativity.yi.org | http://www.openprivacy.org
> Message to SUN Microsystems: "Please Open Source Java!"
> To fight and conquer in all your battles is not supreme excellence;
> supreme
> excellence consists in breaking the enemy's resistance without fighting.
> - Sun Tzu, 300 B.C.
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
