- 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 UTC