Open ligaz opened 9 years ago
Nah, I'm not in favor of this. Not sure if XMLHttpRequest
can be clobbered, but if it can, this is something that the consumer of the plugin should do. I'm in favor of APIs, plugins, that cause no surprises and clobbering XMLHttpRequest
out of the box could produce unintended side-effects.
I like the idea of it being a drop-in replacement per Stefans suggestion, but that would not be ideal for everybody. A strong argument against it is that the plugin doesn't support all HTTP methods.
Like I said, I like the general idea, so perhaps we can provide a JS adapter as part of the plugin distribution which users can drop into their project if they like.
A strong argument against it is that the plugin doesn't support all HTTP methods.
Both native frameworks support setting the HTTP method so I guess this is doable.
I like the idea of having the clobbering configurable either via config.xml preference or with JavaScript.
Hi, I see that support for PUT and DELETE was added in the last few months. Does this mean we can manually clobber XMLHttpRequest reliably now, or are there still issues with doing this?
Well, I forked the project and dug around a bit and figured I'd share some observations before I immediately forget everything. :-)
It turns out, it's not just about supporting more HTTP methods. There's also an overall lack of flexibility in terms of content types. Currently, the supported methods assume the content type is application/x-www-form-urlencoded
when encoding the body regardless of what you set in the header.
There is a fork of the original cordovaHTTP project here that shows how to enable application/json
in order to use JSON payloads. It's nice to see how to extend the project in a way to get JSON payloads working for POSTs, and I added JSON support for PUTs as well in a parallel manner in my secureHTTP fork.
However, that implementation requires adding a new postJson
function on the cordovaHTTP
javascript api that's implemented in a new CordovaHttpPostJson
java class. Unfortunately, in terms of more general XHR-like support, structuring things as separate classes per http method per content type seems like it'll explode with permutations and be hard to support.
However, all of the separate http method classes pretty much have the same code in them, so it may be simpler to reduce the duplication and consolidate behavior in to a single class (maybe keeping the upload/download stuff separate) that accept an http verb parameter and dynamically encodes the body based on content-type. My java is pretty rusty, but I may give it a shot if I have time. I wanted to mention it here tho in case anyone interested in this who's more versed in java wants to give it a go.
Currently the plugin requires a brand new Http API to be used instead of familiar ones like jQuery's Ajax or Angular's $http.It would be great if this plugin clobbers the root XMLHttpRequest so that everything works out of the box