"Jeffrey D.Brekke" wrote:
>
> "Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> > <snip> >
> > > > There has been talk about using multiple URLs for some Portlets.
> > >
> > > Well maybe we should not use the url as part of the handle for cacheing
> but
> > > use some other method for uniqueness? For the turbine screen portlet
> we're
> > > working on there is no url. Since I am passing the screen to display in
> the
> > > portlet as a parameter, every instance of the portlet output is the same.
> The
> > > second portlet is a cache hit since the classname/url are the same (
> > > TurbineScreenPortlet/null ).
> >
> > Also... Turbine screens probably won't work in the long run. I am going
> > to remove RunData from the PortletConfig so that it isn't tied to the
> > Servlet Engine. Why do you want to use Turbine screens?
>
> Well we have Turbine-based applications that we want the first screen to be in
> a portal on our users jetspeed home page. We envision all our applications
> able to be 'subscribed to' or 'customized' by the user ( layout, ordering, etc
> ) using jetspeed. We started writing our web applications using turbine.
> Instead of just creating a extra portlet for each applications first screen,
> we just wrote a simple generic portlet that will display any turbine screen.
>
> If you don't have the RunData in the PortletConfig object, I don't think it
> will be a problem. We can just create one in the portal for use by the
> turbine screen. The parameters will still be in the PortletConfig so they can
> still be passed to the screen.
The problem is that RunData allows the user to have access to the
Servlet API and this needs to be abstracted so that Jetspeed doesn't
have to be run in an Servlet env (like embeding it in another
application or running it "headless".).
Is there anything you need within RunData other than the HTTP parameters
(via ParameterParser)? If not then you should be able to run your
Screens as Portlets just fine.
If you need the ServletConfig or ServletRequest then it won't work.
This would require a code rework to just use ParameterParser. This
isn't a bad thing IMO as it allows you to run in a larger env.
> If interested, we were going to contribute the portlet to the jetspeed
> project. We are using it to bring in admin screens from Turbine and the first
> cut admin screen from Jetspeed onto our page. Let me know and I'll post what
> we have tomorrow.
If anyone else is interested speak up. It won't make it into CVS
because it would require RunData and this is something I want removed by
1.2...
Kevin
--
Kevin A Burton ([EMAIL PROTECTED])
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Open Source -> Join the conspiracy!
--
--------------------------------------------------------------
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]
