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

I think that Erik's proposal is not equivalent to synchrnous submission.  If the initializations are independent, they can go on in parallel, where is all submissions are synchronous, they cannot.
(BTW, see support for async JavaScript in Mozilla 3.6: https://developer.mozilla.org/En/HTML/Element/Script)
 
Erik's propsal introduces a join point for re-establishing sync, which is more flexible than synchronous submission, and can provide better performance.  
 
My own rambling note was intended to point out that the join point's start need not be limited to initial model construction; it should be generalizable to any contiguous set of asynchrnous submission completions, and that doing so may give rise to an easier framework for controlling trigger and xf:submit lifetime.
 
 
Leigh.

________________________________

From: John Boyer [mailto:boyerj@ca.ibm.com] 
Sent: Wednesday, February 10, 2010 10:53 AM
To: Klotz, Leigh
Cc: public-forms@w3.org; Erik Bruchez
Subject: 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 <http://www.ibm.com/developerworks/blogs/page/JohnBoyer> 
Blog RSS feed: http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw <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.