3

I want to do something like this (redirect to a different page depending on some condition!):

<ui:fragment rendered="#{projectPageBean.availableMethods}">
    <p:commandButton id="test"
        value="View Instrument"
        action="instrumentLayout?faces-redirect=false"/>                                 
</ui:fragment>
<ui:fragment rendered="#{not projectPageBean.availableMethods}">
    <p:commandButton id="test1"
        value="View Instrument"
        action="methodLayout?faces-redirect=false"/>       
</ui:fragment>

But this construction doesn't seem to work; the page redirect in the action attributes is never carried out!

How can I get this behaviour right?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
g.verhaag
  • 139
  • 3
  • 11
  • @cobalt: Neither `` nor `` are specific to RichFaces/PrimeFaces. They are just part of standard JSF. – BalusC Jun 25 '13 at 13:23

1 Answers1

4

During processing the form submit, the rendered attribute of the input/command component and all of its parents is re-evaluated as part of safeguard against tampered requests. If it evaluates false, then any child input/command components won't be decoded and the submitted values won't be set and invoked actions won't be queued.

Apparently that's what's happening here. Placing the bean in the view scope should solve it.

@ManagedBean
@ViewScoped
public class ProjectPageBean {}

This way the bean will live as long as you interact with the same view by (ajax) postbacks.

See also:


Unrelated to the concrete problem, it's however quite strange to use command buttons for plain page-to-page navigation. Better use regular buttons for that.

<ui:fragment rendered="#{projectPageBean.availableMethods}">
    <p:button id="test"
        value="View Instrument"
        outcome="instrumentLayout"/>
</ui:fragment>
<ui:fragment rendered="#{not projectPageBean.availableMethods}">
    <p:button id="test1"
        value="View Instrument"
        outcome="methodLayout"/>
</ui:fragment>

This will also solve the concrete problem. It will just send a plain GET request on the specified URL instead of performing a postback causing all the JSF form processing to run which in turn ultimately sends another GET request as redirect. Much less clumsy thus. Note that you can safely put those buttons outside <h:form> this way.

If you make them <h:link styleClass="ui-button ui-state-default ui-corner-all"> instead of <p:button>, then it's even much more SEO friendly (i.e. searchbots like Googlebot can better find and index them).

See also:

Community
  • 1
  • 1
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • Thank you very, very much for the explanation and suggestion! By the way I'm fairly new to JSF and still looking for a good book covering this topic! Any suggestions will be very much welcomed! – g.verhaag Jun 25 '13 at 13:17
  • As to the book; most of JSF can easily be understood if basic HTTP and HTML is properly understood and you know what HTML those JSF components generate. Then, to dive further into JSF consider "Core JavaServer Faces" or if you want to take JPA/EJB into account (recommended!), then "Beginning Java EE 6/7". – BalusC Jun 25 '13 at 13:27
  • Thanks again, I'll certainly consider the suggestions! – g.verhaag Jun 25 '13 at 13:31