h:commandButton not working
Mat Anthony
Ranch Hand
Posts: 262
posted 5 years ago
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
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
posted 5 years ago
-
2
-
-
-
-
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.
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.
An IDE is no substitute for an Intelligent Developer.
