The problem with this pattern in JSF is that JSF context information is lost between redirections, like the messages, for example (I posted a listener to save the messages between redirections some weeks ago). And I don't know if some more information will be lost...
2005/9/27, Werner Punz <[EMAIL PROTECTED]>:
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
>
