JSON encode problem

Using this code :-


As a standalone script I get :-

{"iTotalRecords":1,"aaData":[["Fred","10th","1","New"]]}

which is correct.

From a snippet in a Revo 2.2.4(linux) install I get :-

{"iTotalRecords":1,"aaData":}

which is wrong. Thinking its the server environment somehow I tried it in a Revo 2.2.0 install on a Windows box, output is as above, ie wrong. I've also tried this with the Zend Json class in the snippet rather than json_encode, still wrong.

What gives, has anyone else seen this behaviour. Note that using associated keys ie 'Name=>Fred' works in the snippet.

Its because Revo is parsing the brackets isn't it, that's why the first string above doesn't' show, it should read :-
{"iTotalRecords":1,"aaData":[ ["Fred","10th","1","New"] ]} with the brackets closed. I'm getting this back form a JSON content type page that I use for AJAX calls, the browser is seing this string :-

responseText: "{"iTotalRecords":1,"aaData":}"

which is wrong, why is this being parsed out on the way back to the browser?

JSON data poses a particularly nasty problem with the parser in MODX, as you are experiencing here. Is this something you are wanting to send back directly to the browser, or is this expected to be returned into another Element (e.g. a Template)? If the former, you may just be able to close the output buffers and exit at that point to prevent further parsing, especially if this is not cacheable.

Some kind of standard method of returning content like this that should not be parsed further is probably in order. Feedback or alternative thoughts on how to address this are certainly welcome...

Yes it needs to go straight back as is, ie not parsed at all. The strange thing is I've written many AJAX calls like this and and only hit this now, obviously I've never generated this particular data structure before, it stumped me initially.

I've changed the code to be associative so we now have 'Name'=>'Fred', this changes the JSON encoding, it no longer has '[[' so it works now(this is actually a better way than doing it as I was originally so in a somewhat perverse way its actually helped!).

I thought, wrongly as it appears, that setting the content type of the page to JSON would stop the parser and just return the data as is, can we not check the page content type before we parse? If its not text/html just return the raw data.

We could document the content types that do or do not get parsed.

I can definitely see a use for tags being parsed even when the content type is set to JSON.

You could do something like this to prevent the issue:

Note that the second set of brackets should be the html encoded version of the brackets... can't wait to upgrade the new forums and not have to worry about simple things like that [ed. note: markh last edited this post 13 years, 11 months ago.]

I tried opening the brackets in the JSON sttring but it didn't work for some reason.

I think we need to let the user decide this with a 'do not parse' flag associated with content type, or have a content type set up that is specifically not parsed so this can be used. MODX shouldn't assume that the return values from every page needs to be parsed, Server side AJAX processing for instance usually ends up like this :-


I doesn't make sense to parse this, also not parsing will of course be faster will it not, which is better for AJAX stuff.