- From: Lee Standen <nom@standen.id.au>
- Date: Wed, 01 Nov 2006 10:52:11 +0800
- To: www-forms@w3.org
Yep, I've sorted out the problem with the event not working...turns out it' was actually generating xforms-submit-error because the CGI script wasn't returning any data (talk about bashing head against wall). We now have a working form, and the issue discussed below is sorted, because xforms-submit-done is being called late enough :) Lee Standen wrote: > > 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:52:40 UTC