My final decision about cross-domain requests: They can be headache. Especially if your requests are bound on some headers. There are new recommendations for this like "
Cross Origin Resource Sharing". But this is so new to apply because it makes your application browser dependent. There are still many users on internet using ancient browsers and we can't force them to use latest version of specific browsers. Also server we're trying to access must support this. Because we actually asking server if it accepts some parameters, headers etc. Besides this, jsonp and script methods may be enough for lots of purposes. But to make oauth authenticated requests to gdata server, it wasn't. So i changed my approach. I saw oauth gadgets use the same approach: providing a proxy url on same domain that serves as a gateway and removes all cross-domain concerns.
That proxy url doesn't care about what request does. It just takes method, gdata server, url, data, headers as parameters and makes a request to gdata server and returns response directly to the client.
After resolving cross-domain request problem, i started to develop "list exporting" feature. For now i'm able to create an empty spreadsheet when user clicks "export to spreadsheet" button. Here are some screenshots of current state:
Button for exporting:
Uploading may take time, so it's stressed in a dialog window.
After upload complete, user may click to see the document:
Document is exported with the name of the list:
Posts
No comments:
Post a Comment