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: