h:commandbutton vs h:commandlink

问题

We are using JSF-2.1.7 and in all our form post requests. I am trying to justify whether to use <h:commandButton> or <h:commandLink> . The appearance of <h:commandLink> (href <a/> ) can be controlled using style and jQuery.

Which is recommended <h:commandButton> or <h:commandLink>? Is there any real advantage?

回答1:

There is no functional difference apart from the generated markup and the appearance. The <h:commandButton> generates a HTML <input type="submit"> element and the <h:commandLink> generates a HTML <a> element which uses JavaScript to submit the form. Both are to be used to submit a form. Additional styling is irrelevant to the functionality.

Use the <h:commandButton> if you need a submit button and use the <h:commandLink> if you need a submit link. If that doesn't make sense to you, then I don't know. If you can't decide which one to use, just choose the one which makes the most sense in UI perspective. Ask the web designer if you're unsure.

The difference between <h:commandLink> and <h:outputLink> is by the way more interesting. This is been answered in detail here: When should I use h:outputLink instead of h:commandLink?

回答2:

For a form, I prefer the h:commandbutton

h:commandbutton is like a button in HTML where you can set the action of a backing bean. h:commandlink is like a link in HTML (the tag a) where you also can set the action of a backing bean

To use the css style in JSF, you can use the attribute 'styleClass'.

回答3:

In short, my recommendation is a mix of <h:commandButton type="submit"> for the primary (default) submit button and <h:commandLink>s for any additional buttons (e.g. filter, sort, lookup, preview, generate password, ...).

Lengthy explanation follows:

First, some background: One should probably also be aware of the different <h:commandButton> type attributes. (The type attribute translates directly to the generated <input type=""> attribute.) I haven't found this explicitly stated anywhere, but some tests showed that:

type="submit" (defaults to this if omitted) does the normal "submit" behaviour of the form (i.e. POSTing the form) as well as the action and/or actionListener.
type="reset" does the normal "reset" behaviour (i.e. clearing/resetting the form fields) without calling any action and/or actionListeners.
type="button" generates a button (apparently <input type="button"> is a bit more limited than the <button> tag) without calling any action and/or actionListeners.

Apart from resetting the fields, the latter two seem to be useful only to activate e.g. Javascript. They don't POST the form.

So to answer the question: in a form context:

<h:commandButton> (which is equivalent to <h:commandButton type="submit">, remember) is often the most useful, especially as most browsers now implement activation of the first submit button found in the DOM tree of the form when Enter is pressed. This might improve your form's user experience

E.g. it is somewhat faster to log with:

Username Tab Password Enter

as opposed to

Username Tab Password ... move hand from keyboard to mouse, hunt pointer and position on button, click.

Also keep in mind that any <input> buttons (optionally CSS-styled) can still be reached via keyboard by Tabing until the <a> (CSS-styled as a button) has focus, and then Spacebar.

However, for additional buttons on the form that should do some other action instead of submitting (or "just" clearing the fields), <h:commandLink> would be more appropriate. This can still be reached via keyboard by Tabing until the <a> (CSS-styled as a button) has focus, and then Enter. Note that this is inconsistent with buttons generated with <h:commandButton>, which may be CSS-styled to look identical, but are handled differently by the browser (Tab...Spacebar).

That is the general explanation, BUT there are some issues you might want to take note of...

When you do not have a <h:commandButton type="submit"> button on a form, only a <h:commandLink> button (or even no buttons at all), when the user presses Enter the form is still submitted, but without the benefit of a action{Listener} running. Which might not be too big a problem, as the form values get stored in the backing bean and shown again when the page loads, so apart from the server roundtrip the user will often not notice anything is amiss. But that might not be how you want Enter to be handled.... The only way I can think of at the moment circumventing that, is to put an onSubmit event on the form which activates your default <h:commandLink> button via Javascript.... Arghhhh!!

You should also make sure that your CSS style selectors are sound.

A.mystyle is applied to <h:commandLink>;
INPUT[type=submit].mystyle to <h:commandButton type="submit">;
INPUT[type=reset].mystyle to <h:commandButton type="reset">;
INPUT[type=button].mystyle to <h:commandButton type="button">;

These can of course be concatenated with a comma as the selector for a single style definition. Or if you want to take the risk of something else being styled as a mystyle button, you could omit the A/INPUT specifiers. However, I have styled my buttons as above, so that I could also use this:

SPAN.mystyle definition for when the link or button is disabled (e.g. via the disabled attribute) - this allows you to supply a toned-down (greyed) look for a disabled button.

I have also run into some height differences (line height on Button vs. content height on Link - which may be a problem if your button includes a background image as icon instead of text), and also some slight differences in how :before/:after pseudoclasses are handled. All I'm saying: test and retest your CSS on both <h:commandButton>s and <h:commandLink>s to make sure they look (essentially) the same!

Here is my summary cheat sheet:

JSF                  <h:commandButton <h:commandButton <h:commandButton <h:commandLink>
                      type="submit">   type="reset">    type="button">

Translates to        <input           <input           <input           <a>
                      type="submit">   type="reset">    type="button">
Submit form             POST             no, clears flds  no              POST
Javascript events       YES              YES              YES             YES
action{Listener}        YES              no               no              YES
Enter on form activates YES              no               no              no
Tab...+Enter activates  YES(*)           YES              YES             YES
Tab...+Space activates  YES(*)           YES              YES             no
Highlight on Tab-focus:
- Firefox 32            YES              no               no              no
- Chrome 41             YES              YES              YES             YES
- Internet Explorer 11  YES              YES              YES             YES
- Opera 28              YES              YES              YES             no(*)

(*=Opera 28 seems not to allow tabbing (or Alt+Arrow) to  hyperlinks to activate them.)

回答4:

Correct me if I'm wrong but the first difference between these two is the fact, that <h:commandButton> doesn't need JavaScript to be enabled in a browser. If your webpage is JS heavy then you can use <h:commandLink>, otherwise it might be better to keep it JS free in case your user wants to use sth like Tor Browser and you are ok with it. The second one is how these two will behave in a webpage. The <h:commandLink> will just do what it is supposed to do or sometimes also fire a method from backing bean that has @PostConstruct annotation. While <h:commandButton> may also fire inline JavaScripts which may lead to firing other methods from backing bean. However it will also automatically refresh the view.

来源：https://stackoverflow.com/questions/10688755/hcommandbutton-vs-hcommandlink

标签

jsf

jsf-2

commandbutton

commandlink