Hi Archana. Why not create a re-usable portlet class and a portlet.xml with different init-parms for each "mode" ? I did something similar in order to avoid having to code endless portlet classes that performed the same function. I create an "init-param" in my portlet.xml that tells my portlet which view page/folder to render on startup ... and the rest is handled through links.
- Frank > -----Original Message----- > From: Archana Turaga [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 08:56 AM > To: Jetspeed Users List > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > > > Thanks for the response Frank. > > Just to reiterate my problem. I have defined a portlet,xml where > the same page is defined in three different modes therefore it > appears as three different portlets with different parameters each time. > > So final problem that occurs is I go to link1 click on submit on > that portlet page and then I go to link2 and navigate back to > link1 instead of the request being submitted freshly with the > parameters defined in portlet.xml the last request is remembered > and the page at link1 is in the state that I left in i.e. after > Submit on link1. > > > > -----Original Message----- > From: Frank Villarreal [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 8:49 AM > To: Jetspeed Users List > Subject: RE: REQUEST PROBLEM in JSR 168 portlets > > 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] > > > 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]
