W3C home > Mailing lists > Public > www-forms@w3.org > July 2009

RE: Questions regarding @incremental

From: Nick Van den Bleeken <Nick_Van_den_Bleeken@inventivegroup.com>
Date: Fri, 10 Jul 2009 10:30:38 +0200
To: "dion.sole@gmail.com" <dion.sole@gmail.com>, "www-forms@w3.org" <www-forms@w3.org>
Message-ID: <98F519CDC2FA6146AE00069E9A1D91FD5D37D6CF1A@erganix.dc.intranet>
Hi Dion,

The difference between incremental equals "true" and "false" is the timing when the UI control commits its changes to the instance AND sends its Value change events (as explained in 4.6.1 and 4.6.3).

In short when incremental is "false" the UI control commits its data to the instance AND sends its Value change events only when both of the following two conditions are met:
  - the user changed the value of a UI control
  - the control is activated or the focus moves away from the form control

When incremental is "true" the UI control commits its data to the instance AND sends its Value change events 'more frequently'. Here we need to distinguish between two groups of controls. The first group contains the input, secret, textarea, range, and upload Controls those controls may update the instance AND send the events at implementation dependent intervals when the user is changing the value of the UI control (for example an implementation may choose to update the instance AND send the events when the user pauses typing for x ms or when he typed n-characters in an input control). The second group of UI controls contains the select and select1 Controls for those controls the implementation should update the instance AND send the events when the selection is interactively changed.

I hope that this e-mail clarifies what the difference is between incremental "true" and "false" and what the impact on instance update and dispatching of the Value change events is. If my e-mail doesn't answers all your questions, or if you have additional questions, please feel free to contact me and the WG.

Regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 821 01 70
Office Fax: +32 3 821 01 71
Nick_Van_den_Bleeken@inventivegroup.com
http://www.inventivegroup.com


> -----Original Message-----
> From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
> Behalf Of Dion Sole
> Sent: dinsdag 23 juni 2009 12:40
> To: www-forms@w3.org
> Subject: Questions regarding @incremental
>
> Hello all.
> I've been working on various form control bugs for the mozilla XForms
> project,
> and I've got a few questions regarding event sequencing, @incremental
> and bound
> node updating:
>
> In sections 4.6.1 and 4.6.3, it's stated that "after the new value is
> placed
> into the bound instance node, the event sequence...". When would such
> an event
> occur that the bound instance node hadn't already been updated by the
> user
> interactively changing the form (4.6.1) or the selection (4.6.3)?
> At first I thought this might be the case if @incremental is false, but
> I can't
> find anything in the actual input and select1 sections that state the
> instance
> data isn't updated until either activation or a focus change.
>
> So would I be correct in assuming that conceptually, the instance data
> is
> updated "as you type" for inputs etc., and updated for select/select1
> if it
> passes the rules in the select1 section (i.e. not empty and matches one
> of the
> items)? And that @incremental is only used to inform other controls
> that the
> bound node has changed since it results in rebuild, recalculate and
> refresh
> being processed?
> I say "conceptually" there because if @incremental is false, it
> wouldn't matter
> if the bound node was updated or not until activation or focus as far
> as the
> rest of the form is concerned.
>
> Thanks, Dion.
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
>


Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
Received on Friday, 10 July 2009 08:31:49 GMT

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