W3C home > Mailing lists > Public > www-forms@w3.org > January 2002

Re: Order of xforms:revalidate and xforms:recalculate

From: Alistair Coles <anc@hplb.hpl.hp.com>
Date: Fri, 04 Jan 2002 16:35:27 +0000
Message-ID: <3C35D9CF.3C1F14D4@hplb.hpl.hp.com>
To: www-forms@w3.org

Jérôme Nègre wrote:
> > 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?
> > 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. 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?


> Jérôme

Received on Friday, 4 January 2002 11:38:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:42 UTC