Reputation: 36634
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:
pass the caller page name through the chain to the result page, using <f:param>
or action="#{search.commit(name_of_calling_page)}
put all 'search parameter' forms in one JSF page and conditionally switch the content
Or is there a JSF functions which returns the name of the calling JSF page?
Upvotes: 3
Views: 1206
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