As far as I know the #this is to denote the current component triggering the event, such as :
<p:commandButton process="#this" ... />
And in JSF 2 Ajax, the #this can also mean the encapsulating component, like :
<h:inputText ...>
<f:ajax execute="#this" ... />
</h:inputText>
And I have one case where using p:datatable, including or excluding #this can have a different impact upon Ajax partial submit
Here's the example, in this case, the process is using #this, and this works as expected, where when process happens first, and then followed by setPropertyActionListener and last, the action is executed :
<p:column>
<p:commandLink
value="#{anggaranDetail.map['code']}"
process="#this infoAnggaranForm:Anggaran"
update="detailDialogForm:Anggaran detailDialogForm:SubAnggaran"
oncomplete="infoAnggaranDialog.hide()"
image="ui-icon ui-icon-search"
action="#{tInputBean.updateAnggaranSubAnggaran}">
<f:setPropertyActionListener value="#{anggaranDetail}"
target="#{infoAnggaranBean.selectedAnggaranDetail}" />
</p:commandLink>
</p:column>
But when I omit the #this from this example, the setPropertyActionListener and the action are never executed, as if they're not there.
I wonder why ? Perhaps #this has some other meaning other than the current component, perhaps the current record in this example ?
Im using tomcat 7, and these are my dependencies :
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
The PrimeFaces process and standard JSF execute attributes should point to spaceseparated component identifiers of components which JSF should process during the entire JSF lifecycle upon an ajax request (get request parameters, validate them, update model, execute action). The process defaults to #form, the current form, and the execute defaults to #this, the current component. In command links/buttons this is mandatory to execute the actions associated with the link/button itself.
However, in your datatable you have process="#this infoAnggaranForm:Anggaran", thus two components to process. If you omit #this but keep the other component, then it will only process/execute the other component and not the link/button component. If you omit the process attribute it will default to #form. If you have more other input components in the same form, then they will also be processed.
Depending on the concrete functional requirement, you could just keep it process="#this infoAnggaranForm:Anggaran", or omit it. JSF will then process/execute at least both the button and the other component, exactly as you want.
See also:
Understanding PrimeFaces process/update and JSF f:ajax execute/render attributes
Related
I just can't get sorting working. I'm not sure if this should be posted in the Rain forums, because I am just using PrimeFaces for the first time, and purchased/installed the Rain layout. So I'm not sure whether Rain is causing this or not.
I define a standard p:dataTable and use:
<p:column headerText="Name" field="name" filterMatchMode="contains" />
And sort does not work.
Here is my p:dataTable definition:
<p:dataTable id="table" widgetVar="table" stripedRows="true" reflow="true"
value="#{viewBean.dtos}"
var="dto" selection="#{viewBean.dtos}" rowKey="#{dto.id}" paginator="true"
rows="10" rowSelectMode="add">
My PrimeFaces version:
<!-- https://mvnrepository.com/artifact/org.primefaces/primefaces -->
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>10.0.0-RC2</version>
</dependency>
You are using a PrimeFaces version that has some bugs related to sort/filter data tables.
Like this:
DataTable/TreeTable: sortBy not working with client saving state method
You can apply the workarond, but you may face other issues, so
it will be better if you switch to PrimeFaces 11, using the: PrimeFaces migration guide 10.0.0 -> 11.0.0
What exactly are process and update in PrimeFaces p:commandXxx components and execute and render in f:ajax tag?
Which works at the time of validation? What does update attribute do rather than updating value to component from back end? Do process attribute bind value to model? What exactly do #this, #parent, #all and #form in both attributes?
The example below is working fine, but I am a little confused in basic concepts.
<p:commandButton process="#parent"
update="#form"
action="#{bean.submit}"
value="Submit" />
<p:commandXxx process> <p:ajax process> <f:ajax execute>
The process attribute is server side and can only affect UIComponents implementing EditableValueHolder (input fields) or ActionSource (command fields). The process attribute tells JSF, using a space-separated list of client IDs, which components exactly must be processed through the entire JSF lifecycle upon (partial) form submit.
JSF will then apply the request values (finding HTTP request parameter based on component's own client ID and then either setting it as submitted value in case of EditableValueHolder components or queueing a new ActionEvent in case of ActionSource components), perform conversion, validation and updating the model values (EditableValueHolder components only) and finally invoke the queued ActionEvent (ActionSource components only). JSF will skip processing of all other components which are not covered by process attribute. Also, components whose rendered attribute evaluates to false during apply request values phase will also be skipped as part of safeguard against tampered requests.
Note that it's in case of ActionSource components (such as <p:commandButton>) very important that you also include the component itself in the process attribute, particularly if you intend to invoke the action associated with the component. So the below example which intends to process only certain input component(s) when a certain command component is invoked ain't gonna work:
<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="foo" action="#{bean.action}" />
It would only process the #{bean.foo} and not the #{bean.action}. You'd need to include the command component itself as well:
<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="#this foo" action="#{bean.action}" />
Or, as you apparently found out, using #parent if they happen to be the only components having a common parent:
<p:panel><!-- Type doesn't matter, as long as it's a common parent. -->
<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="#parent" action="#{bean.action}" />
</p:panel>
Or, if they both happen to be the only components of the parent UIForm component, then you can also use #form:
<h:form>
<p:inputText id="foo" value="#{bean.foo}" />
<p:commandButton process="#form" action="#{bean.action}" />
</h:form>
This is sometimes undesirable if the form contains more input components which you'd like to skip in processing, more than often in cases when you'd like to update another input component(s) or some UI section based on the current input component in an ajax listener method. You namely don't want that validation errors on other input components are preventing the ajax listener method from being executed.
Then there's the #all. This has no special effect in process attribute, but only in update attribute. A process="#all" behaves exactly the same as process="#form". HTML doesn't support submitting multiple forms at once anyway.
There's by the way also a #none which may be useful in case you absolutely don't need to process anything, but only want to update some specific parts via update, particularly those sections whose content doesn't depend on submitted values or action listeners.
Noted should be that the process attribute has no influence on the HTTP request payload (the amount of request parameters). Meaning, the default HTML behavior of sending "everything" contained within the HTML representation of the <h:form> will be not be affected. In case you have a large form, and want to reduce the HTTP request payload to only these absolutely necessary in processing, i.e. only these covered by process attribute, then you can set the partialSubmit attribute in PrimeFaces Ajax components as in <p:commandXxx ... partialSubmit="true"> or <p:ajax ... partialSubmit="true">. You can also configure this 'globally' by editing web.xml and add
<context-param>
<param-name>primefaces.SUBMIT</param-name>
<param-value>partial</param-value>
</context-param>
Alternatively, you can also use <o:form> of OmniFaces 3.0+ which defaults to this behavior.
The standard JSF equivalent to the PrimeFaces specific process is execute from <f:ajax execute>. It behaves exactly the same except that it doesn't support a comma-separated string while the PrimeFaces one does (although I personally recommend to just stick to space-separated convention), nor the #parent keyword. Also, it may be useful to know that <p:commandXxx process> defaults to #form while <p:ajax process> and <f:ajax execute> defaults to #this. Finally, it's also useful to know that process supports the so-called "PrimeFaces Selectors", see also How do PrimeFaces Selectors as in update="#(.myClass)" work?
<p:commandXxx update> <p:ajax update> <f:ajax render>
The update attribute is client side and can affect the HTML representation of all UIComponents. The update attribute tells JavaScript (the one responsible for handling the ajax request/response), using a space-separated list of client IDs, which parts in the HTML DOM tree need to be updated as response to the form submit.
JSF will then prepare the right ajax response for that, containing only the requested parts to update. JSF will skip all other components which are not covered by update attribute in the ajax response, hereby keeping the response payload small. Also, components whose rendered attribute evaluates to false during render response phase will be skipped. Note that even though it would return true, JavaScript cannot update it in the HTML DOM tree if it was initially false. You'd need to wrap it or update its parent instead. See also Ajax update/render does not work on a component which has rendered attribute.
Usually, you'd like to update only the components which really need to be "refreshed" in the client side upon (partial) form submit. The example below updates the entire parent form via #form:
<h:form>
<p:inputText id="foo" value="#{bean.foo}" required="true" />
<p:message id="foo_m" for="foo" />
<p:inputText id="bar" value="#{bean.bar}" required="true" />
<p:message id="bar_m" for="bar" />
<p:commandButton action="#{bean.action}" update="#form" />
</h:form>
(note that process attribute is omitted as that defaults to #form already)
Whilst that may work fine, the update of input and command components is in this particular example unnecessary. Unless you change the model values foo and bar inside action method (which would in turn be unintuitive in UX perspective), there's no point of updating them. The message components are the only which really need to be updated:
<h:form>
<p:inputText id="foo" value="#{bean.foo}" required="true" />
<p:message id="foo_m" for="foo" />
<p:inputText id="bar" value="#{bean.bar}" required="true" />
<p:message id="bar_m" for="bar" />
<p:commandButton action="#{bean.action}" update="foo_m bar_m" />
</h:form>
However, that gets tedious when you have many of them. That's one of the reasons why PrimeFaces Selectors exist. Those message components have in the generated HTML output a common style class of ui-message, so the following should also do:
<h:form>
<p:inputText id="foo" value="#{bean.foo}" required="true" />
<p:message id="foo_m" for="foo" />
<p:inputText id="bar" value="#{bean.bar}" required="true" />
<p:message id="bar_m" for="bar" />
<p:commandButton action="#{bean.action}" update="#(.ui-message)" />
</h:form>
(note that you should keep the IDs on message components, otherwise #(...) won't work! Again, see How do PrimeFaces Selectors as in update="#(.myClass)" work? for detail)
The #parent updates only the parent component, which thus covers the current component and all siblings and their children. This is more useful if you have separated the form in sane groups with each its own responsibility. The #this updates, obviously, only the current component. Normally, this is only necessary when you need to change one of the component's own HTML attributes in the action method. E.g.
<p:commandButton action="#{bean.action}" update="#this"
oncomplete="doSomething('#{bean.value}')" />
Imagine that the oncomplete needs to work with the value which is changed in action, then this construct wouldn't have worked if the component isn't updated, for the simple reason that oncomplete is part of generated HTML output (and thus all EL expressions in there are evaluated during render response).
The #all updates the entire document, which should be used with care. Normally, you'd like to use a true GET request for this instead by either a plain link (<a> or <h:link>) or a redirect-after-POST by ?faces-redirect=true or ExternalContext#redirect(). In effects, process="#form" update="#all" has exactly the same effect as a non-ajax (non-partial) submit. In my entire JSF career, the only sensible use case I encountered for #all is to display an error page in its entirety in case an exception occurs during an ajax request. See also What is the correct way to deal with JSF 2.0 exceptions for AJAXified components?
The standard JSF equivalent to the PrimeFaces specific update is render from <f:ajax render>. It behaves exactly the same except that it doesn't support a comma-separated string while the PrimeFaces one does (although I personally recommend to just stick to space-separated convention), nor the #parent keyword. Both update and render defaults to #none (which is, "nothing").
See also:
How to find out client ID of component for ajax update/render? Cannot find component with expression "foo" referenced from "bar"
Execution order of events when pressing PrimeFaces p:commandButton
How to decrease request payload of p:ajax during e.g. p:dataTable pagination
How to show details of current row from p:dataTable in a p:dialog and update after save
How to use <h:form> in JSF page? Single form? Multiple forms? Nested forms?
If you have a hard time remembering the default values (I know I have...) here's a short extract from BalusC's answer:
Component
Submit
Refresh
f:ajax
execute="#this"
render="#none"
p:ajax
process="#this"
update="#none"
p:commandXXX
process="#form"
update="#none"
By process (in the JSF specification it's called execute) you tell JSF to limit the processing to component that are specified every thing else is just ignored.
update indicates which element will be updated when the server respond back to you request.
#all : Every component is processed/rendered.
#this: The requesting component with the execute attribute is processed/rendered.
#form : The form that contains the requesting component is processed/rendered.
#parent: The parent that contains the requesting component is processed/rendered.
With Primefaces you can even use JQuery selectors, check out this blog: http://blog.primefaces.org/?p=1867
JSF 2.0+ keywords
#this Current component.
#all Whole view.
#form Closest ancestor form of current component.
#none No component.
JSF 2.3+ keywords
#child(n) nth child.
#composite Closest composite component ancestor.
#id(id) Used to search components by their id ignoring the component tree structure and naming containers.
#namingcontainer Closest ancestor naming container of current component.
#parent Parent of the current component.
#previous Previous sibling.
#next Next sibling.
#root UIViewRoot instance of the view, can be used to start searching from the root instead the current component.
PrimeFaces specific keywords
#row(n) nth row.
#widgetVar(name) Component with given widgetVar.
And you can even use something called "PrimeFaces Selectors" which allows you to use jQuery Selector API. For example to process all inputs in a element with the CSS class myClass:
process="#(.myClass :input)"
See:
https://primefaces.github.io/primefaces/12_0_0/#/core/searchexpression
PrimeFaces 10+ Observer / Event
This allows you to update components based on a custom event name, set by the #obs(event) keyword. For example:
<p:commandButton update="#obs(myEvent)"/>
<h:panelGroup>
<p:autoUpdate on="myEvent"/>
</h:panelGroup>
See:
https://www.primefaces.org/showcase/ui/ajax/observer.xhtml
These are PrimeFaces features to provide partial view processing and partial rendering. You can control what to execute in lifecycle and what to render with ajax.
When using backing bean properties in expression language
process attribute calls SETTER methods
update attribute calls GETTER methods
primefaces forum
I am using primefaces 4.0 and I am having problems with p:outputLabel.
When It is mixed with any other primefaces component it behaves like escape="false"
This field is not processed even if I specify escape="true"
Example:
I have the following html code:
<h:form>
<p:outputLabel value="<b>TEXT</b>" escape="true"></p:outputLabel>
<h:outputLabel value="<b>TEXT</b> " escape="true"></h:outputLabel>
</h:form>
And for the Output I have this
<b>TEXT</b> <b>TEXT</b>
Which is expected behavior. (I am willing to see HTML tags as text).
But when I will add any other primefaces tag like in example:
<h:form>
<p:outputLabel value="<b>TEXT</b>" escape="true"></p:outputLabel>
<h:outputLabel value="<b>TEXT</b> " escape="true"></h:outputLabel>
<p:commandButton value="button"></p:commandButton>
</h:form>
Now even I have escape="true" I get
TEXT TEXT and then the button.
Does any one have experience with this how should I fix this.
Any suggestion.
I solved this issue.
I had this into my pom
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1.12</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.1.12</version>
</dependency>
I just downgraded to 2.1.11 and everything works fine.
I have a strange situation where using #parent, or even explicit id-s dont work in the update attribute. But #form works fine.
I've made a very simple test case, that includes a simple grid whose behaviour is like this :
Every record inside the grid has a modify button
After the modify button is clicked, it'll modify the server data, and the button will be gone, since it'll be only rendered if the record has NOT been modified.
The modify button is like this :
<!-- this works, since it's using #form in the update attribute -->
<p:column>
<p:commandLink
value="modify record"
process="#this"
action="#{testUserBean.modifyRecord(user)}"
update="#form"
rendered="#{not testUserBean.isRecordModified(user)}" />
</p:column>
Notice that the update attribute makes use of #form which makes it work: when the modify button is clicked, it rerenders and disappears.
Substitute it with #this or #parent or the id of the grid, then it will NOT work. For me it's very logical to use the id of the grid in the update attribute, since i would like to refresh the grid after clicking on the buttton.
I tried making use of rowIndexVar="rowIndex" and myGridId:#{rowIndex}:link, but still aint working.
<!-- this does not work -->
<p:column>
<p:commandLink id="link"
value="modify record"
process="#this"
action="#{testUserBean.modifyRecord(user)}"
update="tblUser"
rendered="#{not testUserBean.isRecordModified(user)}" />
</p:column>
Here are the resources for this simple example :
The xhtml file
The JSF Bean file
The user POJO bean
Im using tomcat 7, and these are my dependencies :
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
Tried out primefaces 3.0.M1 also, but it got the same behavior also.
Please share your ideas. Is this a bug or i did something wrong ?
UPDATE
Hello,
I've just finished some testing, but all still fails.
Test 1 (making use of update=":gridRPBDetails") :
The JSF File :
<p:commandLink id="undoLink" value="Undo" process="#this"
action="#{tInputBean.actionUndoRemoveRecord(rpbDetail)}"
update=":gridRPBDetails"
rendered="#{tInputBean.isRemoveRecord(rpbDetail)}"
title="Batalkan buang data" />
The generated xhtml :
<a title="Batalkan buang data" onclick="PrimeFaces.ajax.AjaxRequest('/cashbank/faces/TInput.xhtml',
{formId:'j_idt38',async:false,global:true,source:'gridRPBDetails:0:undoLink',
process:'gridRPBDetails:0:undoLink',update:':gridRPBDetails'});"
href="javascript:void(0);" id="gridRPBDetails:0:undoLink">Undo</a>
Test 2 (making use of update=":gridRPBDetails:#{rowIndex}:undoLink") :
The JSF File :
<p:commandLink id="undoLink" value="Undo" process="#this"
action="#{tInputBean.actionUndoRemoveRecord(rpbDetail)}"
update=":gridRPBDetails:#{rowIndex}:undoLink"
rendered="#{tInputBean.isRemoveRecord(rpbDetail)}"
title="Batalkan buang data" />
The generated xhtml :
<a title="Batalkan buang data" onclick="PrimeFaces.ajax.AjaxRequest('/cashbank/faces/TInput.xhtml',
{formId:'j_idt38',async:false,global:true,source:'gridRPBDetails:0:undoLink',
process:'gridRPBDetails:0:undoLink',update:':gridRPBDetails:0:undoLink'});"
href="javascript:void(0);" id="gridRPBDetails:0:undoLink">Undo</a>
Both tests still fail in terms of clicking the undo button cannot refresh the record of the grid, or even the grid itself.
UPDATE
I've just updated my test using :
<p:commandLink
value="modify record"
process="#this"
action="#{testUserBean.modifyRecord(user)}"
update=":mainForm:tblUser"
rendered="#{not testUserBean.isRecordModified(user)}" />
Notice i used the :mainForm:tblUser, and i've tried the other options and still failed :
:mainForm:tblUser:
:tblUser (when i dont define the form name)
:mainForm:tblUser:#{rowIndex}:linkId
But 1 thing i notice is,nNo matter what i choosed for the update, the update always ends up as tblUser:0
<a onclick="PrimeFaces.ajax.AjaxRequest('/cashbank/faces/test.xhtml',
{formId:'mainForm',async:false,global:true,source:'tblUser:0:j_idt33',
process:'tblUser:0:j_idt33',
update:'tblUser:0'
});" href="javascript:void(0);" id="tblUser:0:j_idt33">modify record</a>
I tried modifying tblUser:0 on the fly using firebug to just tblUser, the partial rendering on the grid works fine.
Im beginning to think that this is a bug when trying to update a grid from inside a grid record.
This has been answered in here.
Here is the quote from the answer :
This is more like a mojarra issue, it should work fine with myfaces
without a wrapper. Workaround is to put a wrapper.
Code:
<h:form id="frm">
<p:outputPanel id="wrapper">
<p:dataTable id="tbl">
//...
<p:commandButton update=":frm:wrapper" />
//...
<p:dataTable>
<p:outputPanel>
</h:form>
Sorry for the late update !
Look at the generated HTML. Since the <p:commandLink> is placed in a <p:dataTable>, its generated client ID is something like this
<a id="someformid:tblUser:0:link">
The 0 is the table row index.
So when you use the relative identifier update="tblUser" on <p:commandLink>, then it will basically search for someformid:tblUser:0:tblUser to update. But this does not exist. You'd like to use an absolute identifier instead, starting with :.
<p:commandLink update=":someformid:tblUser">
<p:dataTable id="mytable"
value="#{dataTableWithLinkBean.list}" var="item">
<p:column>
<f:facet name="header">
Code
</f:facet>
<p:commandLink actionListener="#{dataTableWithLinkBean.viewDetail}"
oncomplete="dlg.show()" process="#this"
update=":mainform:dialog_content">
<h:outputText value="#{item.code}"/>
<f:param name="code" value="#{item.code}"/>
</p:commandLink>
</p:column>
</p:dataTable>
<p:dialog widgetVar="dlg" modal="true" id="dialog"
width="300" height="300">
<h:panelGrid id="dialog_content">
<h:outputText value="#{dataTableWithLinkBean.selectedCode}"/>
</h:panelGrid>
</p:dialog>
Above is the example of link in the datatable that render the dialog.
may be you can try to change
update=":mainform:dialog_content"
to
update=":mainform:mytable"
in this case my tag form is using id mainform, shown as below:
Please note that I've not been trying this. I just have used in my example above to rendering the dialog panel partially. Good luck
Update:
Well I give it a try like this, combine with your updated post
<p:dataTable id="mytable"
value="#{dataTableWithLinkBean.list}" var="item">
<p:column>
<f:facet name="header">
Code
</f:facet>
<h:outputText value="#{item.code}"/>
</p:column>
<p:column>
<p:commandLink value="Modify"
action="#{dataTableWithLinkBean.removeDetail(item)}"
process="#this"
update="mytable"
rendered="#{not dataTableWithLinkBean.isModifier(item)}">
</p:commandLink>
</p:column>
</p:dataTable>
And in the backing bean
public String removeDetail(ClassForTest item){
for(ClassForTest o: list){
if(o.equals(item)){
//do something update to database
item.setModified(true);
break;
}
}
return "";
}
public boolean isModifier(ClassForTest item){
return item.isModified();
}
And it's worked! after I click on the modify button, call the removeDetail method, do some actions, update the modified status. then do update="mytable", and the link modify is gone.
I'm using Mojarra 2.0.4 and primefaces 3.0.M2
FYI, I'm using DataModel in the backing bean, just a simple List
so no rowIndexVar. Maybe when using the DataModel, can produce this problem.
I'm currently experiencing a strange phenomena, where setting the value to the model happens before executing valueChangeListener.
Basically what i would like to happen is :
I change the select menu
The new value get submitted using Ajax to update the myBean (using f:ajax)
Execute a query based on the newly submitted value (using valueChangeListener)
Render the table based on the result from the last query
But what happens when i run it is in this order, 1 - 3 - 2 - 4 (not 1 - 2 - 3 - 4 as i imagined)
Here's the part of the UI :
<h:selectOneMenu label="budget" id="budget"
converter="genericConverter"
value="#{myBean.budget}"
valueChangeListener="#{myBean.actionSearch}">
<f:ajax render="myGrid" />
<f:selectItem itemLabel="Choose one .." noSelectionOption="true" />
<f:selectItems ... />
</h:selectOneMenu>
And this is the excerpt from the bean :
public void actionSearch() {
System.out.println("searching with this.budget == " + this.budget);
...
}
public void setBudget(String budget) {
System.out.println("setting budget : " + budget);
this.budget = budget;
}
And this is the output :
searching with this.budget == xxxx
setting budget : yyyy
What i would like is, setting the budget first from the new value selected in the UI, and then start searching based on the new UI. But i dont know how to achieve that.
And im using Tomcat 7 along with these :
<dependency>
<groupId>org.primefaces</groupId>
<artifactId>primefaces</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-impl</artifactId>
<version>2.0.4-b09</version>
<scope>compile</scope>
</dependency>
I wonder what i did wrong ?
Thank you !
The valueChangeListener is executed during Validations phase, before the Update Model Values phase. It is intented to be able to get a handle of both the old and new value so that you can if necessary do some business stuff (logging?) based on the real change. In JSF 1.x this was however more than often (ab)used to invoke actions on a dropdown change only, but it has to be used in combination with onchange="submit()", immediate="true", FacesContext#renderResponse() and other stuffs. The selected value is to be obtained by ValueChangeEvent#getNewValue() (the ValueChangeEvent is supposed to be definied as method's argument).
For JSF 2.x you don't need the valueChangeListener anymore in such case. You're also not interested in the old value anyway. Use the listener attribute of <f:ajax> instead.
<f:ajax listener="#{bean.actionSearch}" />
This will be executed during Invoke Action phase, after Update Model Values phase.