You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Archana Turaga <Ar...@intervoice.com> on 2005/10/21 20:51:53 UTC
REQUEST PROBLEM in JSR 168 portlets
Hi everyone,
I'm still trying to find a solution for this problem. It is a major
problems since now the only ways we can access the pages again after the
screens are in this state is logout and then login. I will again
reiterate it. PLEASE EXPERTS/GURUS ANY GUIDANCE WILL BE OF GREAT HELP.
-I have defined certain parameters as part of my view page in the
portlet.xml.
-I noticed that when I navigate to one link do some action go to another
link and then come back to the previous link the request parameters seem
to be lost (Also look at the email Amit has outlined).
-After reading the JSR 168 spec ("PLT.11.1.1 Request Parameters")and
struts bridges document(Readme.txt) it seems that if RenderRequest is
used to display the page the parameters in request scope should not be
depended upon. That is what I concluded. Is there a way to get around
this problem.
AGAIN THANKS FOR YOUR TIME AND PATIENCE.
Regards,
Archana
-----Original Message-----
From: Archana Turaga [mailto:Archana.Turaga@intervoice.com]
Sent: Thursday, October 20, 2005 3:48 PM
To: Jetspeed Users List
Subject: RE: request problem in the struts portlets
Thanks for the reply and I appreciate the response. I will keep you
posted as you what I find. I
hope one of the gurus can help us here(I HOPE THERE ARE SEEING THIS
THREAD)...but whatever works right? If this worked for you then till a
better solution comes along...it is the best solution around....I will
keep you posted if I find something else.
Regards,
Archana
-----Original Message-----
From: Shah Amit [mailto:amit_shah25@hotmail.com]
Sent: Thursday, October 20, 2005 3:43 PM
To: jetspeed-user@portals.apache.org
Subject: RE: request problem in the struts portlets
Hi,
Sorry for the late ... Just got caught up with some stuff ...
Unfortunately I haven't been able to find anything for this. Following
is
the practise that I have followed and has helped me avoiding grief --
- I have to put my form in session. I dont have any "scattered" request
or
session parameters or attributes that I count on. I always put
everything in
form. This can be good because I wont need to keep going to DB for
certain
fields like dropdowns and stuff like that. However it can be a big
memory
hog if there are lots of users. Besides, another problem is I have to be
careful to "clear" the form on requests like "save" which would need to
clean up the screen and present it again for data entry.
- There can be lets say 3-4 pages that we can browse back and forth for
a
single portlet. I have to make sure that I have some mechanism for going
back to the previous pages within the same portlet. Otherwise there is a
problem because jetspeed only remembers your last "renderAction"
- This is a big problem. If an unhandled error occurs in your
"renderActoin", I am doomed !! The only way to recover is to logout and
log
back in. So I have to be VERY careful in not letting any unhandled error
escape !!
Unfortunately I haven't been able to find any elegant solutions for
above
scenerios. May be you can suggest something better .. :-(
HTH,
Amit
----Original Message Follows----
From: "Archana Turaga" <Ar...@intervoice.com>
Reply-To: "Jetspeed Users List" <je...@portals.apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Subject: RE: request problem in the struts portlets
Date: Thu, 20 Oct 2005 15:35:25 -0500
Amit,
Do you know how this issue can be resolved? Thanks once again for your
time. I guess I'm desperate to find the solution.
Regards,
Archana
-----Original Message-----
From: Shah Amit [mailto:amit_shah25@hotmail.com]
Sent: Thursday, October 20, 2005 11:02 AM
To: jetspeed-user@portals.apache.org
Subject: RE: request problem in the struts portlets
I am not a champion yet so I could be wrong. But here is what I feel
could
have happened.
- You go to create page
- You do some stuff (which ultimately transfers to making some requests
to
the server)
- Now each request should be a 2 step process - One is an ActionRequest
and
then second is a RenderRequest. (In struts this is done by having
atleast
one forward with redirect=true).
- So it is going to remember whatever is the "last renderRequest" and
not
the renderRequest that you declared in the portlet.xml with the
"viewPage"
parameter.
I dont know if this is what you are talking about so if it is not
relevant,
please ignore !
HTH,
Amit
----Original Message Follows----
From: "Archana Turaga" <Ar...@intervoice.com>
Reply-To: "Jetspeed Users List" <je...@portals.apache.org>
To: "Jetspeed Users List" <je...@portals.apache.org>
Subject: request problem in the struts portlets
Date: Thu, 20 Oct 2005 09:59:41 -0500
Hello,
I'm having a major problem here...most probably it is something that
someone has run into. I have taken my struts webapp and broken it into
JSR168 portlets (Each view page with some parameters). I have aligned
all of them in a menu and then I navigate between these pages. There is
one page that appears as Create/Update....both are defined with separate
parameters in portlet.xml. So each time the link is clicked the relevant
parameters are passed in the request to that same page.
The problem is here (I will try my best to explain):
1) Navigate to the create link and input some values.
2) Then navigate to the update link and input some values and
submit.
3) Navigate back to the create link and it seems as if has not got
the parameters it needs...because some create related display items do
not show up as they should. Basically it does not behave like a page
that has been navigated into the first time. This seems as if somehow
the request was not a new one when the link was clicked...it lost it's
state. Almost seems like some caching of request going on.
PLEASE PLEASE any pointers anyone. Is there a configuration parameter
somewhere that I need to look at? This is a big problem currently.
Thanks in advance for your time and patience.
Regards,
Archana
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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
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: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org
Re: REQUEST PROBLEM in JSR 168 portlets
Posted by Jacek Wiślicki <ja...@gmail.com>.
Wiadomosc od Archana Turaga z 2005-10-21 20:51 brzmiala:
> -I have defined certain parameters as part of my view page in the
> portlet.xml.
> -I noticed that when I navigate to one link do some action go to another
> link and then come back to the previous link the request parameters seem
> to be lost (Also look at the email Amit has outlined).
> -After reading the JSR 168 spec ("PLT.11.1.1 Request Parameters")and
> struts bridges document(Readme.txt) it seems that if RenderRequest is
> used to display the page the parameters in request scope should not be
> depended upon. That is what I concluded. Is there a way to get around
> this problem.
Maybe you should try storing the parameters in the application scope, e.g.
<RenderRequest>.getPortletSession().setAttribute(<String>, <Object>,
PortletSession.APPLICATION_SCOPE);
or cast a PortletSession object to a HTTPSession object:
((HTTPSession)<RenderRequest>.getPortletSession()).setAttribute(<String>,
<Object>);
--
pozdrawiam,
Jacek Wislicki
jacek.wislicki@gmail.com
tel.: +48 502 408 444
gg: 2540358
skype: jacek_wislicki
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org