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

Good point, except you don't require a UI refresh, which can be  
expensive. So it would still be worth it to change the current  
behavior I think.

My main reasoning for the above remains that updating an instance as  
result of a synchronous submission or of xforms:insert shouldn't be  
different.

> but I think the above point negates the efficacy of using deferred  
> update flags for this problem in either case.

Except for refresh, which unlike rebuild/recalculate/revalidate is not  
required to proceed with a submission.

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

I don't disagree with this, really, when it comes to asynchronous  
submissions. My approach is that there is no fundamental difference  
between:

* a user hitting a key in an input field, therefore causing a sequence  
of events and updates to models and the UI
* an async submission completing and modifying an instance either in  
part or completely

For a user-triggered value change, we say explicity in "4.6.7  
Sequence: Value Change" [1] that RRR should take place. For an async  
submission we do something similar in "11.2 The xforms-submit  
Event" [2]:

* RRR if replace="text"
* RRRR if replace="instance" and XML structure has change

So all good, there is consistency here. But I disagree that it should  
be the same for synchronous submissions.

To summarize my opinion in 2 lines:

+ Async submission: we are consistent with user-triggered changes.
- Sync submission: we are not consistent with xforms:insert or other  
actions which modify the instance in a sequence of actions.

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

I am still not convinced about that.

-Erik

[1] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#rpm-event-seq-vc
[2] http://www.w3.org/MarkUp/Forms/specs/XForms1.1/index-all.html#submit-evt-submit

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

Received on Wednesday, 4 March 2009 01:05:30 UTC