Enterprise Client Community

Hi,

we have a standalone Java Client (with PageWebStart) in which the user can download some .pdf files, which are generated by the server. The download is done with the component <t:filedownload/> with localfilemode dark and openimmediately set to true.

1. If the user chooses to generate a single .pdf file, it will be downloaded and opened in Acrobat Reader at the Client automatically. It all happens with one click.

2. But if we try this with multiple files it doesn't work. Only the first file is downloaded, the others get lost. (It's actually reasonable since the response can only transfer one single file each time).

It is required that all the files are downloaded and opened in Acrobat Reader with a single click. Our customer doesn't want a solution with a .zip file comprising other .pdf files. The users don't want to open the .zip file to view the .pdf files.

Does anyone have an idea, how to achive this?

Thank you in advance.

Best regards.

B.Yilmaz

Hello,

(short answer: read *4*)

we faced a similar problem in the RISC-Client. We refactored the download behavior to be more user friendly in Browser-Environments.

The files are generated in sub threads and saved to the disk. Actually files, not byte-arrays in memory. After the thread finishes it writes its status into an queue (Queue<DownloadInfo>) inside the managing UI-class (DownloadManagerUI).
The DownloadManagerUI will be triggered to do a roundtrip (via longpolling) and in the longpolling action we trigger the download of the next file of the queue. Since we have an actual file and we are in an RISC-Environment, we use the t:jshowurl component. To save the file we use the CC-FileManager.
Is the queue not yet empty, we call another roundtrip (not via longpolling, but a additional t:callserverontrigger) and repeat the step above until the queue is empty.

More explanation:
*1*
We used two different triggers, longpolling and callserverontrigger, to synchronize the Main-UI-Thread and the Sub-Threads who will generate the files. The Sub-Threads are triggering the longpolling (wakeup). If the Sub-Threads are quicker then the roundtrip (two wakeup-calls inside a single roundtrip) we may lose information to trigger the download. Thats why we write into a queue and need the t:callserverontrigger to watch inside the queue if we maybe missed something since the last roundtrip.

*2*
You will likey need to remove the generated files manually from the (server-) disk. Or use the CC-TempFileManager (org.eclnt.jsfserver.util.tempfile.TempFileManager).

*3*
In our case the DownloadManagerUI has a list of download files. And a button to re-download. And you may abort the running threads if you trigger a lot of downloads. So it is a nice little usability tool...

*4*
Before the RISC-Environment (Java-Client, like in your scenario) we generated the PDF inside the Main-UI-Thread, triggered the download and used the feature "withcallback" of the t:download component to trigger the next download.

Actually you can try to use the "withcallback" function in your scenario. In a RISC-Environment this option ist not "safe". Browsers have different behavior on this matter.

greetings
Ruven

Hi Ruven,

i tried your solution as described at point "4". It works.

Thank you for your detailed explanation.

Best regards
Baris