On 6/8/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote:
Tonio,

Your description of the phases sounds about right, and it makes sense
why you ran into that problem.

Let me check the diagram in Core JSF, to double-check... yep, Backing
bean shouldn't have been updated when your listener is called. Sounds
like you may have found a bug in the RI, albeit one that was convenient
to you at the time. :)

You'd be better off looking at the JSF spec and the API javadocs, which are authoritative :-).  And the RI is working correctly on this point ... values *inside* an editable value holder will have been updated by the time value change event listeners are called.

What will not have happened yet is pushing the updated value back to your model, if you use a value binding _expression_ on the "value" property.  That doesn't happen until the following phase (Update Model Values), which won't start until all the value change events have been fired in Process Validations.

@Martin ... check particularly the API javadocs for UIInput.validate() ... in there you will see that setValue() is supposed to be called immediately after the validations have succeeded for a particular component.  Value change listeners aren't called until the end of Process Validations, after *all* the validations on the entire component tree have been processed.

You said you already have a solution or workaround for this right?

If you want to know what the old value was, call getOldValue() on the event ... that's what it is there for.  You can also call getNewValue() on the event, so if that's all you need to know you don't even need to bother looking up the source.

Regards,

Jeff Bischoff
Kenneth L Kurz & Assoc, Inc.

Craig

Reply via email to