W3C home > Mailing lists > Public > www-forms@w3.org > March 2006

Re: "Tracking" submission progress?

From: John Boyer <boyerj@ca.ibm.com>
Date: Tue, 28 Mar 2006 09:40:01 -0800
To: "Allan Beaufour" <beaufour@gmail.com>
Cc: www-forms@w3.org, www-forms-request@w3.org, w3c-forms@w3.org
Message-ID: <OFE84B0455.7A030F43-ON8825713F.005FAC7C-8825713F.00610E85@ca.ibm.com>
Hi Allan (and David),

I agree it could be done with two events. 
It might be better to keep it as one event, though, and use event context 
to distinguish states of progress because
then we won't get into an event soup every time a new submission protocol 
is considered.

It remains easy to set up an event handler that is keyed to a particular 
state of progress because we have the 'if' attribute:

<xforms:action ev:event="xforms-submit-progress" if="event()/state = 
'uploading' ">
    <!-- show progress of upload -->
</xforms:action>

The uploading and downloading states would have other context info like 
bytes sent or received and content length (if known).

An example of the advantage to using event context rather than more events 
could be seen when considering
the https protocol, which could add states for authenticating and 
authenticated without adding more events.

It would then be easy to have a simple output that listens for all 
progress and reports all states.
It would be important for such a listener to translate between the state 
names, which are code, and the localized
versions of those state names, of course.

But in any case, another example that bends toward a single event is that 
the event context should have
a writable node called something like 'cancel'.  So, if the user triggers 
a cancellation, e.g. by pressing a button,
this could be stored in instance data, and if this is done, then the 
cancellation could be transferred to the event
context on the next xforms-submit-progress, e.g.

<trigger>
   <label>Cancel Submission</label>
   <setvalue ref="/data/userCancel" value=" 'true' "/>
</trigger>

...

<action ev:event="xforms-submit-progress" 
if="boolean-from-string(/data/userCancel)">
   <setvalue ref="event()/cancel" value=" 'true' "/>
   <setvalue ref="/data/userCancel" value=" 'false' "/>
</action>

The key here is that I can easily write the cancellation with a single 
handler without regard for what state the
submission might be in.

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/boyer/index.jsp





"Allan Beaufour" <beaufour@gmail.com> 
Sent by: www-forms-request@w3.org
03/27/2006 11:50 PM

To
John Boyer/CanWest/IBM@IBMCA
cc
www-forms@w3.org
Subject
Re: "Tracking" submission progress?







On 3/27/06, John Boyer <boyerj@ca.ibm.com> wrote:
> Rather hoping for the event-based approach of having 
xforms-submit-progress where
> the event context contains bytes received and, if available, download 
size.  Also need
> upload size and progress.

Ok, events do give a lot more flexibility, although it needs some more
work from the form author. I liked the simplicity of the attribute
approach, but events are fine too. Possibly with two different events
as David proposed.

--
... Allan
Received on Tuesday, 28 March 2006 17:40:34 GMT

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