"Strong-typing" JSON object property names - Forum - OpenEdge Development - Progress Community

"Strong-typing" JSON object property names


"Strong-typing" JSON object property names

  • 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


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

    ENUM PropertyNamesEnum:

    DEF ENUM ioMode. 


    and do something like


    - 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}]
  • 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.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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).