encodeURIComponent

6 views
Skip to first unread message

mykhyggz

unread,
Jul 28, 2009, 3:46:52 AM7/28/09
to inputex
IDK if this was found in the latest release, but sinceI just tracked
down this problem with POST-ing JSON from a textarea that has an '&'
in it, I'll mention it while it's on my mind.

"root/static/js/Form.js" line 130 of 254 --51%

/**
* Send the form value in JSON through an ajax request
*/
asyncRequest: function() {

if(this.options.ajax.showMask) { this.showMask(); }
// >
|||||||||||||||||||||||||||||||||||||||||||| < THIS is what's needed,
I think...
var postData = "value="+encodeURIComponent
(lang.JSON.stringify(this.getValue()));
util.Connect.asyncRequest(this.options.ajax.method,
this.options.ajax.uri, {

mykhyggz

unread,
Jul 28, 2009, 12:55:08 PM7/28/09
to inputex

To clarify, the problem is, I think, pretty clear... it may be a bug
in Gentoo Firefox/3.0.11... or not, but it seems the patch should be
safe in any case.

Basically, the query (POST-ing to a web service) has a "&" in it, and
it fails to pass all the data and close the JSON string.

Just checked my git checkout... seems to be:

checkouts/inputex $ git pull

"Already up-to-date."

.... and encodeURIComponent isn't in this Form.js file, but here I
think it needs to be. ;-)

Anyway, there doesn't *seem* to be another way to fix it, short of
starting yet another account somewhere.... perhaps... so if anyone
else runs into this, I've uploaded a patch to the 'files' area here:

http://inputex.googlegroups.com/web/inputexForm_encodeURIComponent.diff

Hope this helps.

Joe Developer

unread,
Jul 28, 2009, 2:04:31 PM7/28/09
to inp...@googlegroups.com
Hi Mike,
I am setting up an alternative inputex git repo if you wan't to push it there
I have made some other changes including a 'presubmit' hook for the form
probably going to patch up the file upload thing in the near future as well

mykhyggz

unread,
Jul 29, 2009, 12:20:28 AM7/29/09
to inputex
Naturally, that patch broke the 'GET' requests. So, a new patch
coming.

I'll have to have a look at the alternative repo.... at any rate, the
problem is obvious at this point, and I think I have it fixed here.

mykhyggz

unread,
Jul 29, 2009, 4:48:12 AM7/29/09
to inputex
On Jul 28, 9:20 pm, mykhyggz <mhi...@iinet.com> wrote:
> Naturally, that patch broke the 'GET' requests. So, a new patch
> coming.

>
> I'll have to have a look at the alternative repo.... at any rate, the
> problem is obvious at this point, and I think I have it fixed here.

Actually, the problem is obvious: GET doesn't send any parameters. You
have to mangle it first.

I've fixed it so it does, after much pain.

Tomorrow, I'll try to get a good clean patch up for anyone who would
like GET to send form values.

mykhyggz

unread,
Jul 29, 2009, 1:25:42 PM7/29/09
to inputex
Patch inputexForm_encodeURIComponent.diff to Form.js uploaded.
Properly handles async GET request... seems like it actually sends
along the parameters.

Form JSON collected is wrapped in encodeURIComponent and if GET
request, appended to the query uri. Code was cribbed from the 'net,
more or less.

Anyway, it looks like whoever wrote this has done us the favor and set
up this forum. Too bad they are so quiet.

Joe Developer, if you are branching, can we discuss off, maybe off
this forum? There is some interest from some other folks, who have
helped me quite a bit on IRC with my project, in what I'm doing with
inputEx, so it may be good for me to get involved if there's a reason
you are branching.

One of the questions I'd had was if this project is still being
developed, or if it's been more or less abandoned, so maybe you know
more. If there's interest in polishing it, as you seem to be doing,
I'd love to help, if only out of self-interest at this point.

Feel free to email me directly, or maybe there's some IRC #channel you
like?

neyric

unread,
Aug 10, 2009, 5:44:17 AM8/10/09
to inputex
Hi to both of you,

Sorry for the lack of response lately...
We've been in holidays, trying to get our minds off any development :)
The project is still being actively developed !

Actually, I think I made a mistake: I undertook a huge refactoring of
the library, which prevented me from commiting small patches.

Your patches seems great ! I think there's indeed an
encodeURIComponent missing here...

If you want to create a branch: please do !!
The best way to that is to go to the github repository (http://
github.com/neyric/inputex/tree/master) and click "Fork".
If you commit your patches to your fork repository, I'll just need a
click to include them in the master branch !

Sincerly,
Eric

Joe Developer

unread,
Aug 10, 2009, 5:50:48 AM8/10/09
to inp...@googlegroups.com
Hi Eric,

Hope you enjoyed your vacation!

Have a look at your baby in action : http://contest.getafreelancer.com/submit.html

PS, thanks for the undeserved mention ;)

- unomi

http://joedev.no-ip.org
Every Facet, Every Department Of Your Mind Is To Be Programmed By You, And Unless You Assume Your Rightful Responsibility To Program Your Own Mind, The World Will Program It For You.
Chat Google Talk: joe.d.d...@gmail.com Skype: joe-developer MSN: rf2...@hotmail.com

neyric

unread,
Aug 11, 2009, 9:41:36 AM8/11/09
to inputex
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,
Eric


On 29 juil, 19:25, mykhyggz <mhi...@iinet.com> wrote:
Reply all
Reply to author
Forward
0 new messages