Difference between h:button and h:commandButton

JsfButtonJsf 2

Jsf Problem Overview


In JSF 2, what is the difference between h:button and h:commandButton ?

Jsf Solutions


Solution 1 - Jsf

<h:button>

The <h:button> generates a HTML <input type="button">. The generated element uses JavaScript to navigate to the page given by the attribute outcome, using a HTTP GET request.

E.g.

<h:button value="GET button" outcome="otherpage" />

will generate

<input type="button" onclick="window.location.href='/contextpath/otherpage.xhtml'; return false;" value="GET button" />

Even though this ends up in a (bookmarkable) URL change in the browser address bar, this is not SEO-friendly. Searchbots won't follow the URL in the onclick. You'd better use a <h:outputLink> or <h:link> if SEO is important on the given URL. You could if necessary throw in some CSS on the generated HTML <a> element to make it to look like a button.

Do note that while you can put an EL expression referring a method in outcome attribute as below,

<h:button value="GET button" outcome="#{bean.getOutcome()}" />

it will not be invoked when you click the button. Instead, it is already invoked when the page containing the button is rendered for the sole purpose to obtain the navigation outcome to be embedded in the generated onclick code. If you ever attempted to use the action method syntax as in outcome="#{bean.action}", you would already be hinted by this mistake/misconception by facing a https://stackoverflow.com/questions/7950628/javax-el-elexception-could-not-find-property-actionmethod-in-class-com-example.

If you intend to invoke a method as result of a POST request, use <h:commandButton> instead, see below. Or if you intend to invoke a method as result of a GET request, head to https://stackoverflow.com/questions/2451154/invoke-jsf-managed-bean-action-on-page-load or if you also have GET request parameters via <f:param>, https://stackoverflow.com/questions/10724428/how-do-i-process-get-query-string-url-parameters-in-backing-bean-on-page-load/


<h:commandButton>

The <h:commandButton> generates a HTML <input type="submit"> button which submits by default the parent <h:form> using HTTP POST method and invokes the actions attached to action, actionListener and/or <f:ajax listener>, if any. The <h:form> is required.

E.g.

<h:form id="form">
    <h:commandButton id="button" value="POST button" action="otherpage" />
</h:form>

will generate

<form id="form" name="form" method="post" action="/contextpath/currentpage.xhtml" enctype="application/x-www-form-urlencoded">
    <input type="hidden" name="form" value="form" />
    <input type="submit" name="form:button" value="POST button" />
    <input type="hidden" name="javax.faces.ViewState" id="javax.faces.ViewState" value="...." autocomplete="off" />
</form>

Note that it thus submits to the current page (the form action URL will show up in the browser address bar). It will afterwards forward to the target page, without any change in the URL in the browser address bar. You could add ?faces-redirect=true parameter to the outcome value to trigger a redirect after POST (as per the Post-Redirect-Get pattern) so that the target URL becomes bookmarkable.

The <h:commandButton> is usually exclusively used to submit a POST form, not to perform page-to-page navigation. Normally, the action points to some business action, such as saving the form data in DB, which returns a String outcome.

<h:commandButton ... action="#{bean.save}" />

with

public String save() {
    // ...
    return "otherpage";
}

Returning null or void will bring you back to the same view. Returning an empty string also, but it would recreate any view scoped bean. These days, with modern JSF2 and <f:ajax>, more than often actions just return to the same view (thus, null or void) wherein the results are conditionally rendered by ajax.

public void save() {
    // ...
}

See also:

Solution 2 - Jsf

h:button - clicking on a h:button issues a bookmarkable GET request.

h:commandbutton - Instead of a get request, h:commandbutton issues a POST request which sends the form data back to the server.

Solution 3 - Jsf

h:commandButton must be enclosed in a h:form and has the two ways of navigation i.e. static by setting the action attribute and dynamic by setting the actionListener attribute hence it is more advanced as follows:

<h:form>
    <h:commandButton action="page.xhtml" value="cmdButton"/>
</h:form>

this code generates the follwing html:

<form id="j_idt7" name="j_idt7" method="post" action="/jsf/faces/index.xhtml" enctype="application/x-www-form-urlencoded">

whereas the h:button is simpler and just used for static or rule based navigation as follows

<h:button outcome="page.xhtml" value="button"/>

the generated html is

 <title>Facelet Title</title></head><body><input type="button" onclick="window.location.href='/jsf/faces/page.xhtml'; return false;" value="button" />

Solution 4 - Jsf

This is taken from the book - The Complete Reference by Ed Burns & Chris Schalk

h:commandButton vs h:button

> What’s the difference between h:commandButton|h:commandLink and > h:button|h:link ?

The latter two components were introduced in 2.0 to enable bookmarkable JSF pages, when used in concert with the View Parameters feature.

There are 3 main differences between h:button|h:link and h:commandButton|h:commandLink.

> First, h:button|h:link causes the browser to issue an HTTP GET > request, while h:commandButton|h:commandLink does a form POST. This > means that any components in the page that have values entered by the > user, such as text fields, checkboxes, etc., will not automatically > be submitted to the server when using h:button|h:link. To cause > values to be submitted with h:button|h:link, extra action has to be > taken, using the “View Parameters” feature. > > The second main difference between the two kinds of components is that > h:button|h:link has an outcome attribute to describe where to go next > while h:commandButton|h:commandLink uses an action attribute for this > purpose. This is because the former does not result in an ActionEvent > in the event system, while the latter does. > > Finally, and most important to the complete understanding of this > feature, the h:button|h:link components cause the navigation system to > be asked to derive the outcome during the rendering of the page, and > the answer to this question is encoded in the markup of the page. In > contrast, the h:commandButton|h:commandLink components cause the > navigation system to be asked to derive the outcome on the POSTBACK > from the page. This is a difference in timing. Rendering always > happens before POSTBACK.

Solution 5 - Jsf

Here is what the JSF javadocs have to say about the commandButton action attribute:

> MethodExpression representing the application action to invoke when > this component is activated by the user. The expression must evaluate > to a public method that takes no parameters, and returns an Object > (the toString() of which is called to derive the logical outcome) > which is passed to the NavigationHandler for this application.

It would be illuminating to me if anyone can explain what that has to do with any of the answers on this page. It seems pretty clear that action refers to some page's filename and not a method.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionGeekView Question on Stackoverflow
Solution 1 - JsfBalusCView Answer on Stackoverflow
Solution 2 - JsfdsgriffinView Answer on Stackoverflow
Solution 3 - JsfashishView Answer on Stackoverflow
Solution 4 - JsfFarhan Shirgill AnsariView Answer on Stackoverflow
Solution 5 - JsfjordanpgView Answer on Stackoverflow