0

This is a problem I inherited. We have a JSF/RichFaces/Seam app, which for security reasons has no-cache set. The problem comes when users hit the back-button, causing a repost of a form. Sometimes (and it is inconsistent) the form re-POST after hitting the back-button sets the backing bean properties to null. When caching is set to private, this does not happen. Unfortunately, that is not an option.

I have been looking for a workaround for this, and I'm not sure there is one.

Does anyone know of a standard pattern to use for this?

Harry Pendergrass
  • 1

1 Answers1

0

Does anyone know of a standard pattern to use for this?

Yes, the Post-Redirect-Get pattern. Add <redirect/> to your navigation cases of interest to perform a redirect to a GET request after a POST. The back button would then go to the GET request instead. In JSF 2.x, you can also do this by adding ?faces-redirect=true parameter to the outcome.

It has however a disadvantage when your webapplication poorly developed in such way that you're sending POST requests from page-to-page instead of POST requests to self (preferably ajax-flavored). This way any request scoped bean is not available anymore in the redirected GET request.

Also, when you're using commandlinks instead of outputlinks for plain vanilla page-to-page navigation (e.g. menu links, etc), then those should be fixed to outputlinks. Using POST has totally no value here, they should be GET from the beginning on.

Ideally, for sure in JSF 1.x webapps, you should not have any navigation cases at all if you want optimal SEO, bookmarkability and user experience.

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • We have a navigation rule that applies to these POSTS when the action returns a specific outcome, and if I try to add another redirect to the navigation from-action, it gets in the way of that redirect. – Harry Pendergrass Oct 20 '11 at 18:16
  • Does what you're saying imply we shouldn't be doing that other redirect with a navigation from-action anyway? We aren't so concerned about SEO, or bookmarkability, although the user experience is definitely suffering. – Harry Pendergrass Oct 20 '11 at 18:25
  • I should mention that this POST isn't a result of a commandlink, but a commandButton instead. – Harry Pendergrass Oct 20 '11 at 18:27
  • As to navigation, instead of navigating to the result page after post, let your bean action method set the result and return `null` or `void` instead of returning a navigation outcome. Finally invoke that method by ajax and let it re-render the component which should present the result (and eventually hide the form) depending on `rendered` attribute. As to commandlinks vs commandbuttons, it really doesn't matter. I was talking about menu links and such which actually don't invoke any bean action. – BalusC Oct 20 '11 at 18:31
  • The only problem with that is it would require a considerable rewrite of the application. At this time, the reports queue is a separate page, and multiple report pages redirect to it based on this navigation rule. – Harry Pendergrass Oct 20 '11 at 18:41
  • So, you're already redirecting or are you confusing forwarding with redirecting? Anyway, you could make the report page a bookmarkable GET request based page and pass request parameters along with the redirect. For JSF 1.x you only need to send the redirect programmatically using `ExternalContext#redirect()`. – BalusC Oct 20 '11 at 18:43
  • Okay, if it's a redirect, then you shouldn't have any problems when navigating to that result page by back button. – BalusC Oct 20 '11 at 19:09