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
Joined: May 29, 2004
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
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.