- From: Lee Standen <nom@standen.id.au>
- Date: Wed, 01 Nov 2006 10:03:31 +0800
- To: www-forms@w3.org
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 >
Received on Wednesday, 1 November 2006 02:04:28 UTC