mjn
mjn

Reputation: 36634

JSF 2 - which ways exist to find back to the calling page?

My web application has two search pages - search1.jsf and search2.jsf - which share the same bean which in turn calls a result page - result.jsf.

So both search pages have a commandButton

 <h:commandButton value="Commit" action="#{search.commit}" />

The "search" bean then processes the search and forwards to the result page using

target = "result?faces-redirect=true";

Now the result.jsf doesn't know which search page has been used. How can I pass the calling page so that the called page is able to render a link back to the calling page?

Using the browser back button (or Javascript code) to go back in the history has the disadvantage that the user, after browsing through the results, only would go back one page in the results instead of going 'up' to the search parameter form.

Options I see so far are:

Or is there a JSF functions which returns the name of the calling JSF page?

Upvotes: 3

Views: 1206

Answers (1)

BalusC
BalusC

Reputation: 1108632

You're redirecting to the result page which suggests that you're using a session scoped bean to hold the results (a request/view scoped simply doesn't survive redirects). Ignoring the fact that this is a poor/odd approach, you could just store the search type in that bean as well?

Anyway, easiest and cleanest is to use a single master view with a single master view scoped bean and conditionally display search1.xhtml, search2.xhtml and results.xhtml using <ui:include> in the master view.

search.xhtml

<ui:fragment rendered="#{empty search.results}">
    <ui:include src="/WEB-INF/search#{search.type}.xhtml" />
</ui:fragment>
<ui:fragment rendered="#{not empty search.results}">
    <ui:include src="/WEB-INF/results.xhtml" />
</ui:fragment>

As long as you return void or null in action methods, the same view scoped bean will be retained on every subsequent (and non-redirected!) request. If you intend to make it a GET instead of POST (so that it's bookmarkable and back-button-navigable such as Google), then you should actually change the forms and view parameters to make it GET instead of POST.

Upvotes: 3

Related Questions