File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSF and the fly likes Going back to previous page Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Going back to previous page" Watch "Going back to previous page" New topic
Author

Going back to previous page

Michal Glowacki
Ranch Hand

Joined: Mar 14, 2006
Posts: 114
Hi

I was wondering if there's an easy or popular way to solve the problem of going back to previous page in JSF. Javascript's history.back() is not always good, because page can expiry or I can make an action which will reload current page and pressing button will get me back to the same one. My pages can be accessed from many other, so I can't make static binding, also parameters sent to them can be various. Maybe there's a good solution for this?

Thanks for any tips,
Michal
Maurizio Nagni
Ranch Hand

Joined: May 29, 2004
Posts: 75
Hi,

I have the same problem ... for now i am studying if it possible to do something using a custom NavigationHandler or a custom PhaseListener (which i already use for login reasons).
I started really few times ago (minutes) to check the problem and actually i would like solve the problem in small steps
1) how identify a previous page from the "request" object
2) how to "cacel" the back operation.

waiting for some news from here, if I will have better news I will posts
Maurizio Nagni
Ranch Hand

Joined: May 29, 2004
Posts: 75
Well, after some day the solution is working!
Supposing you are POSTing from a JSF page, 4 steps are needed:

1) be aware of the life cycle of the pages
the first point is absolutely needed to be aware where insert the code; according to this you learn (I learnt) that when you submit or refresh a page, during the first phase, the restore view, the faces servlet is aware of the new page, the newViewID, you moved using the back button in the browser and for this later we can use a code like


2) take memory of the page from where you are
Before the faces servlet relly render the new page there are several pages which could redirect to different view than the one you read at the beginning. But after the UpdateModelValue phase, which is where the faces servlet:
a) call the faces-config for read the correct page navigation
b) call the NavigationHandler to execute it.
The next two phases (InvokeApplication and RenderResponse) will not change the page to be rendered (ok...ok.... you could have an error page...)
this is the the best point to read out the final viewId.


At this point most of the trick is clear: we need to remember the currentViewId, during some NavigationHandler method (see below), and compare it with the newViewId at the beginning of the restorePhase. If you are submitting a POST, the two viewId, obviously they have to be equal (remember that I suppose you are POSTing from another JSF page); if they are different you can force the faces servlet to render agin the OLD page.

3) build a custom phase listener
This is needed to overwrite the afterPhase(PhaseEvent event) method and add an if to intercept the "RestoreView". Here the code can checks for pageJumping.

4) build a custom NavigationHandler
Overwriting the

and adding a code like


(note that the NavigationPoint, sessionHandler, AppHandler are custom class that you will find usefull to implement for the more general webapp architecture)

So long ... so good (I hope)... the last code you need is to force the navigation after checked that the user really "back-ed" the page using the browser. In this case you can have in the SessionManager a couple of methods like



and in the PhaseLister a code like:


if the will execute the

code the faces servlet will render again the old page. Just a last note to point out the null object as second argument of the handleNavigation: this tell to the servlet to not execute any action but just to render the old page as if it was the first time you navigate to it.
Still thank you for your question it made me learnt a lot of new and interesting things
Roman Vladimirovich Ivanov
Greenhorn

Joined: Oct 14, 2008
Posts: 1
I've got the same problem right now.
I upgraded to JSF 1.2 with no effect.

For now I'm trying to follow Maurizio's example,
and it seems to be ok, but... castom NavigationHandler makes a big and dangerous deal. With this approach we take all responsibility for requst/response logic for our application! In conjunction with JSF servlet there are loads of cases to keep in mind and unexpectible behaviour could raise.

Not sure it solves the problem in a right way.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Going back to previous page