Hi Alain, Thank you very much for your feedback. I tried what you suggest, unfortunately, if it works perfectly with XSLTForms 1.3, it doesn’t with XSLTForms 1.5.3, the last submission is still activated twice with this release.
Thanks for your help, Best, Josselin. > Le 13 févr. 2021 à 17:51, Alain Couthures <[email protected]> a > écrit : > > Hi Josselin, > > In this test case, an event is defined so two submissions are to be sent > synchronously, one after one, according to a condition which should be true > for one only. The first one will send again the same event producing a > submission loop effect. But the first one is also altering the loop condition > and it appears that, at the end, the 2 submissions are sent for the same > event just before the latest event being caught. > > The easiest way to control this is to invert the order of the submissions: > the one to be activated at the end is to be tested before the one to be > activated repeatedly. > > <xf:action ev:event="submission"> > <xf:send if="not(instance('sub')/xpr:person[@localType='new'])" > submission="submitBio"/> > <xf:send if="instance('sub')/xpr:person[@localType='new']" > submission="submitNewPerson"/> > </xf:action> > > Thank you for your feedback! > > --Alain >> Le 06/02/2021 14:42, Josselin Morvan <[email protected]> a écrit : >> >> >> Hi Steven, Hi Alain, >> >> I made a short and simple sample to show you how my form works, what it >> does, and the error I get with the submission. >> >> Because I run it with BaseX, I added a little Xquery script that creates the >> db and allows the saving of the submissions. >> If you want to use it, just put the form file into basex/webapp/static >> folder and the Xquery file into basex/webapp/ folder. It is a little REST >> application, just run basexhttp, then go to >> http://localhost:8984/xforms/install <http://localhost:8984/xforms/install> >> to create the db, and to >> http://localhost:8984/static/xsltforms/submissionLoop.xml >> <http://localhost:8984/static/xsltforms/submissionLoop.xml> to access the >> form. >> >> You can access the files on my Github Gist : >> https://gist.github.com/sardinecan/64451cf122095178159804e1ea13b4e5 >> <https://gist.github.com/sardinecan/64451cf122095178159804e1ea13b4e5> >> >> As you’ll see, I have two submissions, one for the added persons, which is >> looping as long as there are new persons, and a second one for the main >> instance which is running when all the new persons have been submitted. >> >> I use the dispatch method, with the xforms-submit-done event, and a @delay : >> >> <xf:action ev:event="xforms-submit-done"> >> <xf:dispatch name="submission" targetid="model" delay="1"/> >> </xf:action> >> >> Then I have a "if" rule to select the submission to run : >> >> <xf:action ev:event="submission"> >> <xf:send if="instance('sub')/xpr:person[@localType='new']" >> submission="submitNewPerson"/> >> <xf:send if="not(instance('sub')/xpr:person[@localType='new'])" >> submission="submitBio"/> >> </xf:action> >> >> Like Steven suggests, I think now that there is a submission activated >> twice, as the submission#submitBio is running two time and it shouldn’t, but >> maybe I’m doing something wrong ? >> >> Thanks a lot for your help, >> Best, >> Josselin. >> >> >>> Le 5 févr. 2021 à 10:54, Steven Pemberton <[email protected] >>> <mailto:[email protected]>> a écrit : >>> Although submissions are by default asynchronous, a submission element may >>> only be activated once at a time. I'm surprised that all the event values >>> are empty; they really shouldn't be for an xforms-submit-error event. >>> >>> There is a difference in semantics between a dispatch with and without a >>> delay, even if the delay is 0, so try making the delay 0, it should still >>> work. The fact that it works with my original dispatch method suggests that >>> the problem is indeed with a submission being activated twice, but my >>> reading of the spec is that it should be possible once submit-done has been >>> dispatched. I will raise this with the working group. >>> >>> Best wishes, >>> >>> Steven >>> >>> On Thursday 04 February 2021 23:42:37 (+01:00), Josselin Morvan wrote: >>> >>> Hi Steven, >>> >>> Thank you for your quick response. Unfortunately, all the error events are >>> empty. >>> So, I tried your method with the dispatch element. At first it didn’t work >>> either, then I added a delay to the dispatch and… it works! >>> As I said, when the submission is done, I update my instance with the >>> server’s response (@xml:id and @localType value, etc.) and then I perform >>> the next submission, maybe all these actions are asynchronous or performed >>> simultaneously, and it produces a conflict? The @delay would allow to >>> really execute the next submission at the end of the entire process? >>> >>> Best, >>> Josselin. >>> >>>> Le 4 févr. 2021 à 22:25, Steven Pemberton <[email protected] >>>> <mailto:[email protected]>> a écrit : >>>> <message>Submission error. error-type: <output >>>> value="event('error-type')"/> error-message: <output >>>> value="event('error-message')"/> response-status-code: <output >>>> value="event('response-status-code')"/> response-reason-phrase: <output >>>> value="event('response-reason-phrase')"/> resource-uri: <output >>>> value="event('resource-uri')"/> </message> >>> >>> >>> -- >> >> _______________________________________________ Xsltforms-support mailing >> list [email protected] >> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
_______________________________________________ Xsltforms-support mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xsltforms-support
