Thanks for the info, Rafael. The session combined with using the rewind/listener tapestry phase should work. This requires that I package the messaging portlets into the same .ear file right? Currently I am deploying each portlet in what turns out to be its own .ear, but that can change. What is the tapestry phase that corresponds to render? If 2 portlets are on a page and 1 receives event into the rewind/listener phase, how do I configure tapestry in the other portlet to do something in render?
## Not related to Tapestry but just thoughts on portlet data sharing I am using WebSphere Portal 5.1 and from what I have read I have 4 ways to message. (1) Use the session with Application attribute as mentioned (2) Use the sendMessage() api that works in the action phase but is limited to sending Strings to portlets on the same page (3) Use something called click-to-Action (IBM portlets only I think) (4) Use something called wiring (requires an adminstrative step after portlets have been installed to setup wires). I don't like 3 and 4 because they seam heavier than necessary from a development and deployment standpoint. Also, 3 actually affects the UI as a link is generated to send the data. 2 is pretty limited. 1 seems very reasonable. The other that I have used successfully is the external cache. Since portlet sessions each get a "slice" of the HttpSession you don't see the portlet session data from portlet A in portlet B (unless you use 1). However, you can get the session id from each portlet session and all are the same (equal to the HttpSession id). Then you can use this id in an external cache as a key into the "shared" session. The only advantage I can see this gives over 1 is that you don't have to package your portlets in the same application. The disadvantages are the external cache configuration and how to cleanup this cache when the session ends. Ryan Raphaël Jean <[EMAIL PROTECTED]> 08/04/2005 11:16 AM Please respond to "Tapestry users" To "Tapestry users" <[email protected]> cc Subject RE: Tapestry and JSR-168 One common way is to use the session to store messages: https://www.dev.java.net/files/documents/1654/8898/tip1.html I haven't tried this approach with Tapestry yet but I suppose it should work. The Action phase of JSR-168 corresponds to the tapestry rewind/listener phase, and this is where a portlet should store some data in the session, for other portlets to read during the render phase. Raphael -----Original Message----- From: Mark Wilcox [mailto:[EMAIL PROTECTED] Sent: jeudi 4 août 2005 16:31 To: Tapestry users Subject: Re: Tapestry and JSR-168 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
