Hi again,
I finally took a look at your patch. The issue it adresses is real,
and I'll work on this for the next release.
Ths issue is that yout patch is coupling two different things in HTTP:
* the method GET,POST,PUT,DELETE,HEAD,OPTIONS
* the content-type header
With a "standard" html form, the content-type is always set to
"application/x-www-form-urlencoded". (the one your fix is calling with
the ?param1=value1&... notation).
This content-type can be sent in a HTTP GET or HTTP POST method...
(not GET only...)
inputEx has more complex fields structures than the standard html
(such as lists, nested forms, etc...). The parameters are not well
standardized yet
(some frameworks support things like ?myArray[0]=value1&myArray[1]
=value2 or ?myHash[key1]=value1&myHash[key2] but not all of
them...)
Furthermore, the input "names" of fields in those nested structures
are not set in inputEx (there is no standard we can follow...)
Only the (implicit) "application/json" content-type was used in the
Ajax Form.
Here is my attempt to support the "application/x-www-form-urlencoded"
content-type, which is the thing you need.
For backward compatibility, the default behavior is still using the
"application/json" content-type, but you can override it by setting
the ajax.contentType option:
inputEx({
type: 'form',
inputParams: {
fields: [....],
ajax: {
method: 'POST',
uri: 'default.php',
....
contentType: "application/x-www-form-urlencoded" //
default is "application/json"
}
}
});
Here is the diff:
http://github.com/neyric/inputex/commit/204d6ce4f8fb23bf12e04b0bcff78b3b19551efe
This still needs some improvements, but should work for you case.
Please let me know.
Regards,