Todd Kuebler wrote:
The init() call has no request info because it is intended to be called once for each Portlet.At 11:47 AM 11/18/2002 -0800, Andrew C. Oliver wrote:Thanks!
preLoad isn't intent on
creating anything that could be construed as "View". The idea is that
data that the view might depend upon can be loaded...
So for instance...
init
preload(RunData) { get stuff from the database }
getContent(RunData) { get the database stuff from the cache and present it via Velocity JSP whatever... }
This would be most excellent. I've found that I've had to implement some strange stuff to achieve user level data caching since the init() call is not tied to a request and is missing rundata/user info. And the parallelization of portlet content fetching would be really appreciated.
What you are calling for is some kind of session events. A portlet could be handed some event when a session is started, and possibly another event when the session is unbound. The portlet API does contain such events, which we could register to.
But take into account that currently portlets are instantiated once per container, so they should not store session or user information except under the session object. There is already a rundata.getSession().isNew() call to check for new sessions and calculate and store session-dependent information in the session.
Another possibility would be to have session-scoped (or even request-scoped) portlets, which *could* be implemented by having a registry stored in the session, and populated at session creation. This registry would be looked before the "global" one, thus returning session portlets prior to global portlets..
This would not make a lot of sense unless the initialization of such portlets is really cheap, as they would add overhead to each session (request).
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
