| Author |
Browser back button
|
|
| Dan Dubinsky 2005-01-14, 5:53 pm |
| I have a JSR-168 portlet that uses a request dispatcher to load various JSP
pages based on a value stored in the session. The problem I'm having is the
browser back button doesn't work. It always loads the current page. I was
thinking if I could get something unique on the browser's URL line I could
use that to figure out that the page request is from a back button and use
that load a different page, but I haven't found a way. Is there any way for
a JSR-168 portlet to get something on the URL line in Websphere 5, or some
other design patterns that I could use to get the back button to work.
Thanks in advance.
| |
| Maik Weber 2005-01-18, 2:54 am |
| You have to use request parameters to store your values. The portlet
session holds variables independent from requests, so you will always
get the latest value you have set.
Maik
Dan Dubinsky wrote:
> I have a JSR-168 portlet that uses a request dispatcher to load various JSP
> pages based on a value stored in the session. The problem I'm having is the
> browser back button doesn't work. It always loads the current page. I was
> thinking if I could get something unique on the browser's URL line I could
> use that to figure out that the page request is from a back button and use
> that load a different page, but I haven't found a way. Is there any way for
> a JSR-168 portlet to get something on the URL line in Websphere 5, or some
> other design patterns that I could use to get the back button to work.
>
> Thanks in advance.
>
>
| |
| Dan Dubinsky 2005-01-18, 5:57 pm |
| Thanks Maik,
I actually tried some experiments with ActionResponse.setRenderParameter,
but it doesn't seem to work. The parameter seems to also only have the
latest value and never seems to add anything to the URL line so when I click
the back button the parameter is either null or the last one, never one
several page requests back. I read somewhere that this can be used to code
back button behavior, but it doesn't seem to work in Websphere portal (or
maybe I'm doing something wrong, should it work).
Is there another way to add parameters to the page URL line from within a
portlet. I would prefer using a standard JSR-168 way, but at this point I
think I would settle for a Websphere portal specific way.
"Maik Weber" <maikweber@de.ibm.com> wrote in message
news:csic2l$6hmk$1@news.boulder.ibm.com...[vbcol=seagreen]
> You have to use request parameters to store your values. The portlet
> session holds variables independent from requests, so you will always
> get the latest value you have set.
>
> Maik
>
>
> Dan Dubinsky wrote:
| |
| Maik Weber 2005-01-19, 7:48 am |
| hello Dan,
this should be the way you have to implement. Using setRenderParameter.
Which version of WP are you using?
Maik
Dan Dubinsky wrote:
> Thanks Maik,
>
> I actually tried some experiments with ActionResponse.setRenderParameter,
> but it doesn't seem to work. The parameter seems to also only have the
> latest value and never seems to add anything to the URL line so when I click
> the back button the parameter is either null or the last one, never one
> several page requests back. I read somewhere that this can be used to code
> back button behavior, but it doesn't seem to work in Websphere portal (or
> maybe I'm doing something wrong, should it work).
>
> Is there another way to add parameters to the page URL line from within a
> portlet. I would prefer using a standard JSR-168 way, but at this point I
> think I would settle for a Websphere portal specific way.
>
> "Maik Weber" <maikweber@de.ibm.com> wrote in message
> news:csic2l$6hmk$1@news.boulder.ibm.com...
>
>
>
>
| |
| Dan Dubinsky 2005-01-21, 5:53 pm |
| It's Websphere 5.0. I've been hacking with it using a JSR-168 portal project
in WSAD 5.1.2, but I haven't tried it on a real server.
Thanks
"Maik Weber" <maikweber@de.ibm.com> wrote in message
news:csl8kd$6oa4$1@news.boulder.ibm.com...[vbcol=seagreen]
> hello Dan,
>
> this should be the way you have to implement. Using setRenderParameter.
> Which version of WP are you using?
>
> Maik
>
> Dan Dubinsky wrote:
| |
| Maik Weber 2005-01-23, 5:51 pm |
| Well, you have to use at least WPv5.0.2.1 which contains official
JSR168 support.
Maik
Dan Dubinsky wrote:
> It's Websphere 5.0. I've been hacking with it using a JSR-168 portal project
> in WSAD 5.1.2, but I haven't tried it on a real server.
>
> Thanks
>
> "Maik Weber" <maikweber@de.ibm.com> wrote in message
> news:csl8kd$6oa4$1@news.boulder.ibm.com...
>
>
| |
| Dan Dubinsky 2005-01-24, 5:54 pm |
| I checked it. It looks like I have
IBM WebSphere Portal 5.0.2.1
Build Level: 034 2004-04-17 12:04
So I guess it should work, but maybe I should try to upgrade. Is there a
later version for Websphere Studio?
"Maik Weber" <maikweber@de.ibm.com> wrote in message
news:ct0bv2$78i8$1@news.boulder.ibm.com...[vbcol=seagreen]
> Well, you have to use at least WPv5.0.2.1 which contains official
> JSR168 support.
>
> Maik
>
> Dan Dubinsky wrote:
| |
| James Yannotta 2005-01-24, 5:54 pm |
|
WebSphere Portal Server unit test environments: v5.0.2.2 is listed with
Rational Application Developer 6.0 here:
http://www-306.ibm.com/software/awd...ures/index.html
Dan Dubinsky wrote:
> I checked it. It looks like I have
>
> IBM WebSphere Portal 5.0.2.1
> Build Level: 034 2004-04-17 12:04
>
> So I guess it should work, but maybe I should try to upgrade. Is there a
> later version for Websphere Studio?
>
> "Maik Weber" <maikweber@de.ibm.com> wrote in message
> news:ct0bv2$78i8$1@news.boulder.ibm.com...
>
>
>
| |
| Dan Dubinsky 2005-01-24, 5:54 pm |
| The WSAD automatic updates only bring the portal up to 5.0.2.1. Where can I
download a WSAD update to bring it up to the latest and greatest portal
version?
"James Yannotta" <jyannottaNO@SPAMprolifics.com> wrote in message
news:ct38rq$1mea$1@news.boulder.ibm.com...[vbcol=seagreen]
>
> WebSphere Portal Server unit test environments: v5.0.2.2 is listed with
> Rational Application Developer 6.0 here:
> http://www-306.ibm.com/software/awd...ures/index.html
>
> Dan Dubinsky wrote:
| |
| James Yannotta 2005-01-24, 5:54 pm |
|
Only 5.0.2.1 is listed in the 'Available Portal Test Environment' column
on this page, although 5.0.2.2 is listed under 'WP supported by Remote
Server Attach' column on the Portal Toolkit site:
http://www-306.ibm.com/software/inf...s/portaltoolkit
Dan Dubinsky wrote:
> The WSAD automatic updates only bring the portal up to 5.0.2.1. Where can I
> download a WSAD update to bring it up to the latest and greatest portal
> version?
>
>
> "James Yannotta" <jyannottaNO@SPAMprolifics.com> wrote in message
> news:ct38rq$1mea$1@news.boulder.ibm.com...
>
>
| |
| Maik Weber 2005-01-25, 7:50 am |
| However, it should also work with WPv5.0.2.1 in the test environment.
Did you update the portlet toolkit using the WSAD update mechanism?
I will check the behaviour in my environment.
Maik
James Yannotta wrote:[vbcol=seagreen]
>
> Only 5.0.2.1 is listed in the 'Available Portal Test Environment' column
> on this page, although 5.0.2.2 is listed under 'WP supported by Remote
> Server Attach' column on the Portal Toolkit site:
> http://www-306.ibm.com/software/inf...s/portaltoolkit
>
>
> Dan Dubinsky wrote:
>
| |
| Dan Dubinsky 2005-01-28, 5:55 pm |
| Thanks very much Maik and James. I upgraded WSAD and the render parameters
started working as you said they should. I now have the back button working
for my JSR 168 portlets :-).
Just in case anybody comes across this problem and reads this thread, the
solution involved a bit more then just using render parameters to choose the
JSP. That is because render parameters can only be set from a "post" and not
a "get" so you can't change the JSP on the fly in the render and have the
next post remember it. My solution is to:
1) In render get the value of the current JSP for the portlet from a request
partameter. If it isn't there, use whatever page is default for the portlet.
2) Also in render, if you change a page on the fly set that in a session
variable.
3) In processAction, look at the session to find out the last page rendered,
not the request parameters. Use the JSP indicated by the session to do your
processing for the post.
4) At the end of processAction, make sure to set a render parameter with the
current page your processing chose so the next render picks it up (and also
a future render caused by the back button picks it up).
I'm not sure what to call this design pattern or if it's already in a book
somewhere, but it lets you have a portlet that basically acts like a servlet
for page selection purposes. Both the "get" and "post" can change the JSP
the portlet is displaying on the fly and the browser back button still
works.
"Maik Weber" <maikweber@de.ibm.com> wrote in message
news:ct51tb$32pm$2@news.boulder.ibm.com...[vbcol=seagreen]
> However, it should also work with WPv5.0.2.1 in the test environment.
> Did you update the portlet toolkit using the WSAD update mechanism?
>
> I will check the behaviour in my environment.
>
> Maik
>
> James Yannotta wrote:
|
|
|
|