> From: Ryan Wynn [mailto:[EMAIL PROTECTED] > > 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?
I'm not sure. I believe the APPLICATION_SCOPE session is shared by all portlets for a given user session so this shouldn't be requirement. > What is the tapestry phase that corresponds to render? Simply the render phase > 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? There is no existing mechanism that I know of in Tapestry that allows portlets to communicate. You'd have to manually access the session to read the data that's been set by another portlet. What data you read and how you handle it is up to you. > ## 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
