Re: Ability to suppress rebuild-recalculate-revalidate-refresh on submission completion

I was talking this over with Vlad Trakhtenberg (who works with me on 
XForms), and he pointed out that our problem with multiple consecutive 
submissions is harder than we perhaps appreciated in the past.

Consider the synchronous submission case.  Suppose we were to switch to 
saying it should just set the rebuild-recalculate-revalidate-refresh 
deferred update flags.  Note that on the succeeding submission we have 
step 0 inspecting and doing at least rebuild-recalculate-revalidate.  This 
has been unavoidable, of course, because the behaviors of preceding 
actions (including but not limited to send) can affect what data is sent 
and whether it is sent (e.g. invalid).

I didn't understand your comments about synchronous versus asynchronous 
submissions not being different, but I think the above point negates the 
efficacy of using deferred update flags for this problem in either case.

But it's still worth clarifying that an asynchronous submission *is* quite 
different.  You start it up essentially on another thread of execution, 
and when it is finished, it notifies the main XForms processor thread that 
the results need to be processed.  The main XForms thread will process the 
results as soon as it finishes whatever it is doing.  The processor will 
not, for example, process the results *while* it is in the middle of 
running an action sequence.  So, once you spin up an asynch submission, 
you're pretty much guaranteed that its results will be processed after the 
completion of the outermost action handler that initiated the submission. 
This means that setting the deferred update flags when you process the 
results of an asynch submission is not a meaningful thing to do because 
there is no outermost action handler to execute the results.  This, in 
fact, is *why* we say that we execute 
rebuild-recalculate-revalidate-refresh, rather than just setting the 
deferred update flags.

Net-net, I think we cannot avoid making authors decide whether to either 
suppress updating or perhaps given them the flexibility over which update 
operations to suppress after processing the results.

Cheers,
John M. Boyer, Ph.D.
STSM, Interactive Documents and Web 2.0 Applications
Chair, W3C Forms Working Group
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:
Erik Bruchez <ebruchez@orbeon.com>
To:
Forms WG <public-forms@w3.org>
Date:
02/25/2009 11:18 AM
Subject:
Re: Ability to suppress rebuild-recalculate-revalidate-refresh on 
submission  completion



John,

You bring up a good point. I have argued in that direction once in the
past (although I can't find an actual link to substantiate this ;).

We do not implement the immediate RRRR after synchronous submissions
because it is a performance drag and, honestly, it just doesn't make
much sense: if the spec mandates this for synchronous submission, then
it must also do so for xforms:insert and xforms:delete. Currently it
does not, which is a serious inconsistency.

So I think it is necessary to change the specification. I don't think
we should add a "suppressupdate" attribute, but instead make your
suggested behavior the default, certainly for synchronous submissions
where there is no downside doing this.

Now regarding async submissions: maybe the spec implies that
synchronous vs. asynchronous makes a difference due to the order in
which things happen, but it really shouldn't. We should first think
about a way of making the deferred events work in that case as
well. Maybe say that the replacing an instance/text as a consequence
of an asynchronous submission completion is immediately followed by
xforms-submit-done/error, and the processor must not allow any other
to occur between these two steps.

-Erik

On Feb 25, 2009, at 9:53 AM, John Boyer wrote:

>
> We are hitting increasingly many cases where the mandatory rebuild- 
> recalculate-revalidate-refresh at the end of a submission is proving 
> detrimentally inefficient.
>
> The cases involve scenarios in which authors are performing more 
> than one web service invocation in sequence in reasonably large forms.
>
> We cannot simply say that submission should set the deferred update 
> flags because submissions are usually asynchronous, so their results 
> are processed only after the completion of the outermost action 
> handler that initiated the request.
>
> The desired markup pattern is that each service is invoked from the 
> xforms-submit-done handler of the preceding service, except of 
> course for the first service in the sequence.
>
> In this pattern, we would like to have an attribute like 
> "suppressupdate" that would simply turn off the automatic rebuild- 
> recalculate-revalidate-refresh.
>
> An author would then place suppressupdate="true" in all service 
> requests except the last one in the sequence.
>
> For best results, authors would be advised to put rebuild- 
> recalculate-revalidate-refresh actions into the xforms-submit-error 
> handlers of the second through second to last service, so that the 
> results of any preceding successful submissions would be reflected 
> to the UI.
>
> The form author could also suppress updating but then invoke some of 
> the operations in xforms-submit-done, such as just rebuild and 
> recalculate, if the results of a service are expected to affect 
> later services based on a calculate.  Since following services are 
> more likely to be affected by their use of value attributes, this 
> capability will not be needed often, but it is available and still 
> saves the costly UI refresh in any case.
>
> A feature like this seems a useful addition to XForms 1.2.
>
> John M. Boyer, Ph.D.
> STSM, Interactive Documents and Web 2.0 Applications
> Chair, W3C Forms Working Group
> 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
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/