• Post Reply Bookmark Topic Watch Topic
  • New Topic

valueChangeListener of rich:comboBox getting called on submit which is unintended  RSS feed

 
Saurabh Kulkarni
Greenhorn
Posts: 8
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm facing a issue where on changing rich:comboBox value, i need to call backing bean. So i'm using valueChangeListener with a4j:support event="onchange" as bellow:


The backing bean method:


The method checkToChangeName() should get call only on change event. But in my case, the methods is getting called on change event & also getting called on submit of the form which i don't need & creating trouble.

I'm using h:commandButton as bellow to submit the form:


Can anyone help me to understand why its calling checkToChangeName() method on submit? & How can i prevent it?
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A ValueChangeEvent is fired when JSF compares the value on the incoming form to the value in the backing bean (returned here by getName()).

A false event means that very likely the incoming name isn't "equal enough". HTML does cruel things to spaces, and therefore a common source of problems is if you have trailing (pad) spaces in the form value and HTML removes them from the form submit.

The best way to check is to capture the old and new values in your valueChangeListener and look at them in a way that makes it plain what the exact values are, including any spaces.
 
Saurabh Kulkarni
Greenhorn
Posts: 8
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm already capturing the old & new value. All the time when this method is gettign called on click of submit, oldValue is the value present in inputBox & new value is blank(not null). So every time it sets the name to blank.
After finishing this method it calls updateProfile() method (which shold get call on submit) where validation fails as name is set to blank.
 
Jaikiran Pai
Sheriff
Posts: 10447
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does it make any difference if you remove the "disabled" attribute on that element just for the sake of testing? I don't fully think that might be interfering with this, but you state that you are receiving an empty value for that element on submit, so might want to see if the disabled attribute is playing a role (it shouldn't in this manner).
 
Saurabh Kulkarni
Greenhorn
Posts: 8
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I tested application by removing "disabled" but still the same issue continues
 
Tim Holloway
Bartender
Posts: 18715
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Something doesn't sound quite right here, but there's not enough information.

First of all, are you attempting to manually change myBean's name property in the valueChangeListener? Because you should not do that. JSF will set the value automatically when the time is appropriate (update model phase).

Secondly, I'm unclear about the "submit" question. ALL server requests from JSF View are submits. An AJAX submit may be a partial form submit, as opposed to the full form submit that an unconstrained commandbutton or commandlink would do, but it's still a submit and the lifecycle processing is virtually identical other than possible constraints on what control values AJAX submits and what parts of the view will re-render.

You cannot have an AJAX submit and a full-form submit in the same request. Each request to the server will be one or the other. And as long as a control is included in a submit and validated, its value-change logic will be executed and if a change is detected, its valueChangeListener will be fired. Since in a full-form submit ALL input control values in the form are submitted (or at least all changed one, per the HTML spec), that means that the valueChangeListener can potentially be fired. Likewise, the valueChangeListener can potentially fire for any AJAX submit that specifically included the control.

However, since only one submit happens per request, normally, the listener won't fire twice, since the first request will have updated the backing bean and thus the subsequent request won't see a change in value.

The other thing that doesn't ring true here is the implication that the value change listener is firing before validation. Unless you're short-circuiting the normal procedures, that should not happen. A value-change event only occurs when the backing bean value is about to change. Failing validation bypasses update of not only that particular backing bean property, but every backing bean property, in accordance with the fundamental JSF requirement that only if every value on the submit is valid will the backing bean be updated (and the action method/AJAX listener fire).
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!