>>>>> On Mon, 28 Jun 2010 10:16:11 PDT, webtier_at_javadesktop.org said:
P> lets say that we have a facelet view [b]index.xhtml[/b] with
P> following command links:
P> <h:commandLink value "Navigate Back" action="index" />
P> <h:commandLink value "Redirect Back" action="index?faces-redirect true" />
P> If I follow the first command link PreDestroyViewMapEvent will fire,
P> but if I follow the second one it won'tt. So, I was wondering does
P> anyone know if there is a reason for this difference in behavior.
This is because in the first case, you are doing a POSTBACK, which
causes the navigation to happen during the invoke application phase,
which changes the viewId stored in the FacesContext during the POSTBACK
lifecycle run.
In the second case, you're doing a POST REDIRECT GET, which encompases
multiple runs through the lifecycle, each with its own FacesContext
instance.
Let's look at the HTTP traffic in both cases.
P> <h:commandLink value "Navigate Back" action="index" />
Client Server
POST index.xhtml run lifecycle phases APPLY_REQUEST_VALUES upto
and including INVOKE_APPLICATION on one
FacesContext.
During INVOKE_APPLICATION, a new UIViewRoot is
created as a result of the navigation. It
happens have the same viewId because you
manually specify "index" as your action, but
it's a new UIViewRoot just the same. When this
viewId is populated into the FacesContext, the
viewMap is destroyed.
Run RENDER_RESPONSE phase, send response to client
P> <h:commandLink value "Redirect Back" action="index?faces-redirect true" />
Client Server
POST index.xhtml same as above, but do not run RENDER_RESPONSE
phase. Instead send 302 redirect.
GET index.html This is a new request, with a new FacesContext,
so we don't get the viewmap destroyed event.
Ed
--
| edburns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 13 Work Days Til JSF 2.1 Milestone 1