W3C home > Mailing lists > Public > public-forms@w3.org > March 2011

Re: incremental delay considered harmful

From: COUTHURES Alain <alain.couthures@agencexml.com>
Date: Tue, 29 Mar 2011 22:05:01 +0200
Message-ID: <4D923B6D.6060002@agencexml.com>
To: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
CC: "Leigh L. Klotz, Jr." <Leigh.Klotz@Xerox.com>, "public-forms@w3.org" <public-forms@w3.org>, "www-forms@w3.org" <www-forms@w3.org>
Nick,

The problem with a calculation is that it has to be performed for each 
control and that it has to be initialized with a quite small value 
because most actions will be rapidly executed. So, for the obviously 
(but just for the author) time consuming actions, the first keystroke 
will always launch them with a too small delay.

Having different XY values or different delay values for different 
devices is surely a problem because a browser cannot say much about the 
device in which it is running. The author, again, has to test the form 
on various devices to adjust values.

Maybe it would be good enough to allow something like delay="yes" so a 
configured initial delay could be used and implementations could try to 
optimize it the way they want. The performance of the device could also 
be measured to adapt the initial delay.

What do you think?

Thanks!

-Alain

Le 29/03/2011 10:57, Nick Van den Bleeken a écrit :
>
> Alain,
>
> To me it still feels that the delay should be something the XForms 
> processor should 'calculate' himself ideally without any specific 
> attributes on the control because:
>
> ·The form author shouldn't have to worry about what the best value for 
> the delay is
>
> ·May depend on the device on which the form is ran
>
> ·May depend the XForms processor (pure client based or client/server 
> based)
>
> ·May even vary on load and or version of the external service that is 
> called
>
> I'm not saying that an XForms implementation couldn't have 
> configuration parameters (or even a processor specific attribute on 
> the control or form if really desired) that can be used to 'calculate' 
> the optimal value for delays between xforms-value-change events.
>
> The implementation is more suited for doing the calculation because it 
> could for example take into account the time needed to process 
> previous xforms-value-change events, and or don't dispatch a new 
> xforms-value-change event until all processing of the previous event 
> is done (also asynchronous submissions -> this should already the case 
> I think because 'Under no circumstances can more than a single 
> concurrent submit process be under way for a particular XForms 
> submission').
>
> Kind 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 
> <mailto:nick.van.den.bleeken@inventivegroup.com>
>
> www.inventivedesigners.com <http://www.inventivedesigners.com/>
>
>
Received on Tuesday, 29 March 2011 20:05:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:55 UTC