Can't pass json data with a form submit

[aliasmask]

When trying to pass a json structure with form input the parser gets confused and truncates the data.

This is probably a really old issue and has a work around (encode the data first). Probably haven't seen much problem with this because people either probably gave up or just don't use json data.

Original Post: https://forums.rptools.net/viewtopic.php?f=20&t=28318&p=273851#p273850

[Merudo]

I think the issue is with how FormView reads the data (getFormData) from a form. Unfortunately, the method comes from package javax.swing.text.html and is private. I don't really see what we could do change the current behavior beside editing the package itself.

I did find a workaround though! Change the quotes around the value option from " to ', such as

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

to

<input type="hidden" name="key" value='[r: array]'>

and the json gets properly parsed.

[aliasmask]

I think we can close this one then. Just chalk it up to an MT quirk.

[aliasmask]

Although, a note in the Wiki under form tutorial may be appropriate.

[aliasmask]

Found another issue related to the form submit: https://forums.rptools.net/viewtopic.php?f=53&t=26670&p=275588#p275580

If you have a form:

[H: link = macroLinkText("process@"+getMacroLocation(),'all')]

[dialog("Test"): {
   <form action="[r: link]" method="json">
      <input type="hidden" name="num" value=1 />
      <input type="submit" />
   </form>
}]

And process it

[r: macro.args]

You get: {"num":"1"}

You can see the value of 1 is returned as "1". I'm not really sure what could/should be done with this. If I put value="1" vs value=1 if there is something to distinguish it from a string vs a number. The issue only is an issue because of json updates retaining a string that looks like a number as a string (which is a good thing). Old macros like the DiceBox blow up due to this change.

[Phergus]

Looks like the workaround noted by @Merudo above no longer works either.

Tested with dialog5() in 1.6.0 alpha 7 with the same results.

[Merudo]

Yep, the workaround got broken in MapTool 1.5.12. Now the json passed is

{"key":"[{\"FirstKey\":\"A\",\"SecondKey\":\"B\"}]"}

[Phergus]

So looking at submitData() in HTMLPanelFormView and I see this:

} else if (dataStr.length > 2) {
	jobj.addProperty(dataStr[0], dataStr[1]);
}

I'm sure there is a reason for it but not sure what it is as the else block that follows would do the same thing if the URL.decoder failed.

So just out of curiosity I replaced it with this:

} else if (dataStr.length == 2) {
	if (StringUtils.isNumeric( dataStr[1])) {
	  jobj.addProperty(dataStr[0],new BigInteger(dataStr[1]));
	} else {
	  try {
		double d = Double.parseDouble(dataStr[1]);
		jobj.addProperty(dataStr[0],new BigDecimal(d));
	  } catch (NumberFormatException nfe) {
		jobj.addProperty(dataStr[0], dataStr[1]);
	  }
	}
}

And using this macro:

[H: link = macroLinkText("process@"+getMacroLocation(),'all')]
[dialog("Test"): {
   <form action='[r: link]' method="json">
      <input type="hidden" name="num1" value=123 />
      <input type="hidden" name="num2" value=3.1416 />
      <input type="hidden" name="num3" value=-9 />
      <input type="hidden" name="notanum" value=-12f3.2 />
      <input type="submit" />
   </form>
}]

I get this:

{
  "num1": 123,
  "num2": 3.1416,
  "num3": -9,
  "notanum": "-12f3.2"
}

So it looks like this is fixable if we just make the fallback in the NFE the contents of the last else block.

[Merudo]

PR #1351 solves the number appearing as a string, and restores the previous workaround.

[Phergus]

Figured there was a better way to do it. The PR works for my trivial example. I'll have to find some other examples with forms to test with.

@Merudo I assume the same kind of fix will need to be done for the HTML5 support?