Re: Order of xforms:revalidate and xforms:recalculate

> > > May I add a follow-up question: how would this processing (if
> > > confirmed as correct) differ from that for
> > > xforms:valueChanging(11.3.5)?
> >
> > The dispatch of revalidate is added.
> >
>
> Isn't revalidate fired on the particular instance data that the form
> control is bound to, since 11.3.5 says the intermediate value should
> be validated?

In my understanding, 11.3.5 says the intermediate value (and only this one)
is validated, whereas the revalidate event is dispatched to element
<xform:model>, meaning that all values are validated.

> > > Perhaps there is no difference intended, but if that is the case I am
> > > wondering how I could listen for changes to an instance data element
> > > (as opposed to the form control) and distinguish between instance data
> > > changes that were the result of a valueChanged vs. a valueChanging
> > > event.
> >
> > First, I'd prefer that valueChanging doesn't modify the instance data
> > element (like in the previous draft).
> > That said, I think you can do what you want with the help of the
mutation
> > event types introduced in DOM level 2.
>
> Yes, the DOM mutation events would indicate that instance data had
> changed, but not differentiate between valueChanged and valueChanging
> being the cause.

Stupid of me, you're right !

> Obviously if as you say valueChanging does not cause
> instance data to change then this becomes irrelevant. But otherwise,
> would it be useful to have instanceChanged (fired on instance data
> element when it is changed as a result of a valueChanged or a
> recalculation) and instanceChanging (fired on instance data when
> valueChanging occurs and value is valid) events?

I see no other "clean" way to do it...

Jérôme

Received on Friday, 4 January 2002 11:51:11 UTC