PageBeans AND redirect (was: great article)

[Mario Ivankovits <ma...@ops.co.at>]

Hi!
> On the negative side, we do sometimes have that JSF annoyance with 
> URLs going out of sync. As it turned out, though, the flow-scoped 
> sequences we support wouldn't have been easily bookmarkable anyway.
If its not a problem to have the extra redirect roundtrip, there seems 
to be a solution for this.

I have done the following:
*) Mark the beans to survive the redirect with a special marker 
interface (PageBean). This is badd - need to find a way to NOT need it.
*) for in-page navigation use <x:saveState to store the beans
*) create a NavigationHandler which hijacks the ExternalContext (sounds 
hackier than it is) and override its redirect() method.
*) if redirect is called (navigate-rule) capture all PageBeans from 
requestMap into a session-based PageBeanContainer.
*) create a PhaseListender and reinject the beans BEFORE restoreView.

It works .... nearly.

The last REAL problem is to find a way when to reset the beans captured 
into the PageBeanContainer.

Currently I simply reset the container after reinjecting the beans - so 
far so good, but then the "reaload" (Browsers reload button) of the page 
do no longer work.

One solution could be to NOT reset the container and add some extra 
unique ID information to the redirect url. Then the container can have 
something like a policy, e.g. capture only the last 15 redirects. Then 
the browser-back failes after 15 backs.
I admit this is not very sexy, but maybe someone else have a better idea.

What if we reset the container as soon as another view is requested - 
that might work ....


If one is interested in the code I could provide it for download.
---
Mario