aspose file tools*
The moose likes JSF and the fly likes h:commandButton not working Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "h:commandButton not working" Watch "h:commandButton not working" New topic
Author

h:commandButton not working

Mat Anthony
Ranch Hand

Joined: May 21, 2008
Posts: 237
Hi All,
I'm new to jsf2 and just can get the hang of wat I'm doing wrong

I have created a simple application containing jsf2 and facelets. Every time I click the
commandButton I would expect to go into my UserBean method username. I have debug
set within username and it never goes into it


It's not rocket science but not sure wats going on

file: administration.xhtml


file UserBean.java


Can anybody help

Mat
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

<h:form/>?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

JSF is an HTTP-based framework, not a client/server framework. What that means is that clicking a button doesn't "call a method", it initiates an HTTP Request/Response process in accordance with the JSF lifecycle architecture.

In order for a commandButton or commandLink to actually result in the execution of a backing bean method, a number of pre-conditions have to be met.

First of all, since this is HTTP, the request from the client must be encapsulated within an HTTP form. The JSF form element will generate that, but you must specify it - there's no default.

Actually first of all, in JSF, the whole thing has to be in a JSF view element, but you did that. The form (or forms, for pages containing multiple forms) must be wholly contained within that view.

Having a button in a form guarantees that when you click the button, an HTTP request will be sent to the server. But that's only the start of it.

For HTTP requests that match the FacesServlet URL pattern in web.xml, the Request is then processed by the FacesServlet, which runs through a multi-phase lifecycle. The first step in that lifecycle is to validate ALL inputs coming from that form. If even one input fails validation, the lifecycle short-circuits and returns an error without calling the button's action method.

If the inputs are all valid, they are then used to update their corresponding properties on the backing bean. Thus, before the action method is invoked, the bean has been updated to reflect the latest (valid) values of the input controls on the form.

After the bean is updated, THEN the action method (or actionlisteners) is invoked. Note: people use listeners too much. I think this is because old stale documentation on JSF is still floating around. Listeners have their uses, but there are simpler, cleaner mechanisms that should be used in most cases.

If you code "immediate="true"" on a commandButton or commandLink, the form data will not be submitted, validated, or updated and the action method will be fired directly. This is useful for things like a "Cancel" button where you don't care what people did to the form's input controls, but it's not selective. If you use it, all you'll get is the action, not any data.


Customer surveys are for companies who didn't pay proper attention to begin with.
Mat Anthony
Ranch Hand

Joined: May 21, 2008
Posts: 237
Hi Tim,
that was an absolutely fantastic description of how things work. The web is full of solutions
many don’t work and some with difficulty descriptions to understand.

Thanks for all your help

Mat
 
wood burning stoves
 
subject: h:commandButton not working