Content-Type: application

[skuramshin]

Hi,

I need to return an application file (f.i. doc or pdf) from a DWR-managed service bean. The bean serializes the file content into the HTTP response and sets appropriate response headers (Content-Type and Content-Disposition). If the DWR service call is made using options httpMethod: 'GET' and responseType: 'dwr.engine.IFrame', the hidden iframe would handle the file content by displaying standard Open or Save As dialog box.

There is one little issue though. The dwr.engine._validateBatch() JavaScript function checks for unresolved batch handlers, finds one (because the response does not contain typical DWR-generated JavaScript code that calls the handler), and calls the error handling. This stops the browser from finishing the HTTP response processing.

Would it be a good idea to provide a batch-level option that would suppress this default behavior and simply call the unresolved batch handler?

if (typeof(batch.validateIncompleteReply) == 'undefined' || batch.validateIncompleteReply) {
  dwr.engine._handleWarning(batch, { name:"dwr.engine.incompleteReply", message:"Incomplete reply from server" });
  break;
} else {
  batch.handlers[i].callback();
  batch.handlers[i] = null;
}

[Joe Walker-3]

DWR in HEAD has a way to handle binary download very cleanly, which should make things really easy. There are some demos of fileupload and download in the war file which might be worth a play.

Joe

On Dec 17, 2007 4:35 PM, skuramshin <sergiy_kuramshin@...> wrote:

Hi,

I need to return an application file (f.i. doc or pdf) from a DWR-managed
service bean. The bean serializes the file content into the HTTP response
and sets appropriate response headers (Content-Type and
Content-Disposition). If the DWR service call is made using options
httpMethod: 'GET' and responseType: 'dwr.engine.IFrame', the hidden iframe
would handle the file content by displaying standard Open or Save As dialog
box.

There is one little issue though. The dwr.engine._validateBatch() JavaScript
function checks for unresolved batch handlers, finds one (because the
response does not contain typical DWR-generated JavaScript code that calls
the handler), and calls the error handling. This stops the browser from
finishing the HTTP response processing.

Would it be a good idea to provide a batch-level option that would suppress
this default behavior and simply call the unresolved batch handler?

if (typeof(batch.validateIncompleteReply) == 'undefined' ||
batch.validateIncompleteReply) {
 dwr.engine._handleWarning(batch, { name:"dwr.engine.incompleteReply",
message:"Incomplete reply from server" });
 break;
} else {
 batch.handlers[i].callback();
 batch.handlers[i] = null;
}
--
View this message in context: http://www.nabble.com/Content-Type%3A-application-tp14373896p14373896.html
Sent from the DWR - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[skuramshin]

Joe, thanks for the advice. The download manager classes in HEAD have a very clean design indeed, and I'm using them already to return BufferedImage to the client - works great.

In this particular case I am working with document BLOBS that are retrieved from JDBC driver as InputStream. I was hoping to see (at some point) a download manager implementation that would attach the data stream to the HTTP response, without using in-memory buffers (that, as you comment in the source, limit scalability) or temp files.

In the meantime, the hack seems to work well - although it's probably not how DWR response handling was intended to work.

Joe Walker-3 wrote:

DWR in HEAD has a way to handle binary download very cleanly, which should
make things really easy. There are some demos of fileupload and download in
the war file which might be worth a play.

Joe