Ok I think there is a pattern to deal with http post problems, however I have not dealt with it yet, others might be able to help out I think it is called somewhat like redirect after post... You also might have to check out the shale tokens system it might help you out as well.
Sorry that I can not help you further. Werner Dave wrote: > HI Werner, > Thanks. <x:saveState> does not work in this case. Data saved using > <saveState> are only available to the immediately following > request.(post back in most cases). > > When user click Back, the browser says something like "not available > since previous Form post, ask to refresh ". When use click Refresh, the > data saved using <x:saveState> is not there any more because it is not > immediate POST back. > > Dave > > */Werner Punz <[EMAIL PROTECTED]>/* wrote: > > Dave wrote: > > When a backing bean is dependent on some data that are initialized > > by previous page, it works fine normally. But if user click > Back/Refresh > > on browser, then the data is not available anymore to the backing > bean. > > This will result in NullPointerException because the data is null. How > > to catch this issue and display a nice informative message, definitely > > not Exception? Thanks for ideas. Dave > > > Sorry, my first answer was too short, to clarify things a little bit, > the problem you encounter is due to the request scope, a bean declared > in request scope lives only one request, now if you do a refresh you > might lose > important data along the way, the same goes for back. > > There are various solutions to the problem, the shale token stuff, I > yet have to check out, > but one solution is to use constructs w hich enable scopes bigger > than request. > One solution definitely would be to dump the backend bean into the > session > that way non traversed values would survive a refresh. > Another one would be to use a lot of hidden fields, for the non > visible data which has to survive > which is a maintenance nightmare. > > Generally the currently possibly best approach would be to use > x:saveState which stores > beans for every page where a x:saveState tag is hit with the same > declaration, > or to use some kinde of dialog-scoping system: > > Following systems currently are available: > Shale Dialog > Seam > > Seam at least is rather heavy on the configuration side, but it > looks like the most interesting > approach in this area. > Shale Dialog I have not looked into yet, > > the possible most lightweight approach however probably is > x:saveState... > > > ________ __________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mai l has the best spam protection around > http://mail.yahoo.com >
