Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    multiFileItem question

    SmartClient Version: SNAPSHOT_v12.1d_2019-04-17/AllModules Development Only (built 2019-04-17)

    Hello, I'm trying the multiFileItem sample, I noticed that when I save the form it doesn't use a queue, I just want to ask if it's not possible to use queueing.

    #2
    Also, I think that the client-side validation for the files upload could be run before even trying to save the master record, isn't it possible?

    Comment


      #3
      Also I'm facing another problem: I have a customSelectExpression on the master record which tells that there are children records, but after the add the master record hasn't got children...and I don't see a callback that I may use to refresh that master record after the children inserts.

      Comment


        #4
        It's not currently possible to use queuing, and although it would be possible to do so in some browsers using recent HTML5 features, it probably isn't desirable: combining all the files together is far more likely to hit maximum request size limitations (at the end server, or in intervening firewalls and proxies) or to cause a timeout which then loses all files.

        Yes, it should be possible to check that none of the uploaded files exceed size limits, but this is not currently implemented. We'll note down the enhancement request.

        About a callback - you could update the client-side caches via DataSource.updateCaches() to reflect the count of related records. Is that what you're asking? Or are you saying that a callback to dynamicForm.saveData() is firing too soon, before child records are done uploading?

        Comment


          #5
          Originally posted by Isomorphic View Post
          It's not currently possible to use queuing, and although it would be possible to do so in some browsers using recent HTML5 features, it probably isn't desirable: combining all the files together is far more likely to hit maximum request size limitations (at the end server, or in intervening firewalls and proxies) or to cause a timeout which then loses all files.
          Thanks, I understand, though in my case I have a pretty low size limit on any single file.
          Originally posted by Isomorphic View Post
          Yes, it should be possible to check that none of the uploaded files exceed size limits, but this is not currently implemented. We'll note down the enhancement request.
          Thanks
          Originally posted by Isomorphic View Post
          About a callback [cut] Or are you saying that a callback to dynamicForm.saveData() is firing too soon, before child records are done uploading?
          Yes, exactly that is the problem.

          Comment


            #6
            File upload has different timing for a MultiFileItem depending on whether the master record already exists, or is being created along with the upload(s):
            • If the master record already exists, then the files will be uploaded as soon as "save" is clicked on the popup - without ever requiring saveData() on the form to be called. In this case, the modal popup stays visible until uploads are complete, so hitting a separate button to, say, call saveData() on the form shouldn't be possible. Is this the case you're focused on?
            • If the master record does not exist, then the file upload will occur when you do a saveData() on the form, but in this case, we're finding that the callback correctly fires only after all the target files have been uploaded. (A fetch may occur afterwards, but the upload is nevertheless complete.)


            So can you supply sample code that reproduces your issue? Perhaps a modified version of the MultiFileItem Sample.
            Last edited by Isomorphic; 24 Apr 2019, 13:31.

            Comment


              #7
              SmartClient Version: SNAPSHOT_v12.1d_2019-04-29/EVAL Development Only (expires 2019.06.28_09.18.25) Licensed to: Isomorphic Software (#ISC_EVAL_NIGHTLY)

              Chrome on OSX

              Originally posted by Isomorphic View Post
              [*]If the master record does not exist, then the file upload will occur when you do a saveData() on the form, but in this case, we're finding that the callback correctly fires only after all the target files have been uploaded. (A fetch may occur afterwards, but the upload is nevertheless complete.)
              It seems to work correctly in the showcase, so I must have overlooked something.

              But I've got another test case, because I'm trying different use cases, and I've found a behaviour which I want to ask if it's something I could rely on.

              Using the FSmultiFileItem sample, I've tried this code:

              Code:
              isc.DynamicForm.create({
                  ID: "form",
                  width: 400,
                  height: 100,
                  top: 0,
                  left: 20,
                  dataSource: uploadTest
              });
              
              isc.DynamicForm.create({
                  ID: "uploadForm1",
                  width: 400,
                  height: 100,
                  top: 150,
                  left: 20,
                  dataSource: uploadedFiles
              });
              
              isc.DynamicForm.create({
                  ID: "uploadForm2",
                  width: 400,
                  height: 100,
                  top: 300,
                  left: 20,
                  dataSource: uploadedFiles
              });
              
              isc.Button.create({
                  title: "Save Form",
                  top: 400,
                  left: 20,
                  click: function () {
                      isc.RPCManager.startQueue();
                      form.saveData(
                          function () {
                              isc.logEcho("form without upload saved");
                          },
                          {transport: "hiddenFrame"}
                      );
                      uploadForm1.saveData(
                          function () {
                              isc.logEcho("first upload saved");
                          },
                          {transport: "hiddenFrame"}
                      );
                      uploadForm2.saveData(
                          function () {
                              isc.logEcho("second upload saved");
                          },
                          {transport: "hiddenFrame"}
                      );
                      isc.RPCManager.sendQueue(function () {
                          isc.logEcho("send queue callback");
                      });
                  }
              });
              
              isc.Button.create({
                  title: "Clear Form",
                  top: 400,
                  left: 200,
                  click: "form.editNewRecord();uploadForm1.editNewRecord();uploadForm2.editNewRecord()"
              });
              If I choose two files and click 'save', I see it uses a queue for the three requests!
              I also see that, even if the uploads are already using transport: "hiddenFrame", I have got to specify that attribute also for the upload requests (why?), otherwise the request without it will be out of the queue.

              BUT...the two upload requests in the queue aren't actually saving the files :-(

              If instead I comment out the form.saveData, leaving only the two upload forms, both with the transport: "hiddenFrame" in the requestProperties, then I see a queue and this time the files are saved.

              So, the questions are:
              1. the latest is a behaviour I may rely on?
              2. is it normal that I must specify transport: "hiddenFrame" also on upload requests?
              3. is it expected that the files aren't saved if there's also a non-upload form in the queue?
              Last edited by claudiobosticco; 30 Apr 2019, 14:07.

              Comment


                #8
                We see the behavior you're referring to and are looking into it.

                Comment


                  #9
                  So as we previously mentioned, multiple files cannot be uploaded at once in a transaction. This sample *appears* to achieve this, but what's actually happening is that the first file uploaded is saved into all of the records, and subsequent files are never uploaded. You were probably fooled, as we were, because you were using just a single file to test.

                  What *is* supported is issuing multiple non-upload requests along with a *single* upload request. But there's no reason to keep looking for a way to force multiple uploads together into a transaction - that won't work.

                  You did also uncover a bug in that the problem should have been reported to you instead of allowing you to proceed, so we'll be fixing that and clarifying the docs.

                  Comment


                    #10
                    We've added some notes to our documentation on queuing about file uploads - specifically that only one file upload may be sent in a queue. If you attempt to send more, we'll immediately send the existing queue, log a warning, and then restart queuing. In that case, since order between separate transactions isn't guaranteed, any callback you pass to the final sendQueue() may be invoked while transactions sent earlier are still being processed by the server.

                    The changes have been ported back to SC 12.0p, and will be in our next nightly builds.

                    Comment


                      #11
                      Noted, thank you.

                      Comment

                      Working...
                      X