Craig,
See my comments between ================
and thanks for your time
Tonio.
On Thu, 2006-06-08 at 14:47 -0700, Craig McClanahan wrote:
>
>
> On 6/8/06, Tonio Caputo <[EMAIL PROTECTED]> wrote:
> 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.
>
> By "stored in the backing bean", does that mean you are using the
> binding="#{ mybean.mycomponent}" attribute on your components in the
> JSP page, to bind the component instances themselves into the backing
> bean? If so, then this sounds like a different bug in MyFaces --
> those component instances should have been re-established during the
> Restore View phase of the request processing lifecycle. It should
> indeed be the same instance that is the source of the event later on.
==================================================================
Yes that's exactly what I mean, I'm using the binding attribute
for all my components.
==================================================================
> @Matthias (see, I got it right this time): the spec language on
> restoring components with a "binding" attribute is near the end of
> Section 2.2.1. The net effect is that, on a postback of a component
> tree with components using "binding", the value of this component
> property in the backing bean will be set to the one that was
> deserialized ... and this happens in Restore View phase, so that if a
> component fires events in any later phase, the source of the event
> will be == to the component instance that was deserialized.
>
> Craig
>
>
> My BackingBeans has Request Scope.
>
> In RI:
> the components that correspond to event-source are in
> the
> BackingBean when valueChangeListeners are called.
>
> Presuming that "in the BackingBean" means you used the binding
> attribute, that is the way it is supposed to be (i.e. that is the
> behavior required by the JSF specification)..
>
>
> Also their getValue() method returns the newValue and
> not
> the oldValue
>
> That is also the way it is supposed to be. If MyFaces does not do
> either of these, then it needs to be reported as a bug against
> MyFaces.
===========================================================================
Just to make it clear, as I understood from the earlier mails:
(1) if you use value binding (JSP attribute "value") this binding
will not be updated until UpdateModel Phase
(2) if you use component binding (JSP attribute "binding") the binding
must occur in the Restore View Phase (component and all it's
attributes)
===========================================================================
>
>
>
>
> Hope not to mess things up
> Tonio
>
> Craig
>
>
>
> 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
> >
> >
>
>
