Passing JSON parameters to FileMaker scripts?

[jean-Phil]

This is meant more as a discussion opener than a, issue...
What would the PROS and CONS of passing FileMaker scripts parameters in JSON format be?

PROS

• cleaner get(scriptParameter) output
• much cleaner way of passing matrices of arguments

---

CONS

• Is it a lot slower to work this way than to use simple key-value pairs ?
• Custom functions required for decoding
• dates are returned as text
• recursion depth limits

[dansmith65]

I'm not sure I agree with the pro of "cleaner get(scriptParameter) output". This project doesn't support pretty printing of the json, so it's all just one long string without whitespace. Personally, I'd say Let notation is a little easier to read than that. On the other hand, it's easy enough to use https://github.com/geistinteractive/JSONCustomFunctions with BaseElements on your development computer, which gives you access to a pretty print function, which I would say is easier to read than Let Notation.

I haven't done speed tests to confirm, but I'm fairly certain that these native json functions (and probably the BaseElements backed ones, too) are slower than Let Notation. That may depend on which version of Let Notation you're using, for example #Parameters detects the data type, which is convenient, but is slower than not doing so.

JSON dates and timestamps would need to be explicitly converted from a string to FileMaker's format; these functions don't do that for you. The reason for this is that JSON doesn't have a date, time, or timestamp data type, so they are stored as text in ISO format.

Creating JSON requires an extra level of nesting that Let Notation doesn't have, so compare a simple object, for example:

/* Let Notation */
# ( "name" ; "value" )

/* json */
jsonO (
    jsonOp ( "name" ; "value" )
)

Let notation can be created manually, if needed; JSON can't. Because of this, I use it in modules on modularfilemaker.org, where I don't want them to rely on any specific set of custom functions.

Can you edit your initial comment? If not, I can edit it to add to the pros and cons list; let me know if you'd like me to.

[jean-Phil]

Thanks, Daniel... good points!
I grant you the not necessarily cleaner get(ScriptParameter) output, but I disagree on JSON being more difficult to create manually.
Is

"key":"value",

so different than

name="value";¶

?

I find it is with nested parameters and vectors of arguments that carriage-return delimited or let notation parameters easily become convoluted, and your module offers a nice alternative... I"ll test it more, first, but I sure find the idea promising.

( And please update the list! as I hope others will, too. ;)

[dansmith65]

You're right; creating json manually isn't that much different than let notation... until there are characters that need to be escaped. To properly encode json in all scenarios, you would have to do everything in this function: https://github.com/dansmith65/FileMaker-JSON-Functions/blob/master/Functions/z_jsonEncodeSupport.fmfn

Although, I suppose what I really meant is that you can't easily manually decode json, whereas you can manually decode let notation with a simple expression:

Evaluate (
    "Let ( [¶"
    & Get ( ScriptParameter )
    & "! = \"\" ] ; \"\" )"
)

[jean-Phil]

...but now we have your functions to do just that! ;)

Could I add to the PROS the idea of having a parameters as data, ie. something that really stands on its own, that is understandable in any programming language?

[dansmith65]

I forgot to mention another con:

If the json being parsed is large, you may reach FileMaker's custom function recursion depth limits and the functions will return ?. With the cache system, you can run the same request again and the functions will pick up where they left off, so you can get around this recursion depth limit issue by calling the function in a loop and exiting the loop once a valid result, or an error is returned.

There are tests in the FileMaker-JSON-Functions.fmp12 file that demonstrate the recursion depth limit with different input json. There is no set size of the input json that will cause the functions to reach the recursion depth; it depends on the types of values in the json.