I have index.jsp which has a Trinidad table.
Several columns will have a valueChangeListener bound to a backing bean method.
In the valueChangeListener method I print event getNewValue.
Problem: The method gets called (the event fires) for every changed input in every row every time any valueChange event fires.
I have found no way to reset or otherwise stop this behaviour.
The goal is to fire one value change event when an input is changed and update something with the new value.
Then the "newness" of the firing value should become old. The triggering input should not fire another event unless I change it again because it has been dealt with already.
I don't know if I understood that, but you really shouldn't update the backing bean from the ValueChangeListener. It's intended to signal that a value has changed, but the actual value update is done by a later JSF lifecycle event.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: May 04, 2009
Thanks for the reply. I'm sure it's obvious I'm new to JSF.
To clearify, I want to detect a value change in a <tr:inputText which is inside a <tr:column which is inside a <tr:table. When a value change is detected I want to write the new value to a database. Then I need the changed value to know it is no longer new and not trigger another change event unless I change it again.
Example: I change text in a cell on row 1. The ValueChangeEvent fires.
Then I change a cell in row 2. The ValueChangeEvent fires two times. It has now fired 3 times total.
Problem: The ValueChangeEvent fires for every value that changed since the page was loaded.
If I have a 2 column by 2 row table and change all 4 inputs it will fire the event a total of 10 times.
Every time any value change is fired all of them fire where a value was changed.
Definitely don't update the database in the ValueChangeListener.
Probably the best solution is to keep a list of the changed rows, which you update in the valuechangeListener. Then attach a "submit" commandButton to the page. In the submit action processor, write out the changed rows and clear the changed-row list. The Setter methods for the cell items will have updated your datamodel before the action processor gets invoked.