Well Frank Since you mentioned this problem...did you have to deal with this problem i.e. Jetspeed remembering the last action ,in your portal. If yes then how have you dealt with it? Thanks, Archana
-----Original Message----- From: Frank Villarreal [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 25, 2005 8:06 AM To: Jetspeed Users List Subject: RE: REQUEST PROBLEM in JSR 168 portlets Hi Shah. I tend to disagree with this idea. If you have a portlet application that has many "navigable" sub result pages inside it and the user wants to go back "out". Then the only option is for the portal to "clear" render parameters whenever a "page link" is clicked. IMHO, this should be the "default" behavior ... and I base that on what I've witnessed as standard behavior on the vast majority of web sites I've visited in recent years. The alternative is to place a "Go Back" button on every single sub-result page of a portlet ... not very elegant. I believe this outweighs the benefit of what you described. Just my 2 cents. - Frank > -----Original Message----- > From: Shah Amit [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 25, 2005 07: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] > > --------------------------------------------------------------------- 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]
