dansmith65 / filemaker-json-functions Goto Github PK

The scenario this is needed would be:

1. read a few values from json (which caches those values)
2. one of those values is json, so read that json (this would have cleared the temporary cache)
3. go back to the original json to read the next value (there would be no saved cache for this json now)

There is a temporary method in place for this, and a comment in the code, along with an idea for an alternative method.

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

Currently, the leave the $~json.at value pointed to the specified value, but I think it will be more flexible to just return that value.

This code would actually go in z_jsonParseSupport2 ParseObjectGetKeyList/ParseArrayGetKeyList.

It would be easy enough to do this from the object/array walking functions and it could make the jsonGet function much simpler.

jsonO (
    jsonOp ( "ts" ; Get ( CurrentTimestamp ) )
)
// = { "ts":9/24/2015 7:29:01 PM }

it should return:

{ "ts":"9/24/2015 7:29:01 PM" }

Originally reported here: dansmith65/FileMaker-JSON#9

I suspect the encodingSupport script could be improved in a few areas.

My JSON includes a U+2028 character that doesn't pass jsonValidate function, I get the following error message:

Error: control character 0xd

The hex character sequence is: e280a8

Is this correct?

Thanks for your contribution

The following two functions should return the same key:value pairs

Although this may not be addressed with the upcoming FM v16 incorporating CF's it should be documented as many people will keep these CF's in their systems.

jsonModify ( "{}"; "returnTest" ; "first¶Second" ) & ¶ & jsonOp ( "returnTest" ; "first¶Second" )

Current result:
{"returnTest":"first¶Second"} "returnTest":"first\rSecond",

Work around:
' jsonModify ( "{}"; "returnTest" ; Substitute ( "first¶Second"; "¶" ; "\r" ) ) `

The idea here is to get better performance when the plugin is available, yet don't require the plugin to parse json.

Have to use Evaluate when calling BaseElements plugin.

jsonO returned the following:

jsonO (
jsonOp ( "chip_number" ; "3.56E+14")
)
//{ "chip_number":3.56E+14 }

A user imported microchip numbers in from Excel to a text field. Some of the values Excel reformatted as exponential format. These ended up in the FMGo file.

jsonO assumed this was a number and doesn't add the quotes. The PostGreSQL server was expecting a varchar(45) but rejected this because of the E+ not being within quotations.

Are you able to catch for this or can you add another parameter for jsonO to force the output type. Which might also save time when testing if 'req is too long to be a number'.

I don't think I'll needs this until I implement jpath.

It shouldn't have to recurse to do it's job.

May also want to put the code right in the ParseString function since that's the only place it's called from.

• insert before other values
  • negative number?
  • "unshift" (like the json method) ?
• insert between values
  • decimal: 2.5 would insert after 2?
• insert at end
  • I assume this would be the most common use-case
  • empty keyOrIndex value?
  • this is how the function always operates at the time of creating this issue

Like I did for the parse support functions.

It would be useful if there were an equivalent function to #Assign() from the FMP Standards #Parameters module. I realize that it's possible to do something equivalent with a loop at the start of each script, but that seems like a lot of boilerplate steps.

Is this something you're considering? Or are you avoiding it in this module because dynamic variable naming requires using Evaluate() and Quote()?

I'd like to see if extra whitespace/comments impact performance on large recursive CF's.

This doesn't actually happen, though; it just returns an empty string.

An empty string is probably enough since a json null value will be returned as "json:null" (might want to confirm that's working as expected, though).

I've replaced the next function with in-line code, but I think that in-line code should check if there is an error before modifying at and ch.

To make sure the value returned when an error occurs is as expected.

It should either return an empty string, or an error (I'm not sure which, yet). It seems like it's trying to process it and reaching FM's recursion limits.

jsonGet ( $jsonArray ; -1 )

Should this return an error, or "not found"?

I think the ~valEndPos is 1 higher than it should be, but it may depend on how you look at it/what is the most useful. It seems to be pointing at the character after the end position at the moment.

replace current CREATED comment with: "v1.0.0 released on ____ date by me"

If the index is higher than array size + 1, should it pad the array with null values like javascript does?

Having a single space between elements is probably a common enough use case to account for in the code. If there is only a single whitespace character, then this enhancement would allow these functions to parse much more data before reaching the custom function recursion limit.