#33 Options to better handle responses

[Anonymous]

If the user does not want to store the uploaded files, but instead wants to create a composite of the uploads, the user will need control to better handle the responses from the server. The postURL does not serve this purpose and quoteReplacement(jsString) may distort response data. For example, if the user wants to create a mosaic or a collage of the uploaded photos or a service to combine several music files or combine chapters into a composite book, etc. The current option is to create a new upload policy.

[Etienne]

I don't understand exatly what you wan.

But my opinion is that such a composite thing is very specific. So it can't be in the standard package.

So it should be done on server side. Then, as you stated, you can hack the applet. It may be more complex than 'just' create a new upload policy.
For instance: create a mosaic of pictures need you to add a lot of multimedia functions. Do you want to create a new Photoshop or Gimp ?

Etienne

[kiku1]

What I am looking for, is for the server side to be able to process multiple files that are uploaded with the convenience of jupload, (without having to save the files on the server side), and to be able to display the response from the server on the browser. Currently, this can be achieved by the serverside saving the input files or one result and returning the processed result in the postURL. Another solution is to override the afterUpload() method of DefaultUploadPolicy and implement the desired functionality.

[Etienne]

I agree with this.

This would be very specific to your needs... So, the best way is to hack the applet, and override the FileUploadThreadHttp class with yours.

Take care that I'm currently rewriting this part of the applet. The afterUpload() method will remain. But its parameter list changed. It currently accept one UploadFileData (the last uploaded file).
I guess I should create a 'afterRequest' method, to enable a easier way to hack the applet.

BTW: you should wait a little before woking on this part of the applet. It should be a matter of days, but it highly depends on the time I'll have to work on this.

Etienne

[kiku1]

Thanks. I was thinking of hooking the jupload (File Upload Applet) front end to Apache Commons File Upload backend. That will mean multiple files uploaded and one single file response. Yes, I guess it is specific, but I appreciate any extendable/overridable methods in any future release.

[Nobody/Anonymous]

FYI: I just commit a rewriting of the upload process.

Check the FilePreparationThread: you can work on files before they are sent to the upload process.
But you'll have to understand how it works: doc is for next week...

In two words:

• Thread 1: FilePreparationThread post files in the preparedFilesQueue.
• Thread 2: PacketPreparationThread read the queue, and build the packets, if several files should be sent in one packet (nbFilesPerRequest applet parameter). The packets are posted on the packetQueue.
• Thread 3: FileUploadThread. Read the packetQueue, and do the upload of each packet toward the server.

If you want to upload multiple files at once, you can use the applet parameter nbFilesPerRequest.

Etienne

[kiku1]

Yes, I did use nbFilesPerRequest.
Unfortunately, I had to access the private byte array body[] from HTTPInputStreamReader as the method readBody() converts the byte array to String responseBody which is accessible to FileUploadThreadHTTP.
Perhaps the byte array to string conversion could have been deferred to an upper level than a handler ....

[Etienne]

Hi,

So adding a getResponsBodyAsByteArray, returning the body could be useful here. Right ?

Etienne

[kiku1]

Thanks. IMHO, the utility/helper classes that are bytes in(put) can have bytes out(put) rather than bytes input and String output. In that case, the byte array would be available to any new customPolicy classes. That is just my opinion, but yes an access to the byte array would be useful.

[Etienne]

The byte array to String conversion needs the correct management of the response encoding. It should remain in the helper.

Having both access seems to be a good response to our two points of views, isn't it ?

Etienne

[kiku1]

Thanks. Yes, definitely it is.

It would be great if higher classes propagate this access all the way to the policy classes, if there are no problems in doing so. On second thoughts, maybe it is not such a good idea to persist the same data as String and byte array for a long time. So I guess, byte array access is good enough.

[Etienne]

Hi,

I added these methods to the HTTPInputStreamReader class.

public byte[] getResponseBodyAsByteArray();
public String getResponseCharset();

You can check if it's Ok for you.

Etienne