Difference between h:button and h:commandButton
JsfButtonJsf 2Jsf 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.