DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7198>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7198

Extend the Velocity Portlet to provide content caching ability

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jetspeed-
                   |                            |[EMAIL PROTECTED]
           Severity|Normal                      |Enhancement
             Status|NEW                         |ASSIGNED
         OS/Version|Other                       |All
           Priority|Other                       |Medium



------- Additional Comments From [EMAIL PROTECTED]  2002-03-18 10:33 -------

--- David Sean Taylor <[EMAIL PROTECTED]> wrote:
> > 
> > So - did I miss something or is there currently facility for 
> > caching content from velocity based portlets?
> 
> The VelocityPortlet always goes to the template to merge the
> content,
> currently no caching
> 
> > And if not, anyone interested in me add this as an optional (off
> by
> > default) feature to the existing VelocityPortlet?
> 
> No problem with you adding this feature, perhaps create a subclass
> 'CacheableVelocityPortlet'

The thing that I do not understand is why the current VelocityPortlet defaults 
to returning isCacheable of "false".  All that this means is that the portlet 
object is re-created upon each client request and not cached as an object.  Is 
it safe to default this to "true" - or at least make it configurable from the 
portlet init parameters?

I plan to cache the content as a member variable of the portlet - is this the 
right place - or should I be using the Cache Service - thus allowing the 
content to be cached even if the isCacheable flag is false?

> Will you do the same for the JSP portlet ?
> 

I will look at the JSP portlet too.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to