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

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

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 25 Feb 2009 11:15:58 -0800
Message-Id: <9348E9A3-A303-4DB5-8444-01A4268B2A8F@orbeon.com>
To: Forms WG <public-forms@w3.org>

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.


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
Received on Wednesday, 25 February 2009 19:16:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:59 UTC