grid.exportdata appends file suffix even when i set it

[mathias]

According to your DSRequest.setExportFilename javadoc:

If the exportFilename that you specify does not include an extension, one will be added to it based on the [URL="https://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/types/ExportFormat.html"]ExportFormat[/URL] specified by [URL="https://www.smartclient.com/smartgwt/javadoc/com/smartgwt/client/data/DSRequest.html#getExportAs--"]exportAs[/URL].

This does not appear to be the case (smartgwt 6.0-p20171202):

i set it like this:

 DSRequest props = new DSRequest();
dsRequestProperties.setExportFilename("banana.abc");
grid.exportData(props);

Regardless of whether i set .abc, .xml or something else as the filename ending, when the "exportFilename" parameter is sent to the server, the ending has been taken out and replaced with ".csv".

I tried calling setExportAs(null), no difference. If i call "setExportAs" with XML, the ending is changed to xml, but there are 2 problems:

1. I have the need to set a completely custom file ending for a custom export i do manually (via request.getRPCManager().doCustomResponse())
2. This behaviour does not seem to match what the javadoc says.


Inout appreciated.

[Isomorphic]

It looks like you're running into workarounds we need to apply because some browsers will just ignore the content-type header. But you're taking the wrong approach; if you're doing a custom export, don't start by taking the standard exportData() behavior and trying to alter it, just declare an operationBinding and call it, as shown here.

[mathias]

Hello, thanks for quick response.

1. Regarding approach and the example - not sure if this would work for us. We already use the "operationid" for our own server-side logic, so that a custtom method is called. We then call
getRPCManager().doCustomResponse(), and get hold of the outputstream and write our custom structure directly. We need to tailor the output format in detail, there are lots of specific xml-nodes not part of the actual grid datasource.the method call. The only thing that does not work for us is the filename being used.

2. Regarding the filename. To me, it does make sense that the "setExportFilename" works as one would logically expect, i.e. that the String sent in is the one used. As it works now - that it takes only part of the string, but switches out the ending for something else (and not as described in the java doc), seems convoluted and hard to follow.

[Isomorphic]

Re #2: yes, it’s unfortunate that browser bugs require convoluted workarounds. Fortunately, this one is a non-issue as long as you are following suggested approaches.

[mathias]

And it is unfortunate that your documentation does not match the behaviour. It would have saved me time. I am merely suggesting it to be updated.

I am also not sure what browsers ignoring the content-type header has to do with the "filename" criteria you send in your post body. (especially since you have one criteria for the filename and another one for the suffix). But then again i am apparently no expert.

[Isomorphic]

Older versions of IE and some Firefox versions ignore the HTTP headers require the suffix to be specific values.

But again there is no need to take the approach of asking the framework to do an export, and then not having the framework do the export at all, and we have samples showing the correct approach for custom file export.

[mathias]

OK, so i am going to take another last stab at this.

In fact, i *AM* doing manual export just as in your example (i thought that was obvious from my post#3 above where i mentioned "doCustomResponse" and write directly to outputstream). We always have done custom exports like this.

The issue is that regardless of this, the filename i set in setExportFilename gets altered by your process when "exportData" is called (with a custom operationId as mentioned).

Since i want to set the filename clientside, i thought that i could set the exportFilename and use it in my serverside logic like this:

 request.getRPCManager().doCustomResponse();
RequestContext.setNoCacheHeaders(response);
String filename = request.getExportFilename();
response.addHeader("content-disposition", "attachment; filename="+ filename);

This should work according to your javadoc, but it does not, since the filename is altered, seemingly depending on what the DisplayFormat is set to. (if i don't set it a ".csv" is suffixed to the name)

If you look back at my first post this what i wondered from the start, but instead we have derailed into how i should "follow suggested approaches" (which again i do) I guess i'll just use my own custom criteria for the filename and be done with it.

[Isomorphic]

We are stuck here between end user expectations that we will automatically add a correct extension:

https://forums.smartclient.com/forum...t=31435&page=2

.. and bugs in IE where the extension has to be correct and must be part of the URL, which force us to manipulate the filename to avoid broken exports.

So we have now added an exportFormat of "custom" and documented that you can use that setting to avoid any manipulation of the exportFileName, as well as documented on exportFileName that we will add or correct the extension to work around IE bugs.

[mathias]

I hear you about user expectations. Your "custom" approach sounds reasonable.