Subscribe for automatic updates: RSS icon RSS

Login icon Sign in for full access | Help icon Help
Advanced search

Pages: [1]
  Reply  |  Print  
Author Topic: JSON to FGL variable conversion  (Read 12018 times)
Tim B.
Posts: 67


« on: December 20, 2017, 01:24:40 pm »

We have a JSON structure similar to the following being returned from a web service:-

{
  "id": "96gOMKS2",
  "count": 10,
  "feasible": true,
  "route": {
    "0": {
      "name": "LOC 1",
      "arrival": 0,
      "distance": 0
    },
    "1": {
      "name": "LOC 2",
      "arrival": 2,
      "distance": 1.2
    },
    "2": {
      "name": "LOC 3",
      "arrival": 4,
      "distance": 2.3
    }
  }
}

How does this translate into an FGL variable?  When I try "CALL util.JSON.parse" I get "JSON parse error: Unexpected '{', target is not a RECORD or DICTIONARY".

The problem, I assume, is the "0", "1", "2", which I'm not sure how to handle or translate.

I've tried the following:-

       m_resp DYNAMIC ARRAY OF RECORD
           id       CHAR(8),
           count    SMALLINT,
           feasable BOOLEAN,
           route DYNAMIC ARRAY OF RECORD
               name VARCHAR(40),
               arrival  DECIMAL(6,1),
               distance DECIMAL(6,1)
           END RECORD
       END RECORD
and
       m_resp DYNAMIC ARRAY OF RECORD
           id       CHAR(8),
           count    SMALLINT,
           feasable BOOLEAN,
           route DYNAMIC ARRAY OF RECORD
               num INT,
               rec RECORD
                   name VARCHAR(40),
                   arrival  DECIMAL(6,1),
                   distance DECIMAL(6,1)
               END RECORD
           END RECORD
       END RECORD
and
       m_resp DYNAMIC ARRAY OF RECORD
           id       CHAR(8),
           count    SMALLINT,
           feasable BOOLEAN,
           route DICTIONARY OF RECORD
                   name VARCHAR(40),
                   arrival  DECIMAL(6,1),
                   distance DECIMAL(6,1)
           END RECORD
       END RECORD


I assume "route" is a DICTIONARY(?), but I'm not sure how to create variable to fit this structure.

Solutions or ideas gratefully received.

Tim
Rene S.
Four Js
Posts: 111


« Reply #1 on: December 20, 2017, 01:37:01 pm »

Try this:

Code
  1. m_resp RECORD
  2.          id       CHAR(8),
  3.          count    SMALLINT,
  4.          feasable BOOLEAN,
  5.          route DICTIONARY OF RECORD
  6.                  name VARCHAR(40),
  7.                  arrival  DECIMAL(6,1),
  8.                  distance DECIMAL(6,1)
  9.          END RECORD
  10.      END RECORD
  11.  

Rene
Sebastien F.
Four Js
Posts: 509


« Reply #2 on: December 20, 2017, 01:37:59 pm »

Try this:
Code
  1. IMPORT util
  2.  
  3. DEFINE rec  RECORD
  4.              id STRING,
  5.              count FLOAT,
  6.              feasible BOOLEAN,
  7.              route DICTIONARY OF RECORD
  8.                  name STRING,
  9.                  arrival FLOAT,
  10.                  distance FLOAT
  11.              END RECORD
  12.            END RECORD
  13.  
  14. MAIN
  15.    DEFINE js STRING
  16.    LET js = '{
  17.  "id": "96gOMKS2",
  18.  "count": 10,
  19.  "feasible": true,
  20.  "route": {
  21.    "0": { "name": "LOC 1", "arrival": 0, "distance": 0 },
  22.    "1": { "name": "LOC 2", "arrival": 2, "distance": 1.2 },
  23.    "2": { "name": "LOC 3", "arrival": 4, "distance": 2.3 }
  24.  }
  25. }'
  26.    CALL util.JSON.parse(js, rec)
  27.    DISPLAY util.JSON.format( util.JSON.stringify(rec) )
  28. END MAIN
Sebastien F.
Four Js
Posts: 509


« Reply #3 on: December 20, 2017, 01:43:46 pm »

Answers have crossed.
Sure using the original types CHAR, VARCHAR, INTEGER, DECIMAL(p,s) is certainly better for your application needs as STRING/FLOAT.
I have got STRING/FLOAT from util.JSON.proposeType()
Seb
Tim B.
Posts: 67


« Reply #4 on: December 20, 2017, 02:45:45 pm »

Thank you both.  I was close, but not quite there.  DICTIONARY is new to me as we're just upgrading to 3.10.

Incidentally, GST 3.00.32 is showing compile errors for the DICTIONARY keyword ("The symbol 'DICTIONARY' does not represent a valid variable type.") but does compile & run OK.  I assume this is because GST is using the original FGL 3.00.10 package it was bundled with, whereas I am actually using FGL 3.10.09 now.  Is there a way to make the inline compiler use the same version of FGL you have in the configuration?




Sebastien F.
Four Js
Posts: 509


« Reply #5 on: December 20, 2017, 03:16:59 pm »

Why don't you use GST 3.10?
Seb
Tim B.
Posts: 67


« Reply #6 on: December 20, 2017, 03:29:10 pm »

Not quite got round to updating it on this machine.  I should do really though.
Reuben B.
Four Js
Posts: 1046


« Reply #7 on: December 22, 2017, 12:29:12 am »

Quote
Incidentally, GST 3.00.32 is showing compile errors for the DICTIONARY keyword ("The symbol 'DICTIONARY' does not represent a valid variable type.") but does compile & run OK.  I assume this is because GST is using the original FGL 3.00.10 package it was bundled with, whereas I am actually using FGL 3.10.09 now.  Is there a way to make the inline compiler use the same version of FGL you have in the configuration?

... to give you some background,  for real time syntax checking, code completion etc, Studio does not use the same fglcomp as it does for the actual compilation.  If you do a search inside Studio files for fglcomp etc you will find the cut down versions that Studio uses for these code editing purposes.  You will hopefully see a few different versions of this file and can hopefully appreciate why the new 3.1 syntax is not recognised by the 3.0 version of Studio.  You will also face the same issue editing any .xml type files such as .4ad, .4st etc.  Any new tag names, attribute names and values introduced in 3.1 will not be included in the 3.0 definitions and hence will raise false errors in the 3.0 code editor.

With Studio, there should not be anything that holds you back upgrading relatively promptly after each release.  Whilst we can appreciate why sites are still running FGL/GAS/GDC.GRE 3.0, 2.5, 2.4 and worse etc in production, with GST there aren't those same excuses.  By not upgrading promptly, your developers are missing out on the new functionality introduced in Studio in 3.1 http://4js.com/online_documentation/fjs-gst-manual-html/#gst-topics/gst_whatsnew_310.html.  Ideally with GST you have participated and used it during the Early Access Program (EAP) and have the confidence to upgrade to it not long after its general release.

Reuben


Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Reuben B.
Four Js
Posts: 1046


« Reply #8 on: December 22, 2017, 12:59:00 am »

This is interesting, with regards the JSON structure, my first instinct upon reading was to use the util.JSON.proposeType method http://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_ext_util_JSON_proposeType.html this should propose a sensible solution.   However if I ran that I got the following proposed structure ...

Code
  1. RECORD
  2.    id STRING,
  3.    count FLOAT,
  4.    feasible BOOLEAN,
  5.    route RECORD
  6.        0 RECORD
  7.            name STRING,
  8.            arrival FLOAT,
  9.            distance FLOAT
  10.        END RECORD,
  11.        1 RECORD
  12.            name STRING,
  13.            arrival FLOAT,
  14.            distance FLOAT
  15.        END RECORD,
  16.        2 RECORD
  17.            name STRING,
  18.            arrival FLOAT,
  19.            distance FLOAT
  20.        END RECORD
  21.    END RECORD
  22. END RECORD

... which is not a valid Genero definition, and is not as appropriate as Rene and Seb's suggestion using DICTIONARY.

So question should perhaps be asked, why proposeType did not propose a solution that could be used.  There are two new features introduced in Genero 3.10 that this method was not incorporating.

1. The record names, 0,1,2 are not valid Genero identifiers.  In 3.10 we introduced the json_name to help with the mapping of JSON identifiers to Genero identifiers http://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_json_utils_names.html.  Should proposeType have suggested their use?  This is a slight modification on what proposeType proposed, is syntactically valid and "works" with a sample size of 1, but it would most likely not handle real data ...

Code
  1. DEFINE x RECORD
  2.    id STRING,
  3.    count FLOAT,
  4.    feasible BOOLEAN,
  5.    route RECORD
  6.        r0 RECORD ATTRIBUTES (json_name="0")
  7.            name STRING,
  8.            arrival FLOAT,
  9.            distance FLOAT
  10.        END RECORD,
  11.        r1 RECORD ATTRIBUTES (json_name="1")
  12.            name STRING,
  13.            arrival FLOAT,
  14.            distance FLOAT
  15.        END RECORD,
  16.        r2 RECORD ATTRIBUTES(json_name="2")
  17.            name STRING,
  18.            arrival FLOAT,
  19.            distance FLOAT
  20.        END RECORD
  21.    END RECORD
  22. END RECORD

2.  Should proposeType have proposed to use the new DICTIONARY syntax http://4js.com/online_documentation/fjs-fgl-manual-html/#c_fgl_Dictionary_syntax.html that Rene and Seb have suggested in their solutions?  Is it possible for us to simply detect a JSON pattern that matches DICTIONARY and have proposeType suggest it? instead of proposing multiple consecutive records with an identical structure?

Reuben

Product Consultant (Asia Pacific)
Developer Relations Manager (Worldwide)
Author of https://4js.com/ask-reuben
Contributor to https://github.com/FourjsGenero
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines