0

I have a Wicket application which allows the user to generate PDFs and open them in a popup. I defined my own shared resource like this

public class PdfResourceReference extends SharedResourceReference {

   @Override
   public IResource getResource() {
       return new ByteArrayResource("application/pdf") {
        @Override
        protected byte[] getData(final Attributes attributes) {
            // generate the pdf and return byte[]
        }
       };
   }
}

In the application class I mount it via

mountResource("reportPdf", new PdfResourceReference());

It all works fine and the browser opens the pdf. The problem though is that the name of the pdf file (once the user tries to save it) is always "reportPdf". Our users want the pdf to be named according to the report type or the customer number. Something like "0123someCustomerId_report.pdf"

I've found a similar stackoverflow question which suggest using the "Content-disposition" header. Unfortunately I couldn't figure out how to get it working (it also seems to not be supported by all browsers).

Are there other solutions to this kind of problem? Is it possible to use a mount path with a dynamic (regex like) path?

Community
  • 1
  • 1
black666
  • 2,997
  • 7
  • 25
  • 40

2 Answers2

1

I guess you have a static anchor i html with href="reportPdf".

Use a DownloadLink instead. There you can specify a filename using DownloadLink(String id, IModel<File> model, String fileName) Return the PDF from a IModel, preferably LoadableDetachableModel.

It's pretty much this approach: How to use Wicket's DownloadLink with a file generated on the fly?

Community
  • 1
  • 1
Robert Niestroj
  • 15,299
  • 14
  • 76
  • 119
0

I worked around the problem by supplying "filename" parameters to the mounted URLs like that:

mountResource("reportPdf/${filename}", new PdfResourceReference());

Adding a "filename" parameter to the PageParameters then produces urls like /reportPdf/0123someCustomerId_report and the browser saves it the way our users like it.

Maybe somebody comes up with a better solution, but so far it works great and I didn't have to play around with HTTP headers that every browser interprets differently.

black666
  • 2,997
  • 7
  • 25
  • 40