Currently, Fine Uploader uses a POST to send the data to the server - is there a way to change this to a PUT in the options object? I'm using backbone.js, and a POST makes a new record, and a PUT triggers an update.
Thanks.
POST is the most appropriate method for an upload request, mostly because file upload requests are intended to be idempotent. PUT request are more appropriate for non-idempotent (update) requests.
However, there is another reason why PUT is not a good choice here: this will not work in IE9 and older. In those browsers, a form is submitted inside of a hidden iframe for each file to be uploaded, due to lack of File API support. There are only two valid values for the method attribute on a <form>: GET and POST. So you'd have to handle POST requests anyway, unless you are not going to support IE9 and older (not likely).
I am familiar with backbone.js, and there is no reason why POST requests cannot be used, especially in this instance. You haven't provided any specific reason why PUT requests are preferable here, so I can only assume that if there is such a requirement, this is likely due to some logic in your application that should probably be re-evaluated.
Related
So there is a 3rd party ajax call that takes ~5 mins for every request. So when debuggin on local machine, is there a way to simulate that ajax call like maybe store the response somewhere and load that as response every time that call is made to make debugging quicker.
I tried looking at the chrome inspector tool there is a way to resubmit an earlier ajax call, but I need the whole page load execution cycle so thats no use. There is also a way to save the response / or block the URL but no way to simulate/side load the ajax call with a local response saved in maybe a json file or something.
TlDR; Just like there is a way to block a certain URL, Is there a way to specify a certain URL to load local data insted of making the call to the endpoint.
I know software solutions are offtopic for SO, but since this question was unanswered for quite some time, and this functionality is not implemented yet in an browser, so here it goes.
I came across the Chrome Extension named : Mokku: Mock API calls seamlessly
This does seem to fulfil the expectations set.
I’m looking for a neat way to execute a check to see if there are any messages in an inbox (realtime) in a Grails 2.x application.
I’ve moved away from polling via ajax to websockets, which is great at the point where someone actually sends you the message, but when you change to another screen, the “count” still needs to be initialized.
Can anyone advise on a elegant way of doing this?
Interceptors are not ideal as I need to check across just about all controllers
Filters are not ideal because on some screens with graphs there are many ajax request, the check would be run many times for each request.
I’m wondering if there are any other solutions that I’m not thinking of.. but possibly not.
A filter that disregards the check if a request header indicates an Ajax request would work.
Depending on where you need this "count" you could: In your layout (main.gsp for instance) call a tag library which makes use of a service to fetch the count. That way it's only applied to GSPs where the layout is applied (e.g. not any ajax request).
I have an ASP.NET MVC web page that has a file upload control. Under rare conditions the file referenced by the user moves or is deleted on the filesystem prior to the user triggering the post to the page. In IE9 the page successfully posts but the ContentLength is zero (expected) and can be handled server-side. However in Firefox I find that the POST action never reaches the server.
Is there anyway to detect that the file reference is still valid prior to posting the page? Or a way to detect that an error occurred client-side during the POST due to the moved/deleted file?
Using just input type="file", you have no access to check whether the file actually exists until an upload attempt is made. There are some emerging functionalities like FileReader which may help as browsers mature (as it's not available in all browsers) that should make the upload process far smoother (and will make detection of this situation more simple).
If you use an Ajax style upload process, you could initiate the upload right away to help prevent the issue from occurring in the first place.
Or, a bit hacky: one idea for Firefox would be to add a setTimeout in the onsubmit event that fires after a second ... and checks to see if the upload started (by querying the server using Ajax to a JsonResult action/function that can quickly see if an upload started, etc.). It's a bit messy though as you'll need to worry about timing issues -- and may be overkill just to handle the cases where this is occurring.
Is anything that uses JavaScript and asynchronous communication of XML data considered Ajax?
Most people who deal with AJAX would consider any usage of XMLHttpRequest to be AJAX.
This doesn't mean that the request need be async either.
These days, JSON replaces XML for communications.
From wikipedia:
With Ajax, web applications can send data to, and retrieve data from, a server asynchronously (in the background) without interfering with the display and behavior of the existing page. Data is usually retrieved using the XMLHttpRequest object. Despite the name, the use of XML is not needed (JSON is often used instead), and the requests need not be asynchronous.
AJAX seems to encompass any application which retrieves data using the XMLHttpRequest object. Despite it's name you don't need to use XML and I'd wager most AJAX apps these days are using JSON instead. Also they don't necessarily make asynchronous requests. We probably need a new buzzword at this point. Maybe websockets will take off!
The term AJAX and its abbreviation is a misnomer. It has nothing to do with XML. It typically refers to the XMLHttpRequest function. The name of this function again is a misnomer because you could use it to get or send JSON data, plain text, or even binary data now.
AsyncHttpRequest would have been a more appropriate term for the function, and AJAH (Asynchronous JavaScript and HTML) instead of AJAX. On a side note, although XMLHttpRequest allows synchronous requests too, they'd probably be better off getting rid of it altogether.
Typically AJAX applications make good use of asynchronous calls and avoid page refreshes as much as possible. Gmail is a good example. Facebook, on a modern browser, also uses AJAX. Clicking on different links like "News Feed", "Events", etc. doesn't cause a page reload although the path in the address bar changes. Github does the same on modern browsers.
The jQuery AJAX call has a type parameter that allows to specify the method for an async call (GET/POST/PUT/DELETE); documentation states that:
The type of
request to make ("POST" or "GET"),
default is "GET". Note: Other HTTP
request methods, such as PUT and
DELETE, can also be used here, but
they are not supported by all
browsers.
What does this mean for modern browsers? Can I count on jQuery AJAX to make fully RESTful calls, which rely on the PUT and DELETE verbs?
Yes. $.ajax makes the dirty work to allow PUT and DELETE.
Here you'll find more info: Are the PUT, DELETE, HEAD, etc methods available in most web browsers?
I know it's an old question, but I keep on coming here when searching for the browsers HTTP methods support. I never found anything saying exactly which browser supports which call. The link provided is not clear on it too.
Because of that sentence in jQuery manual (they are not supported by all browsers), I've stayed clear for a while of PUT and DELETE and tried to limit myself to GET and POST. However, today I decided to run some tests with IE 6 for a rest API I'm developing and I didn't have any problems to use also DELETE.
If it works in IE6, crappy 2001 technology, it is pretty much likely that it will work everywhere and that sentence on jQuery manual is pretty much obsolete.
I will update this post in the future with further tests. If anyone knows of a browser not supporting ajax calls for PUT and DELETE, I would like to hear.