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

Just for the sake of considering all possibiIites, I wonder if the problem 
can be looked at differently, through the lens of alternate possible 
solutions.

What you're doing, essentially, is turning a set of asynchronous 
submissions into a synchronous process in that you want 
xforms-model-construct-done to block until they complete.

So, one solution is to use synchronous submissions.  I assume there is a 
reason not related to correctness, such as performance, as to why you 
don't want this alternative.

So, next up is still the fact that you want to run a set of asynch 
submissions and then do the UI creation after that.  The UI creation is 
the default processing of xforms-model-construct-done.  In the past, we 
have had no way to conditionally cancel the default action of an event. 
You either cancel it all the time or not at all.  But now we have that 
capability to conditionally run an action and, I assume through XML Events 
2, to conditionally stop propagation and cancel the default action.  These 
seem like more generalized capabilities that we need for many reasons 
besides queuing up and consolidating submission results.

Wouldn't it be sufficient, then, to 
1) launch a sequence of async submissions
2) cancel the default action of xforms-model-construct-done on the 
condition that the submissions are not completed
3) optionally also stop the propagation of xforms-ready on the same 
condition
4) record the completion of each submission via its xforms-submit-done 
event
5) when the xforms-submit-done of each occurs, if the condition of all 
submissions being done is reached, then dispatch 
xforms-model-construct-done again, followed by xforms-ready.

I think one of your technical requirement has to do with having an easy 
way for your processor to tell whether or not to delay the delivery of an 
HTML page to the client side.  Stopping the propagation of xforms-ready 
would do that, if your processor delivers HTML to the user in response to 
xforms-ready on the document root rather than on, say, the model.

Equally important, though, is that on the client side, the same strategy 
does not block the operation of the client engine.  Instead, the user is 
presented with a very basic interface until the submissions complete.

The net here is that this kind of solution rationalizes the technical 
needs of both types of processors and doesn't really require the addition 
of much if any new capabilities.  The only new thing is ensuring XML 
Events 2 has the capabilities described above, which as I said we seem to 
have need of in other scenarios.

Best regards,
John M. Boyer, Ph.D.
STSM, Lotus Forms
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw





From:
"Leigh L. Klotz, Jr." <Leigh.Klotz@xerox.com>
To:
public-forms@w3.org
Date:
02/10/2010 10:30 AM
Subject:
Re: XForms initialization use case in response to ACTION-606



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.