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.
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]
