Hi
Bundled with Mojarra binary distribution there is a sample about how
to deal with ViewExpiredException.
The article talking about the sample is here:
http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2
It proposes uses a custom ExceptionHandler and call
NavigationHandler.handleNavigation to redirect the incoming request
into a page. The example works well.
The problem start when people try to extend the example to deal with
all kind of Exceptions. At the end, the idea is create a custom error
page using a custom ExceptionHandler and JSF pages. So, you can
imagine insert something like this:
nav.handleNavigation(fc, null, "viewExpired");
fc.renderResponse();
This will not work on render response phase, because all exceptions
are handler before end that phase, so the navigation will not have any
effect, because render response already happened.
The curious thing about this and the reason why I'm talking about that
on this list is in JSP, you can create an error page written in JSP,
but you can't do the same in JSF. Something important is missing in
this part.
Things become more relevant with the introduction of f:viewAction and
what happen when you consider JSF 2.0 GET support. A viewAction can
trigger a navigation, right? but what happen if the view to navigate
has f:viewParam set? does the whole lifecycle be executed for that
page?
Other example. Suppose two pages, a.xhtml and b.xhtml with
f:viewAction set, and both has f:viewParam. The client ask a.xhtml to
be rendered, so the whole lifecycle happens. On
INVOKE_APPLICATION_PHASE the f:viewAction triggers a navigation to
b.xhtml, but note since b.xhtml has f:viewParam and f:viewAction, it
is necessary to execute the lifecycle over b.xhtml to give the chance
to the action. I do not have very clear the details about how this
should work, so I'm "betting" something like that should happen here.
In fact, why a view with f:viewParam and invoked through navigation
handler does not require to execute the full lifecycle on itself after
the navigation? Note there is a possible "contradiction" here between
the expected behavior over a normal navigation and a navigation caused
by f:viewAction.
Anyway, I only wanted to call your attention over the "implicit"
effect that has NavigationHandler algorithm over JSF lifecycle, and
that is necessary to provide some "points" to control lifecycle from
navigation algorithm, which is relevant with the current work about
f:viewAction on the EG.
regards,
Leonardo Uribe