`parseXYZ` options about jquery.serializejson HOT 8 CLOSED

I like more the solution with the data argument.
Also, I think we could add a second (optional) argument to the parseWithFunction option, to send the input name.

The only problem with this would be to explain it properly in the README file without adding too much text/confusion to the plate.

from jquery.serializejson.

I reckon the data arguments should be used to override the form's general options. I.e. correlating parseNumbers: true on a global level with being able to override it with data-sjson-parse-numbers="false".

from jquery.serializejson.

That makes sense. I'll think about it and add an update sometime soon.
Thanks KATT!

from jquery.serializejson.

Got tests added and a beginning of a solution with my parseInputValue method -- but need to wire it in somehow in a nice way. Ideas?

Will look at it more tomorrow.

from jquery.serializejson.

To solve this problem, I implemented :types in the version 2.4.0.

Now you can specify a :type on every input by just appending the type with a colon. This way you can control which input is going to be parsed as string, number, boolean, null, array or object. Which for user-generated values is more safe than using the parse options, that will auto-detect the type to be parsed.

For the example input, the problem could be solved by appending :number to the input name:

<input type="text" name="Numeric -2.25:number" value="-2.25" />`

from jquery.serializejson.

Mate, you should really do the :type thing as a data-attribute for the plugin rather than polluting the name field. 😿

from jquery.serializejson.

I like the idea of

<input type="hidden" name="flags:array" value="[]"> 

However, I get a bad taste of changing the name field with plugin specific attributes.

Should be more like:

<input type="hidden" name="flags" value="[]" data-type="array"> 

from jquery.serializejson.

Yes I know.

When I started implementing the "data-type" stuff I realized that it was going to complicate the code a great deal. It would mean that the plugin would no longer use serializeArray (because it would need to check field by field), and that is one of the reasons why serializeJSON works so well.

I would not like to compromise the simple case of using serializeJSON with no options and with same field names used to submit forms to a Rails backend.

Then, I had the idea of "polluting" the name format, because that can still be used with serializeArray. Well, it makes it more intrusive, and the form is no longer non-javascript compatible. But if someone really wants to change the type of the attribute, the form is already non standard. So it actually doesn't matter to change the field name format.

from jquery.serializejson.