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

John,

Some quick comments on your solution:

1. Its main drawback is that it puts a lot of burden on form authors
   and maintainers:

 * It is harder to understand from a processing model point of view:
   canceling events, re-dispatching them etc.

 * There is much more code (separate instance to track completion,
   additional event handlers with subtle logic), which will be more
   error-prone.

2. It doesn't come for free either as:

 * It requires XML events improvements (granted those might be welcome
   anyway).

 * Certainly some spec work will be needed.

3. Questions:

 * Do we really want to allow a form author to cancel processor
   initialization?

 * I am not sure how the dispatching of xforms-model-construct-done /
   xforms-ready will work with multiple models.

-Erik

On Wed, Feb 10, 2010 at 10:53 AM, John Boyer <boyerj@ca.ibm.com> wrote:

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