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

Re: Order of xforms:revalidate and xforms:recalculate

From: Jérôme Nègre <jerome.negre@e-xmlmedia.fr>
Date: Fri, 4 Jan 2002 17:49:36 +0100
Message-ID: <00a101c1953f$f702d200$630aa8c0@fischer>
To: <www-forms@w3.org>
> > > 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
> > 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...

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

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:50 GMT