Site icon FileMakerHacks

Thinking About JSON, part 4

Kevin Frank

This article is part of a series. See also…
•  Thinking About JSON, part 1
•  Thinking About JSON, part 2
•  Thinking About JSON, part 3

Introduction

Welcome back to the fourth installment in this ongoing series. It’s hard to believe it’s been four years since the last segment, but in the meantime some exciting developments have occurred at the intersection of FileMaker and JSON, including…

…and today we’re going to look at a custom function that can leverage JSONGetElementType to help make it easier for you to generate JSON.

Update 14 June 2025: I have belatedly moved this material into its own, properly titled, article: JSON.GetValueType

Problematical Characters In Key Names

As you may know, the issue with dots is they typically serve as path delimiters in JSON structures, but sometimes we encounter (or need to produce) JSON with dots within key names. For example, this:

{
   "name.first" : "Albert",
   "name.last" : "Schweitzer"
}

As opposed to this:

{
   "name" : 
      {
         "first" : "Elvis",
         "last" : "Presley"
      }
}

You can find the official word from Claris on the subject here — https://help.claris.com/en/pro-help/content/json-functions.html.

In a nutshell, if you want to reference JSON objects with dots or other problematical characters in key names, rather than using standard notation, you need to escape the key names via “bracket notation” like so —

['key.name']

— in addition to the normal double quote wrapper that is always required for object names.

This holds true for both JSONSetElement and JSONGetElement, so let’s combine both the above examples into a single object, and push that object into a variable called $$jsonObject:

Now we can extract both first names by using JSONGetElement, first with standard notation, and then with bracket notation.

If bracket notation seems a bit complicated, don’t worry… once you’ve used it a few times it will make perfect sense. And if you happen to use it when you don’t need it, no harm done (assuming, of course, that you are bracketing a name and not a path)… for example, here with a $keyName that, hypothetically speaking, might or might not contain a dot, both of these statements produce identical JSON when $keyName does not contain a dot.

This next example is identical to the preceding, except now $keyName contains dots. Here we see the benefit of playing it safe and applying bracket notation to unknown or dynamically-generated key names.

And of course dots aren’t the only problematical characters. I don’t have a complete list, but common sense would suggest that brackets and/or braces are going to be a problem in an object name, since they normally play a “meta” role. Here, for reasons unknown, we have been tasked with creating a JSON object with key names that look like array addresses.

And sure enough, brackets in key names cause confusion if we go the standard notation route…

But with bracket notation we can achieve not only the impossible…

…but the ridiculous as well.

Exit mobile version