parsing error in jFiles (human readable form)

[AtoB]

Hi Bruce,

I - think - I've spotted a tricky error in the parsing of the json.

Whenever a literal (null, true, false) or numeric gets processed as the last element of an array IN HUMAN READABLE form there is a linebreak (<13,10>) right after this value (before the close "}" of the record structure is processed added to these literals or numbers.

Below I've pasted an example that shows this misbehaviour. the array "orderLines" contains three elements and all "ending" fields ("qAcceleratedType", "label1", "label1") have values that are directly followed by a linebreak. When you modify the "HandleChar" method of the JSONCLASS to include the trace like below you see what's going on quite easily:

JSONClass.HandleChar              PROCEDURE(STRING pChar)
  CODE
  if SELF.Stack.StringStarted OR SELF.Stack.NumericStarted OR SELF.Stack.BooleanStarted OR SELF.Stack.NullStarted
    IF not SELF.Stack.Buffer &= NULL
      SELF.Stack.Buffer.Append(pChar)
      self.trace('pChar : ' & pChar & ' val(pChar) : ' & val(pChar))
    end
  end

I think the solution is maybe to add the following to the loadstring method to only add linebreak when within string values:

    of '<10>' orof '<13>'
      if SELF.Stack.StringStarted
        SELF.HandleChar(pToParse[c])
      end!if


This is the json

{
   "orders_response": {
      "apiVersion": "1.0",
      "orderLines": [
         {
            "fkSetLineId": 12056305,
            "qAcceleratedType": 30
         }
         {
            "fkSetLineId": 12056307,
            "qAcceleratedType": 30,
            "label1": true
         }
         {
            "fkSetLineId": 12056307,
            "qAcceleratedType": 30,
            "label1": null
         }
      ]
   }
}

[AtoB]

Hi Bruce,

I now see there there were two releases of jFiles that I didn't know of (I was on 1.22) :-)

1.24 you did change something that sounds like my problem, but it's not exactly the same I guess as It seems like it doesn't solve my scenario ...

1.23 you apparently now replace null values for empty strings and 0 for numeric fields (I can't find the change in the code though, but it's getting late here ...), but would you maybe, please consider making this an option for strings (the "null" is valuable to me ...). But maybe this is not necessary if you provide the "ClearMode" option (see my other post) and maybe simply not assign the null values to string (and thus leaving it to <255,255 ....> so I can test for it ...)

Regards,
Ton

[Bruce]

Hi Ton,

I've fixed the bug in build 1.25 - thanks for the report.
I've also added "default values" so you can specify default values for omitted and/or null fields.
See http://www.capesoft.com/docs/jfiles/jfiles.htm#OmittedAndNull in the docs for an explanation.

Let me know if this solves your problem, or if it's inadequate in some way.

cheers
Bruce

[AtoB]

Hi Bruce,

(didn't have time to test this earlier ...)

first results are really positive. I now can control null/omitted as I like (I internally only use strings now for importing queues and set these to <255,255,255,255,255> as omitted/null values, works as a charm)

Also did a simple test with the last "record" elements where the <13,10> were append to the data and I think that bug is completely gone too!

Thanks a million, great support!

regards,
Ton