No. I set session variables and each time the buildNormalContext function is called it repaints itself. I am not sure about your comment that you lose portal context? Can you expand on this, please? A
-----Original Message----- From: Oliver Pfau [mailto:[EMAIL PROTECTED] Sent: Friday, June 25, 2004 7:24 AM To: 'Jetspeed Users List' Subject: AW: WG: Sharing attributes between portlet applications hi...that's interesting... but I decided to avoid the usage of IFrames because it implies the loss of the portal context...scheme, ect. how do the IFrame-portlets communicate ? url parameter ? -----Ursprüngliche Nachricht----- Von: alex [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 25. Juni 2004 13:22 An: 'Jetspeed Users List' Betreff: RE: WG: Sharing attributes between portlet applications In regards to the treeview question below...I implemented something very similar by using a "framed" approach: inside an IFramePortlet read a JSP file which defines the "view". I have one portlet with 3 frames, top left is the tree, bottom left is command buttons to ease tree navigation and the right frame is all content. It seems to work fine. For the tree itself I used Javascript to "paint" the tree... Hope this helps. Alex -----Original Message----- From: David Sean Taylor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 24, 2004 8:22 PM To: Jetspeed Users List Subject: Re: WG: Sharing attributes between portlet applications On Jun 24, 2004, at 7:22 AM, Oliver Pfau wrote: >> Hi, >> >> I have a general JSR-168 question: >> >> is it possible to share a attribute between two portlets which are >> not in >> the same portlet application in a JSR-168 portlet ? >> The portlet session, application scope, but its limited to per portlet application -- or -- PLT 11.1.1: The portlet-container must not propagate parameters received in an action request to subsequent render requests of the portlet. If a portlet wants to do that, it can use Render URLs or must use the setRenderParameter or setRenderParameters method of the ActionResponse object within the processAction call. The second approach is limited to strings >> I want to write two portlets: >> one displays the TreeNode data structure from javax.swing.tree.* and >> stores a navigation status (String) in the context (with the >> application >> context it should work), the other portlet retrieves the navigation >> status >> and shows the chosen contents. >> This sounds interesting. Is it an HTML-based tree view? With JavaScript? I am looking for something like this to use in the Jetspeed Portlet Application Manager portlets >> Problem: I plan a generic navigation portlet which can switch its >> TreeNode >> content in run time. I mean one navigation portlet for many content >> portlets. I don't found a way to realize this communication. I think I >> have to pack the navigation portlet with each content portlet >> together as >> portlet application....I am not very happy with this solution....any >> ideas >> ? I think the render parameters could work You could also write a jetspeed service to share common data (see the PAM portlet application for an example of accessing the Registry Service) -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 --------------------------------------------------------------------- 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] --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.706 / Virus Database: 462 - Release Date: 6/14/2004 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
