"Kevin A. Burton" <[EMAIL PROTECTED]> wrote:
> > *) The PortletConfig data member stored in a portlet, is this the same as
the
> > one passed to init()? Should we save this portlet config object via a
call to
> > setPortletConfig(pc) in our implementation of the init() method? For
example,
> > CocoonPortlet, doesn't even use the PortletConfig passed.
>
> 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()?
> > *) The portlet-markup in defaultPortlets.xml lets you define a url for
each
> > portlet. A combination of classname and url are used as a key in the
> > PortletCache. If you don't define a url, you can only have one portlet
> > defined for a given class type. Is this correct behavior? Do I have to
use
> > the url in some fashion when implementing my portlets?
>
> No. If you check the XML schema it doesn't require the URL. In
> defaultPortlets.xml I don't use the URL on some (see
> ApplicationsPortlet).
>
> 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 ).
> > *) 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.
>
> --
> 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."
>
>
> --
> --------------------------------------------------------------
> 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]
Jeffrey D. Brekke
mailto:[EMAIL PROTECTED]
http://sites.netscape.net/ekkerbj/homepage
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.
--
--------------------------------------------------------------
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]
