"Jeffrey D.Brekke" wrote:
<snip>
> > The controller will call setPortletConfig() for you. This way you can
> > always call getPortletConfig() and you will have something. You can do
> > what you want with the version passed in init().
>
> Doesn't this seem confusing? Should we document about it, or just remove the
> PortletConfig parameter to init()?
I am +0 here. I designed the thing so it doesn't seem confusing to me.
Someone else make the call.
<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?
> > > *) I understand why you would have a portlet not cacheable. But if I
> > > implement my getContent() method to by dynamic ( ie: not just returning
> the
> > > contents of a data member that is filled in during the init ) I still gain
> the
> > > benefit of the object existing in the cache which saves some time on
> object
> > > construction, and the dynamic behavior I want. Is this the OK?
> >
> > +1. Yes. The main reason for isCacheable() is for object where it
> > doesn't make sense to cache them and doing so would just pollute the
> > cache. Like an object that is rarely used (like the Admin portlets).
> >
> > > It seems
> > > confusing, but maybe that is just because of the current set of portlets I
> was
> > > using as examples.
> >
> > Does the above make sense.... should I put this in the docs?
>
> Yes, documentation is always good. Maybe as we get more examples, it will be
> easy to illustrate.
OK
--
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]
