Jeff,

    The solution was to change my source code making the
    listeners different for each component, and they will work
    with RI and myfaces no matter how they are implemented.

Craig,

    The problem that originated this mail has NOT to do with
    the components values, but with the components itself, 
    although they seem related.

    In MyFaces: 
        the components that correspond to event-source are stored in
        the BackingBean during the UpdateModel Phase, so during the
        valueChangeListener process the getSource()/getComponent()
        method does not match any of the BackingBean components.

        My BackingBeans has Request Scope.

    In RI:
        the components that correspond to event-source are in the
        BackingBean when valueChangeListeners are called.
        Also their getValue() method returns the newValue and not
        the oldValue
        

Hope not to mess things up
Tonio



   
On Thu, 2006-06-08 at 09:36 -0700, Craig McClanahan wrote:
> 
> 
> 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