I'm trying to create an export type that is not text based, but because ExportForm returns a string this requires a hack (e.g. I can write the bytes to the response and call response.end myself). Any better suggestions?
I'm also wondering why the ContentType is always set to application/octet-stream (at least in the version I'm using), considering the MimeType is a property of the ExportType. Wouldn't text/csv make sense for the csv, etc?
Additionally, a small bug report - if your forms have spaces in their names, the filename of the export gets truncated. Putting quotes around the filename in the header would fix this.
Basically I'm creating an ExportType that creates a zip file containing images from an upload field and an html document with a table displaying the other form data and an img element in the last cell to display the uploaded image.
This is what I'm doing, which prevents the dialog from serving anything because this code calls End on the response after writing it's own file to the response.OutputStream. (I've removed the code that actually writes to the ZipOutputStream to save space.)
public override string ExportForm(Form form)
{
using (var ms = new MemoryStream())
using (var zos = new ZipOutputStream(ms))
{
// insert files into zip, etc
var response = HttpContext.Current.Response;
response.ContentType = "application/zip";
response.AddHeader("Content-Disposition", "attachment; filename=\"" + filename + "\"");
ms.Position = 0;
ms.CopyTo(response.OutputStream);
response.Flush();
response.Close();
response.End();
}
return "";
}
If writing to the response was in a virtual method on the ExportType instead of the dialog, or something like that, it would probably solve my problem in a cleaner way. Something like this, for example:
Binary export type
I'm trying to create an export type that is not text based, but because ExportForm returns a string this requires a hack (e.g. I can write the bytes to the response and call response.end myself). Any better suggestions?
I'm also wondering why the ContentType is always set to application/octet-stream (at least in the version I'm using), considering the MimeType is a property of the ExportType. Wouldn't text/csv make sense for the csv, etc?
Additionally, a small bug report - if your forms have spaces in their names, the filename of the export gets truncated. Putting quotes around the filename in the header would fix this.
Comment author was deleted
Hi Matt,
Yes the exports in Contour are basicly an xslt file that is being used to transfor the submitted records to a certain format.
If you give some more details on what exactly you are trying to do I mightbe able to point you in the correct direction
Thanks for the bug report, I've added it to our issue tracker and it will be fixed in the next maintenance release.
Cheers,
Tim
Hi Tim,
Basically I'm creating an ExportType that creates a zip file containing images from an upload field and an html document with a table displaying the other form data and an img element in the last cell to display the uploaded image.
Cheers,
Matt
Comment author was deleted
Hi Matt,
Currently when creating a new export type the export will always be served
Would if help you if if you return an empty string it doesn't serve but you can handle it on the export type itself?
Regards,
Tim
Hi Tim,
This is what I'm doing, which prevents the dialog from serving anything because this code calls End on the response after writing it's own file to the response.OutputStream. (I've removed the code that actually writes to the ZipOutputStream to save space.)
If writing to the response was in a virtual method on the ExportType instead of the dialog, or something like that, it would probably solve my problem in a cleaner way. Something like this, for example:
This would also enable scenarios where people want a different ContentType or don't want to use UTF8, etc.
Cheers,
Matt
Comment author was deleted
Great idea, will make this happen in our next maintenance release!
Cheers,
Tim
is working on a reply...