- From: Alistair Coles <anc@hplb.hpl.hp.com>
- Date: Fri, 04 Jan 2002 16:35:27 +0000
- 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? Alistair > > Jérôme -- ----------------------- Alistair_Coles@hp.com www.hpl.hp.com -----------------------
Received on Friday, 4 January 2002 11:38:01 UTC