Announcement

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

    How to avoid new tab window during export to pdf

    SmartClient Version: v8.3p_2013-01-31/PowerEdition Deployment (built 2013-01-31)

    Running following code auto-opens temporarily in browser new TAB (tested with FF18,FF19,IE9).
    If backend processing takes for whatever reason longer time it brings to the end user confusing experience – opened browser tab for a while and then closed.
    We suspect it is related to the transport type: hiddenFrame
    Is it possible to eliminate temporarily auto-opening of the new browser tab?

    final DSRequest requestProperties = new DSRequest();
    requestProperties.setDownloadResult(true);
    requestProperties.setExportDisplay(ExportDisplay.DOWNLOAD);
    requestProperties.setContentType("application/pdf");

    RPCManager.exportContent(canvas, requestProperties);

    Many thanks,
    zapryano

    #2
    No, this isn't related to hidden frames.

    We have little control over whether the browser uses a new tab, new window, or just a dialog to present a file for download. What little control we have is available via the setting rpcRequest.downloadToNewWindow - try both settings and see what you prefer.

    Comment


      #3
      Our further testing shows that the problem appears if property value downloadResult: true (provable with calling DMI.call(…))
      Changing value of setDownloadToNewWindow does not make any difference for us.

      Following code works without any browser tab opening (direct usage of DMI.call):

      Canvas.getPrintHTML(componentsToPrint, null, new PrintHTMLCallback(){
      public void setHTML(final String html) {
      Map<String, Object> settings = new HashMap<String, Object>();
      settings.put("defaultSkinName", Page.getSkinDir());

      Object[] arguments = new Object[] { html, settings };

      RPCRequest requestParams = new RPCRequest();
      requestParams.setTransport(RPCTransport.HIDDENFRAME);
      requestParams.setDownloadToNewWindow(false);
      requestParams.setDownloadResult(false); // important flag to eliminate opening of new TAB

      DMI.call("isc_builtin", "builtin", "getPdfObject", null, arguments, requestParams);

      }
      });

      Looking into JS sources (RPCManager.js) - server properties are hardcoded (downloadResult:true):

      exportContent : function (canvas, requestProperties) {
      var callback = function (html) {
      var serverProps = {
      showPrompt:false,
      transport: "hiddenFrame",
      exportResults: true,
      downloadResult: true,
      downloadToNewWindow: null,
      download_filename: null
      };
      var settings = {
      skinName: requestProperties.skinName,
      pdfName: (requestProperties.exportFilename == null)?requestProperties.pdfName:requestProperties.exportFilename,
      defaultSkinName: isc.Page.getSkinDir()
      };
      isc.DMI.callBuiltin({
      methodName: "getPdfObject",
      arguments: [ html, settings ],
      requestParams: serverProps
      });
      };
      var HTML = canvas.getPrintHTML({
      printForExport: true
      }, callback);
      if (HTML != null) {
      callback(HTML);
      }
      },

      Seems like setting in SmartGwt value of “downloadResult” does not have any influence, if using “exportContent” .
      final DSRequest requestProperties = new DSRequest();
      requestProperties.setDownloadResult(true);
      RPCManager.exportContent(canvas, requestProperties);

      Comment


        #4
        Sorry for confusion – problem really comes from setDownloadToNewWindow. Since it is hardcoded to “null” in JS  below setting to false has no influence.

        final DSRequest requestProperties = new DSRequest();
        requestProperties.setDownloadToNewWindow(false);

        RPCManager.exportContent(pdfCanvas, requestProperties);

        Comment


          #5
          Both explanations are incorrect.

          downloadToNewWindow's default is false, your setting would have no effect. The null you see in the JavaScript code is already treated as false.

          downloadResult should be hardcoded to true because you are indeed downloading something.

          The reason a new tab is opened is that, if it were not, the browser might choose to display the .pdf inline, wiping out your page. If you set a filename (indicating you expect the file to be saved), you should find that no new tab is opened.

          Comment


            #6
            Following code does not open new TAB.
            Changing setting to requestParams.setDownloadToNewWindow(true) triggers temporarily opening of TAB.
            File name is provided in both cases.

            private static void triggerPdfCreationAndDownload(String html, final Printable printable) {

            Map<String, Object> settings = new HashMap<String, Object>();
            settings.put("defaultSkinName", Page.getSkinDir());
            String pdfFileName = printable.getPdfFilename();
            if(pdfFileName != null){
            pdfFileName = fixPdfFileName(pdfFileName);
            settings.put("pdfName", pdfFileName);
            }

            Object[] arguments = new Object[] { html, settings };

            RPCRequest requestParams = new RPCRequest();
            requestParams.setTransport(RPCTransport.HIDDENFRAME);
            requestParams.setDownloadToNewWindow(false); // important flag to eliminate opening of new TAB
            requestParams.setDownloadResult(true);
            requestParams.setContentType("application/pdf");
            requestParams.setShowPrompt(false);

            DMI.call("isc_builtin", "builtin", "getPdfObject", new RPCCallback(){
            @Override
            public void execute(RPCResponse response, Object rawData, RPCRequest request) {
            }}, arguments, requestParams);
            }

            Comment


              #7
              You're getting yourself a bit confused with this direct call to DMI, and by directly configuring HiddenFrame transport. What you're really doing is bypassing safety code that is there to prevent you accidentally replacing your whole application with a PDF that the browser decides can be displayed inline.

              The correct way to ask for a download vs display in a new window is to set requestProperties.exportDisplay.

              Directly changing the transport is not a supported approach.

              Also note your setContentType() doesn't make sense. You're trying to set the contentType for the *request*, and you are not sending a PDF to the server, so your contentType is not correct. You should remove this call entirely.

              Comment


                #8
                The code in the previous post we provided to prove that setDownloadToNewWindow(false) eliminates opening of new tab in combination of using direct DMI call.

                Back to original question – what we should change in this code to eliminate temporarily opening of new browser tab?

                private static void triggerPdfCreationAndDownload2(String html, final Printable printable) {

                final DSRequest requestProperties = new DSRequest();
                requestProperties.setDownloadResult(true);
                requestProperties.setExportDisplay(ExportDisplay.DOWNLOAD);
                requestProperties.setDownloadToNewWindow(false);
                requestProperties.setAttribute("pdfName", "myFileName");
                Canvas pdfCanvas = new Canvas();
                pdfCanvas.setContents(html);
                RPCManager.exportContent(pdfCanvas, requestProperties);
                }

                Comment


                  #9
                  Just a quick note to let you know this is not being ignored. We're having a developer look into whether there is a framework issue to address here. We'll follow up with more information when we have it.

                  Comment


                    #10
                    We've now made a change which we believe addresses this issue. Please try the next nightly build (dated March 16 or greater)
                    Regards
                    Isomorphic Software

                    Comment


                      #11
                      We tested with version 3.1p.2013-03-18 and can confirm that issue was resolved.

                      Comment

                      Working...
                      X