Re: XForms - Submission on multiple instances?

Hi Lee,

What I'm trying to say is that xforms-submit-done *is* definitely the 
event you are supposed to be able to hook, and that it isn't working for 
you is a bug in an implementation that should be reported.

There has been some discussion about the fact that XForms 1.0 specifies 
the default processing behavior of xforms-submit in such a way as to 
support *synchronous* operations, whereas many implementors want to 
implement asynchronous operations.  However, this issue is orthogonal to 
the problem you are having.  Asynchronous submissions simply require that 
point 5 of Section 11.1 be changed from being a point in the default 
processing of xforms-submit to being simply a statement of what happens 
when the asynchronous submission result is obtained.  So, regardless of 
synchronous or asynchronous behavior, the material *within* point 5 is the 
same, so its instance replacement then 
rebuild/recalculate/revalidate/refresh then dispatch xforms-submit-done.

I know this doesn't help with your immediate problem that the 
implementation you are using has a bug, but it should at least help you to 
help the implementor identify the patch that is needed, and you can at 
least be assured that you are writing the form correctly.

There is no event *after* xforms-submit-done that you could reasonably 
attach to. There are some really "interesting" things you could do within 
your app to work around the problem in a way that should work for all 
implementations, but it's really very ugly.

Cheers,
John M. Boyer, Ph.D.
STSM: Workplace Forms Architect and Researcher
Co-Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Lee Standen <nom@standen.id.au> 
Sent by: www-forms-request@w3.org
10/31/2006 06:03 PM

To
www-forms@w3.org
cc

Subject
Re: XForms - Submission on multiple instances?







Ok,

Basically, the instance which is being submitted first is making changes 
to the database from which instance2 is generated from, so the insert, 
update and all associated actions on instance1 need to be complete 
before I refresh instance2, otherwise it gets stale data.

xforms-submit-done was the event I was trying, but (i suspect) due to 
the inconsistency as far as asynchronous connections go, instance2 is 
being refreshed BEFORE the CGI from instance1 has finished making 
changes to the database.

Is there any other action which can be trapped that would (be more) 
likely to occur after the submission has received a response back from 
the server?

Thanks :)

p.s.  I haven't got the original example working yet, as far as I can 
tell, but I'll take another crack at it this morning, and debug it 
enough to be sure that it is working.




Mark Birbeck wrote:
> 
> Hi Aaron,
> 
>> I think what Lee is saying is that he is doing a submission that will
>> replace the first instance.  And that the act of this replacement of 
the
>> first instance will affect instance nodes in a second instance document
>> (I assume through recalculate or xforms-value-changed handlers?).  So 
he
>> wants to be sure that all of that is done before he goes ahead and
>> submits the second instance document.  So not as simple as just waiting
>> for xforms-submit-done, is it?  It might actually work in some
>> processors due to the nature of single threading, but it isn't
>> guaranteed to work, is it?
> 
> Yes...I agree that this is probably what Lee is saying. (Lee? Is this
> right?) But I think the second submission should not take place until
> the first is complete.
> 
> You are right that some processors are asynchronous and some
> synchronous (and there is a new flag in XForms 1.1 to allow authors to
> make explicit how a particular submission should behave), but you
> should only receive "xforms-submit-done" once the submission has fully
> completed. Whether that action handler runs in a new thread or not
> shouldn't make any difference to the fact that by the time this
> handler _is_ run, the instance should have been updated.
> 
> Ah...hang on though...I've just had one thought...if there are
> calculations involved (bind statements using @calculate) then a
> rebuild might be needed. Perhaps that's the problem that Lee is
> having--perhaps his second submission *is* correctly taking place
> after the first, but because of the way deferred update works, it may
> be that his second instance is not being updated with the data from
> the returned first instance until both submissions are complete, and
> so he never sees it.
> 
> Regards,
> 
> Mark
>