W3C home > Mailing lists > Public > public-forms@w3.org > February 2010

Re: XForms initialization use case in response to ACTION-606

From: Leigh L. Klotz, Jr. <Leigh.Klotz@xerox.com>
Date: Wed, 10 Feb 2010 10:30:04 -0800
Message-ID: <785a28328447cbdd04cb155cd054825a.squirrel@graflex.org>
To: public-forms@w3.org
I like xxf:join-submissions, but I wonder if it might be necessary to
specify the start point, instead of relying on the form load as the start
point.  It may be more important do to this once we incorporate
components, because it would allow for better isolation of components. I
can also imagine that even with current XForms, it may be necessary to
specify a join start point that begins at some later point in the
lifecycle.

It may be that we can also use the start-point concept to control the
trigger/action/send+ relationship to trigger re-enablement, as the trigger
could wait for all its initiated actions.

Additionally, it may be possible to expand the start-point to something
ath would help identify and operate on outstanding submission requests and
disambiguate their results (especially in the case of multiple outstanding
submissions from the same submission element).  While it is possible to
incorporate unique request values in the GET parameters or the POST entity
(and pass them back to the response), it may be that offering built-in
tracking all the way from the send or submission all the way though to the
xforms-submit-done or -error event context info would be fairly easy to
implement (as it's nearly required for xxf:join-submissions anyway) and
convenient for application authors.  With unique ids (or serial numbers)
for outstanding submissions, we also would obtain the ability to query
submissions for progress, and to cancel them.

Leigh.
Received on Wednesday, 10 February 2010 18:30:34 UTC

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