On 11/30/06, Chris Hansen <[EMAIL PROTECTED]> wrote:
I noticed that a ValueChangeEvent is not queued when an editable value goes from a valid value to an invalid value (null, or "" for a String). In UIXEditableValue (line 60 of the version I have) there is a check for validity before it determines if the value has changed and, if so, queues a ValueChangeEvent. Is this a bug, or is this check for validity necessary, and why?
This behavior is required. If the value is invalid, it's not really a value... It's identical to the behavior of the JSF spec in UIInput.
This behavior is a difficulty for me because I am trying to display a message to the user via PPR when they complete a section of a form using a ValueChangeListener. The ValueChangeListener does not perform full validation, only makes sure all of the fields in the section of the form are filled out. This works fine when the user completes the section of the form. The problem arises when they edit their previous input and put in a non-valid value (select the unselectedLabel of a SelectOneChoice, erase the text in an InputText, etc.). In that case, no ValueChangeEvent happens, and the message to the user that the section is complete remains displayed incorrectly. Is there another way to approach this problem besides using a ValueChangeListener?
Agreed, but they also have an error message that there was a valdation failure, right?
To me, this behavior is not consistent with what a ValueChangeEvent should be. The value is being changed, but no event is being delivered.
No, the value really hasn't been changed... the "submitted value" has been, but not the value. ValueChangeEvents are defined in the JSF spec... -- Adam
