> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of burtonator
[snip]
> > > 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.
So you mean that PortletConfig would stay as it is currently, only that
PortletRunData would be taken out from there and passed as a parameter to
getContent()? Seems ok with me...
> > 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.
I think we should have in Jetspeed a wrapper for ParameterParser also, so I
would need to import to my portlet only jetspeed packages, not Turbine...
> We still need RunData for the Cocoon integration
What do you mean by that? AFAIK, we only need HttpServletRequest for Cocoon?
> > 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 way I see it: there is some class (e.g. DynamicParameter or
JetspeedParameter, or simply ParameterParser) with method like
encodeUrl(String url) on HttpServletResponse. So in my code I would to
something like this:
String paramName = JetspeedParameter.encodeParameter("foo");
Input field = new Input(paramName, "bar");
return field;
and later I would get the value:
String paramValue = JetspeedParameter.getString("foo");
So Jetspeed would take take for namespacing all the parameters properly and
then later resolving them to correct names. This way the portlets could be
fully unaware that there are also other portlets on that page. (Given that
all portlets use this API. If they don't then the conflicting names are
their problem).
Probably we will also need a way to assign page level parameters (basically
without any namespacing) so that portlets can communicate with eachother...
Or does someone have some better idea for intra-portlet communication?
So, JetspeedParameter would search for parameters first in portlet
parameters and if not found then in page level parameters.
Also I see a need for DynamicURI type of functionality:
1. ability to generate an URL that marks a certain portlet in registry. This
is used for example by portlet itself when it has a form and it wants to
process this form data. Or it could be used to generate URL for a link to a
different portlet.
2. ability to do internal redirects between portlets (actually I have
already done some kind of implementation of this). So, after processing the
data submitted by form, the portlet could do a redirect to some other
portlet.
Neeme
--
--------------------------------------------------------------
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]
