Hi Archana. All of my portlet pages depend on the parameters passed to them as well. The problem I'm currently facing is that J2 doesn't "clear" render parameters when a direct "page" link is clicked (at least in my version M2). It seems logical that if a render link is generated/clicked that has ZERO render parameters on it (such as page links), then the portlet should behave/render accordingly. Maintaining state between page jumps and parameter-less render requests seems to me more like a case for utilizing session variables and/or database persistence. Once again, this is just my 2 cents.
- Frank > -----Original Message----- > From: Archana Turaga [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 08:23 AM > To: Jetspeed Users List > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > > > Well you do have a valid point. But I think that this should be > configurable i.e. should Jetspeed remember the last render > action...that way yours and mine concerns are addressed. Because > in certain cases this maybe undesirable as in our case where a > page depends on parameters passed to it... > > -----Original Message----- > From: Shah Amit [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 7:53 AM > To: [email protected] > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > > Hi, > > I was thinking about this on my way to work today !! > > I feel, what jetspeed does by remembering the last renderedAction > _should_ > be the behaviour. Imagine this situation -- > > You have 3 portlets p1, p2 and p3 on a page. You go to p1, and you are in > middle of some stuff. Now, you go to p2 (say a game portlet) and > play some > games. And then you want to resume your work on p1. In that case, if > jetspeed refreshes each portlet with the renderAction declared in the > portlet.xml file, and not the last render action, you would have > to redo all > your work ... ?? > > I feel there needs to be a slightly different approach while > making portal > as compared to making a normal web application .. ?? (with > regards to this > feature) This is the first web portal that I am making so please > bear with > me if this sounds totally stupid !! > > Any comments thoughts from peoples ... > > Amit > > ----Original Message Follows---- > From: "Archana Turaga" <[EMAIL PROTECTED]> > Reply-To: "Jetspeed Users List" <[email protected]> > To: "Jetspeed Users List" <[email protected]> > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > Date: Mon, 24 Oct 2005 08:08:40 -0500 > > Hello Jonathan, > I just wanted to confirm the behavior of your portlets. So when > you navigate > between links the pages are always presented as they were right. > For e.g. if > you went to link1 and did some actions and that resulted in > another result > page. You navigate to link2 and come back to link1 are you presented with > the first page or the result page? > Thanks for your time, > Regards, > Archana > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Monday, October 24, 2005 3:47 AM > To: [email protected] > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > > > Thanks for the info Jonathan. I appreciate the response. > > > > I'm new to the whole JSR168 spec and therefore am discovering stuff as > > I go along. If you can bear with me and answer some of these questions > > then it will help me proceed better: > > > > 1) Is this library under some license? Is there a license agreement? > > Because before I explore anything further I need to verify the terms of > > the license (Company rules!!!:-(). For e.g Jetspeed is under the Apache > > license. > > There is no licence and changes to source are allowed, contact Mechelle > Osmond for clarification. > > > > 2) I just read the library and it seems that certain modifications have > > to be done to the "doView" method (So that I can make the Render action > > behave differently). As you know this method resides within the > > struts-bridges library. I'm by the way using Jetspeet 1.6 with fusion. > > I did not see any mechanism of pulling out the strutsPortletAction > > class to override the doView method. Is there a way I can do that? > > > > I created my struts portlet from the example in Jetspeed2, so am using the > execute method. You have to compile the latest struts bridges > source so the > javax.portlet.reqeust is available. > > > 3) This question is about session sharing. Since I have a struts webapp > > that is a JSR168 portlet within Jetspeed using this library I can pass > > along attributes of my choice to the JSR 168 portlet from the Jetspeed > > webapp session RIGHT? Also does this library do some sort of session > > matching? i.e. if the Jetspeed session ends does it also help > > invalidating the JSR168 portlet webapps' session. For this I guess I > > will have to read the MessageStore stuff that is specified in the > > library. I'm going to go and dig further into that doc...but since you > > have already used it if you can just give me some guidance that will be > > great. > > Not sure about session invalidating. > > If you require some sample code, let me know and I can send a zip file to > you. > > > > Thanks for your time and patience in advance. > > Regards, > > Archana > > > > -----Original Message----- > > From: Jonathan Hawkins [mailto:[EMAIL PROTECTED] > > Sent: Saturday, October 22, 2005 2:08 AM > > To: Jetspeed Users List > > Subject: Re: REQUEST PROBLEM in JSR 168 portlets > > > > Take a look at > > http://www.doc.ic.ac.uk/~mo197/portlets/portlet_messaging/ > > > > Just used this myself to set the source of an iFrame in one portlet > > from the struts action within another ortlet. > > > > Hope that helps > > > > Jon > > > > > > Jacek Wi¶licki wrote: > > > >> Wiadomosc od Archana Turaga z 2005-10-21 23:55 brzmiala: > >> > >>> Thanks for the response. Well the difference here is that I have the > >>> same portlet showing up for create/update/delete. So the distinction > >>> is done in the portlet.xml (Snippet is as below). So a menu link is > >>> associated with that page with specific parameters. The menu is > >>> rendered within the Jetspeed scope but the link is to a JSR168 > >>> portlet which is an external webapp. Unless I do something like when > >>> the link is clicked I somehow pass the attribute along as to what was > >>> clicked...then based on that the jsp can show up in the relevant > >>> mode. WELL THE BIG QUESTION IS WHERE CAN I SET THIS ATTRIBUTE? What > >>> you said is more in the JSR168 session context Right? Do let me know > >>> if there is any additional information that is needed? And thanks > >>> once again for the response. > >> > >> As far as I understand, the only problem is passing some attribute > >> between different web aplications (within the same container), right? > >> I don't know much about other servlet containers, but with Tomcat you > >> could set the "crossContext" attribute for either application context > >> to "true" and then setup the parameter (identified e.g. by the HTTP > >> session id) in the other servlet context (another webapp), like this: > >> //your application context: > >> <HTTPServlet>.getServletContext().getContext(<String:other app context > >> name>).setAttribute(<String>, <Object>); > >> //other application context > >> <HTTPServlet>.getServletContext().getAttribute(<String>); > >> > >> The above code can be applied from within a servlet, you should modify > >> it to execute from a portlet, i.e. get a servlet context from a > >> portlet context. I am not sure if a PortletContext object could by > >> fully functional as a ServletContext object, however if such a > >> solution fails, use an intermediate redirection servlet for setting > >> the other context attributes. > >> > >> I do hope that it's what you meant. > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > This e-mail transmission may contain information that is proprietary, > > privileged and/or confidential and is intended exclusively for the > > person(s) to whom it is addressed. Any use, copying, retention or > > disclosure by any person other than the intended recipient or the > > intended recipient's designees is strictly prohibited. If you are the > > intended recipient, you must treat the information in confidence and in > > accordance with all laws related to the privacy and confidentiality of > > such information. If you are not the intended recipient or their > > designee, please notify the sender immediately by return e-mail and > > delete all copies of this email, including all attachments. > > > > --------------------------------------------------------------------- > > 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] > > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for > the person(s) > to whom it is addressed. Any use, copying, retention or disclosure by any > person other than the intended recipient or the intended recipient's > designees is strictly prohibited. If you are the intended recipient, you > must treat the information in confidence and in accordance with all laws > related to the privacy and confidentiality of such information. > If you are > not the intended recipient or their designee, please notify the sender > immediately by return e-mail and delete all copies of this email, > including > all attachments. > > --------------------------------------------------------------------- > 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] > > > This e-mail transmission may contain information that is > proprietary, privileged and/or confidential and is intended > exclusively for the person(s) to whom it is addressed. Any use, > copying, retention or disclosure by any person other than the > intended recipient or the intended recipient's designees is > strictly prohibited. If you are the intended recipient, you must > treat the information in confidence and in accordance with all > laws related to the privacy and confidentiality of such > information. If you are not the intended recipient or their > designee, please notify the sender immediately by return e-mail > and delete all copies of this email, including all attachments. > > --------------------------------------------------------------------- > 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]
