burtonator wrote:
> 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.
>
I think we should keep configuration information in PortletConfig, and abstract a
new object, that encapsulates the turbine RunData, to be passed with the drawing
process.
>
> > 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 :(
>
The idea I have already implemented partially is:
- Change turbine RunData from a class to an interface. (This would simplify
compatibility issues, but I'm not sure it is a good idea).
- Copy current rundata to TurbineRunData, implementing RunData.
- Create JetspeedRunData, implementing RunData and having a few parameters (a
rundata and a String prefix).
Obviously, the actual RunData interface has too many setters. If turbine is a
true framework, most of those setters should be hidden, and left in the
implementation class.
The way to achieve namespacing would be:
- Each portlet has a unique id (at least in the context of the psml).
- When a portletset is going to be drawn, it does something like:
loop on portlets {
Portlet portlet = portlets.nextElement();
RunData parent = myrundata;
String prefix = myrundata.getPrefix() + portlet.getPrefix();
RunData data = new JetspeedRunData(prefix, parent);
portlet.getContent(data);
}
And JetspeedRunData would have setParameter() and getParameter() using the prefix
to encode/decode the parameter name. The remaining calls (most of them) would be
handed up to the "parent" RunData.
There would be a tricky part if we do want to provide true transparent
namespacing for "legacy" servlets, because then it should be done by a
FacadeHTTPServletRequest, so that any servlet in the framework would get "its"
parameters.
I have tested the conversion of RunData in an interface, using jetspeed jyve
source and CVS turbine. The status is:
- I had to change some files, using directly things like data.parameters
-->data.getParameters() in about 10 files in turbine.
- I had to build clean both jyve (where I had to change a lot of screens) and
jetspeed (I think no changes or very few).
The JetspeedRunData hands up everything right now, and I'm not passing it in the
drawing process yet. But I'm using it in the process.
I took this way because I though that RunData was a stable object in turbine, and
that you would keep it in Jetspeed. Also because then I could change the code
gradually, having working copies all throughout the process (I like this kind of
"evolutionary revolution").
I was about to send a change proposal to the turbine people WRT changing RunData
into an interface and creating a TurbineRunData that would implement it. I could
put it in cvs, as I have it already. Nevertheless, it could break quite a few
applications, like jyve, and would always require a rebuild of apps using
turbine ("IncompatibleClassChangeError"). So, it would have to be weighted up,
and voted.
P.S. I think also the EngineData object should be passed inside the
JetspeerunData or erased, since it contains static versions of the server name,
port, ... that make it difficult to handle virtual hosting, URLEncoded sessions,
etc.
>
> 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]
