We have a HTML page containing the HTML table which is populated dynamically with content from server. The requirement is to able to export the HTML table to excel in IE as well as Firefox.
We are trying following approach -
The HTML table is first being sent to the server with the content as a POST request using XHR.
at the server side there is HttpServlet which is sending the content back with MIME type as "application/vnd.ms-excel" as a repsonse to the POST request.
At the browser the status of request is monitored and is observed as 200. However we are not getting any prompt from browser for opening the excel.
Appreciate if someone can help with this and throw some light on what we are missing on.
Thanks,
Adish
You have to use form submit instead of XHR if you want a single one POST request to handle that.
If you want to use ajax. The excel file needs to be cached or persisted somewhere. The server returns the url for the excel file in response of xhr post. Then in the success callback use window.open(url) to GET the file, which will prompt for downloading. This will use two requests.
I am not sure if iframe can work around.
Related
I am trying to write my first chrome extension. The workflow goes something like this -When the extension is installed and active if a user hovers over a specific product/ID displayed on the page, the extension retrieves related vendor data about the product with the ID.
This is how I thought about this:
Use jQuery attr to access the ID on mouse over.
Post this ID to a retrieve.php file with .post() method
The retrieve.php file retrieves the data from database
Display the data in a tool tip on the web page.
I have some queries for the above process:
I am able to get this working on a local XAMPP server but how will it work online as the chrome extension will not have access to server. What is the way around to retrieve data without using PHP?
I am able to get the logic working but am unable to place these in respective files - Will all my logic reside in background.js ?
Any suggestions on getting this started will be much appreciated.
You could build a very simple API on your server that responds with JSON to any request it receives after processing it. Like this:
{"firstVar":"foo","secondVar":"bar" }
Your chrome extension can then make an xmlhttp request to this server and and process the returned data.(You could also use JSONP and wrap the response in a callback function which will execute as soon as you have the reponse)
The JS extension will be able to deal with the JSON nicely as it can understand that format so you can then choose to display the data in whatever way you want.
Essentially, what you want is a server that can take an ID posted to it and return the corresponding date in a nice and readable format. And a chrome extension that can make an request to a server and then process the response. Build and test them separately (keep positing an ID to the server and see the response and for your JS side at first instead of making requests to your unfinished API just set a static response to begin with which will be the same as an expected response.
I have an application that generates a PDF on the fly (accessed via service/generatePdf).
It returns a HTTP response with content-type="application/pdf" and the outputStream set to the binary contents.
Per business specs, when the user clicks a button we need to open a new window/tab that displays that PDF.
Submitting the form below, that all works beautifully on the Happy Path, where the response is an actual PDF.
<form action="service/generatePdf" method="post" name="PdfForm" target="_blank">
However, what does not work so well is when the PDF can't be generated for whatever reason. For example, let's say that the HTTP response outputStream is empty.
What I want to be able to do is display a nice error message on the first page, and not open the new window/tab.
But there doesn't seem to be any way to do it. Your choices seem to be
Return a valid PDF, or
Live with how the browser's PDF plugin handles corrupt files
I've tried jQuery, Ajax, the jQuery Form Plugin, the jQuery Download plugin plugin, and nothing seems to work.
The server should indicate error or success through a HTTP status code (e.g. 200 = OK, 500 = error). This you can catch in your REST client, with JQuery
$.ajax({
url: 'service/generatedPDF',
error: function(jqXHR, textStatus, errorThrown) {
... // show error message
},
).done(function(data) {
// data contains the PDF
}
It would be better to just create the PDF on the server, put it in a temporary store and send the URL to this PDF in the response. Once the client downloads the file, or after a certain download, the PDF is removed from the store.
In that case you would just open a new window with the URL you received from the server.
If the server provides the PDF in the initial request, you can convert it to a Data URI and open that data URI in a new window.
This is a fairly common requirement. You need to make your REST app a little smarter. It needs to check the result of the LiveCycle PDF generation and, if it wasn't successful, return an HTML response (with a content-type of text/html).
The browser is fairly dumb. It examines the content-type of the incoming response and, based on the content-type, launches the plug-in. It's then up to the plug-in to process the response. The PDF plug-in is also not so bright, it assumes that the incoming data stream is a PDF and if it's empty, it produces an error.
The key here is to send down the right content-type (and content) to the browser, which means checking the PDF result and sending a more appropriate response if the PDF result is a failure.
We often see this in LiveCycle orchestrations too. The temptation is to generate the PDF into a com.adobe.idp.Document object and then return that object directly. This leads to similar problems that you describe. Instead, the better approach is to check the result of the PDF generation. If it is valid, then return that response. If the PDF generation failed, then construct an HTML response in a com.adobe.idp.Document object (with the appropriate text/html content-type) and then return that instead.
I'm posting json to my server and I want to return a csv response and have my browser automatically download the csv.
I know there have been some questions on SO exactly about this topic on the past. So far, I've gathered the following solutions:
Put the request into <form> element. This isn't possible because the JSON is nested and too large to be posted as a string.
Save the csv file (get request) onto the server and then have a separate post request to download it. This is not ideal because I don't want to keep a bunch of useless csv files on my server.
Is there a better solution? Can I make a Post request act like a form submission and automatically get the file to start downloading?
I'm trying to submit a postscript print job directly to printer on port 9100. I tried submitting a form directly to the IP and port, but it includes a lot of header information which obviously messes it up.
Is there a way to do this with jQuery or AJAX (or some other term I don't know about)?
You can't do it with Javascript, it'll only do HTTP requests (e.g. POST/GET), which means you get the full HTTP headers included.
Once WebSockets get more widespread, you could use those and send arbitrary data without the HTTP overhead/payload, but at present, that's only in 'bleeding edge' browsers.
This means you're stuck using a Flash or Java applet at present.
You can create a proxy php script which will accept your POST data from the form, format this data and send it to the printer
If you'd like to submit data to this script in background - please see my answer to the following post:
JavaScript: How do I create JSONP?
I have a CGI script that does a lot things. I'm trying to keep the script very simple and portable. I just need some way for the user to send a message to the server without having to lose the current page. So far, I have the following process:
User loads a "status page" from a CGI script.
The status page has a javascript timer that will read data (not the entire page) from the server every two seconds and alter the status page accordingly.
User clicks a hyperlink element to launch a job on the server.
The CGI receives the parameters from the click and starts the job.
The CGI sends a response of \n
At this point Firefox asks the user if they want to download the CGI script and of course the script is just the \n that the CGI sent. Instead, I want the browser to ignore the response altogether. If my CGI script does not echo a \n apache gives an error. What could I do to tell the browser to ignore the response and stay on the current page? Note that I would rather not reload the current page. I'm thinking there must be some sort of "noop" HTTP response for such a case.
Send back a response with the 204 HTTP status code. From RFC 2616 aka Hypertext Transfer Protocol -- HTTP/1.1:
10.2.5 204 No Content
The server has fulfilled the request
but does not need to return an
entity-body, and might want to return
updated metainformation. The response
MAY include new or updated
metainformation in the form of
entity-headers, which if present
SHOULD be associated with the
requested variant.
If the client is a user agent, it
SHOULD NOT change its document view
from that which caused the request to
be sent. This response is primarily
intended to allow input for actions to
take place without causing a change to
the user agent's active document view,
although any new or updated
metainformation SHOULD be applied to
the document currently in the user
agent's active view.
The 204 response MUST NOT include a
message-body, and thus is always
terminated by the first empty line
after the header fields.
Instead of trying to solve this problem on the server side, you might want to investigate a client side solution. For example, using jQuery you can easily initiate an AJAX asynchronous request to the server on a button click. You don't have to load a new page on the browser at all.
Instead of having the hyperlink be a real <a> or <form> with default behavior, have it be some clickable element whose clicks are handled by your client-side code. The Javascript code should send the job requests with XMLHttpRequest objects, putting it in complete control of how the response is handled.