Tapestry and JSR-168

[Ryan Wynn <rw...@us.ibm.com>]

I am hoping to understand how tapestry is designed for JSR-168. 
Specifically how Tapestry executes inside the two phase Event-Render 
lifecycle of JSR-168 portlets.  I need to develop portlets that share data 
and I am interested in how I can tap into the messaging api for JSR-168. 
Previously using Struts I was able to share data between portlets through 
an external cache.  I was able to have my Struts actions extend an IBM 
interface (IStrutsPrepareRender) that dictated whether or not that action 
was executed in the Event Phase or the Render Phase (If 
IStrutsPrepareRender was implemented that meant to execute in the render 
phase).  When I needed to send messages between portlets I had receiver 
implement IStrutsPrepareRender and the sender not implement it.  This 
ensured that the timing was correct (so that the receiving action would 
always pick up the message from the cache after the sender had put it 
there).

Any help understand how I could use a similiar mechanism in Tapestry would 
be greatly appreciated.

Ryan

Re: Tapestry and JSR-168

[Mark Wilcox <ma...@gmail.com>]

Hi Ryan,
I can't really answer the Tapestry question but I'm active with
portlets - but to my knowledge there is no messaging API in the
JSR-168 specification. It's a common question (how to share data
between portlets) but there is no standard way to do that.

Mark W.

On 8/4/05, Ryan Wynn <rw...@us.ibm.com> wrote:
> I am hoping to understand how tapestry is designed for JSR-168.
> Specifically how Tapestry executes inside the two phase Event-Render
> lifecycle of JSR-168 portlets.  I need to develop portlets that share data
> and I am interested in how I can tap into the messaging api for JSR-168.
> Previously using Struts I was able to share data between portlets through
> an external cache.  I was able to have my Struts actions extend an IBM
> interface (IStrutsPrepareRender) that dictated whether or not that action
> was executed in the Event Phase or the Render Phase (If
> IStrutsPrepareRender was implemented that meant to execute in the render
> phase).  When I needed to send messages between portlets I had receiver
> implement IStrutsPrepareRender and the sender not implement it.  This
> ensured that the timing was correct (so that the receiving action would
> always pick up the message from the cache after the sender had put it
> there).
> 
> Any help understand how I could use a similiar mechanism in Tapestry would
> be greatly appreciated.
> 
> Ryan
>

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org