"Strong-typing" JSON object property names

Posted by Peter Judge on 16-Aug-2017 09:29

When using JSON objects in ABL I can work with property names in a couple of ways

- jsonData:GetNames(output arrayOfNames) and loop through them one at a time.

- jsonData:Has("string name") and jsonData:Get*("string name").

Assuming I know the property I want , what good strategies do I have for reducing errors in the names?

- I can just use a string "ioMode" which I repeat through the code. Not great since it's very error prone to typos and case-sensitivity issues

- I can add a static private property (or variable or preprocessor)  which holds the name

DEF PRIVATE STATIC PROPERTY IO_MODE_PROP_NAME AS CHAR INIT 'ioMode' GET.

- It strikes me as I type this that I can use an enum too

ENUM PropertyNamesEnum:

DEF ENUM ioMode. 

END ENUM

and do something like

jsonData:Has(string(PropertyNamesEnum:ioMode))

- anything else that I'm missing? Any other approaches that you use?

JSON example

        "/Employee": {
          "GET": {
            "contentType": "application/json",
            "jsdo": {
              "entityName": "doh.EmployeeBE",
              "function": "readData",
              "operation": "read",
              "schema": "dsEmployee"
            },
            "entity": {
              "name": "doh.EmployeeBE",
              "function": "readData",
              "arg": [
                {
                  "ablName": "pcFilter",
                  "ioMode": "INPUT",
                  "ablType": "Character",
                  "msgElem": {"type": "QUERY", "name": "filter"}
                },
                {
                  "ablName": "dsEmployee",
                  "ablType": "dataset",
                  "ioMode": "OUTPUT",
                  "msgElem": [{"type": "BODY","name": null}]
                },

All Replies

Posted by Mike Fechner on 16-Aug-2017 12:37

Within the application, we preferably work with ABL classes, not JSON objects.

We still prefer the use of our own JSON Serializable classes (github.com/.../ListsAndEnumSamples) as this gives us a greater freedom to deal with the mapping (e.g. JSON String properties to ABL Enums). Another aspect is that we have implemented case-insensitivity for JSON property names in the serialization process. I don't want to relay on a JavaScript programmer to match the casing style of the ABL programmer.

So we typically deal with the JSON serialization/deserialization only on the Service Interface layer.

Posted by Peter Judge on 16-Aug-2017 13:00

I agree with using ABL classes in ABL (and not operating on the JSON directly). I should have noted that this is largely for the deserialization of the JSON data into more complex objects. Once they’re objects I don’t care about the source JSON.
 
My case here is for loading properties (service definitions if it matters).
 

This thread is closed