• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

ValueChangeEvent fires for every datatable changed value, cannot reset.

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


Given: eclipse 3.4.2
JSF 1.2
Trinidad jsf components

My index.jsp partial code to show what I mean:


index backing bean partial code to show what I mean:
 
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
David Norris
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Tim Holloway
Saloon Keeper
Posts: 27752
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

Another approach if you want something more immediate would be to make the inputText boxes have the "submit" function attached to them using JavaScript (or an AJAX-enabled tag like RichFaces). It would basically be the same thing, but you wouldn't have an explicit submit button on the page. This is usually more trouble than it's worth, though.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic