Consequences of JSF <redirect /> use

Instead of appending ?faces-redirect=true to every action in my <h:commandButton />, I would like to use it once for good in faces-config.xml but I am not yet sure of the consequences of using it.

It stipulates that redirect will be used instead of forward. But what are the consequences? Is it a bad practice, does it affect persistence and servlet requests and respon开发者_JS百科ses?

For me, the use of REDIRECT is only for correct URL browser displaying. I intend to use something like this :

<navigation-rule>
    <from-view-id>/*</from-view-id>
    <navigation-case>
        <from-outcome>*</from-outcome>
        <redirect />
    </navigation-case>
</navigation-rule>

Many thanks for your guidance.

A redirect basically instructs the browser to create a brand new HTTP GET request. So all request (and view) scoped beans will be trashed at the point the redirect is made. Any request scoped data which is been set during the form action will not be available anymore in the new request. If that is a major concern, then your best bet is to put it in the session scope, but this has bigger consequences: any change in a session scoped bean get reflected in all actions which take place in different browser tabs/windows in the same session. An alternative is to pass data of interest as query string of the redirect URL, but that's plain cumbersome and ugly.

If you actually have no data which needs to be retained in the redirected request, then you can do so. But this brings a new question to the front: why are you using a POST request at all? Are you submitting something to the server? Or are you using this for pure page-to-page navigation? This question makes me think that it's the latter. In that case, you should not be using POST for page-to-page navigation at all, but just GET. This can be achieved by <h:button> (and its link equivalent <h:link>)

<h:button value="Next page" outcome="nextpage" />

If it's actually the former, I'd just stick to it. You don't want to bookmark POST requests.

See also:

• When should I use h:outputLink instead of h:commandLink?