nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Request to update JSON library in Content Server

Chris Meyer

I'd like to make a friendly request to OT development to update the JSON library in support/core/ajax_dhtml_util.js. I normally write JavaScript independent of Content Server JavaScript, but sometimes a global is shared among libraries and problems occur.

The JSON code in ajax_dhtml_util.js is open source. Specifically, it's a 2005 version from this repository: https://github.com/douglascrockford/JSON-js. There are two reasons I suggest the upgrade:

The old version clobbers any native support for JSON, which has become standard in modern browsers and is supposedly faster.
The old version doesn't respect the toJSON() function when it's defined on objects being stringified (see here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#toJSON_behavior). This breaks any library that depends on it.

The latest version of json2.js fixes these problems and should be backwards compatible. I hope this update will be considered.

Find more posts tagged with

Comments

Ferdinand Prantl

Until it is considered, you can use a workaround to retrieve the really native JSON object.

Chris Meyer

Hi Ferdinand, that's an interesting workaround to the problem by using an iFrame. The problem is that not all browser versions have a native implementation of window.JSON (I think IE only started supporting it in IE8). I formed a workaround like this:

// reset window.JSON to an empty object<script>window.JSON = {};</script>// such that loading the latest version of json2.js is possible<script src="{{ img }}mymodule/json2.js"></script>

This unfortunately doesn't restore window.JSON to the native implementation (maybe I can mix a solution with the iFrame approach), but at least provides a modern implementation of JSON.stringify that respects the toJSON function on objects. Thanks for your thoughts on this.

Ferdinand Prantl

Chris, actually, looking at your workaround, I like it better :-) basically, you need a working JSON object, which doesn't need to be the native one. By overwriting the current one you don't break anything, which depends on the standard implementation. And it is simpler than other workarounds. The native JSON may have better performance, but typical applicatoins do not parse so big strings to see a difference.

If it were possible to include 2 files by Appearances - one before and one after commonjs.html, you could load json2.js and remember the JSON object in other global variable and use that variable to restore the JSON object after the commonjs.html "destroys" it. But I'm not sure if such fine HTML fragment loading is possible. It would be more complicated as you current workaround anyway.

David Templeton

Chris

I agree with the need for the update. There has to be, as always, caution to such an update and it needs to be rolled out in a way to allow solutions to adsorb the change. While the suggested workaround may work in limited cases it may end up breaking other solutions in weird ways due to expected current usage patterns to be in place. Unfortunately, those would land up in

There appears to be differences in the json, json2 and native responses according to some on stack-overflow ( this needs to be verified of course )

<![if !supportLists]>· <![endif]>http://stackoverflow.com/questions/12866225/access-native-json-object-when-json2-has-overloaded-it

<![if !supportLists]>· <![endif]>http://stackoverflow.com/questions/552135/difference-between-json-js-and-json2-js

The approach we would need to take is the following I see:

<![if !supportLists]>1. <![endif]>Align the change based on the next major release.

<![if !supportLists]>2. <![endif]>Remove all local implementations of JSON handling JavaScript

<![if !supportLists]>3. <![endif]>Rely on the native handlers given, as you stated the browser support is present:http://caniuse.com/#feat=json

<![if !supportLists]>4. <![endif]>Thus allowing solutions to adjust accordingly.

Have an internal issue for investigation, CSARC-766.

Regards

David

Chris Meyer

Hi David,

Your concern echos why I'm reluctant to override the global JSON object with this newer version. I keep my JS code isolated from core (e.g., load my own instance of jQuery, etc.), but sometimes depend on a global like window.JSON. However unlikely it is in this case, I worry that changing it might break something.

I also looked at the differences between json.js and json2.js. From the README:

json.js: This file does everything that json2.js does. It also adds a toJSONString method and a parseJSON method to Object.prototype. Use of this file is not recommended.

The old version of json.js embedded in ajax_dhtml_util.js doesn't add a method to Object.prototype, so json2.js is probably the correct choice. I'll be testing it over the next few days and will let you know if I find any problems.

The approach we would need to take is the following I see:
Align the change based on the next major release.

Remove all local implementations of JSON handling JavaScript

Rely on the native handlers given, as you stated the browser support is present: http://caniuse.com/#feat=json

Thus allowing solutions to adjust accordingly.

A nice thing about later versions of json2.js is that it only applies itself to window.JSON if the browser doesn't natively support it. In other words, older browsers gain the functionality while newer browsers continue to use the native implementation. For this reason you might consider leaving it in to support older browsers.

Thanks
Chris

Ferdinand Prantl

Crockford's JSON and JSON2 have some differences and there's always a risk of breaking code. The JSON object interface has become a part of the ECMAScrip 5.1 standard. Newly written code is more likely to expect JSON2 behaviour otherwise it will be broken by the old one. In the end, something can get broken either way and you'd have to test our application to find out.

If you want a safe solution, you can modify the json2.js to provide JSON.noConflict() funtionality like jQuery or UnderscoreJS, using JSON2 variable, for example:

  <script src=".../json2.js">  <script src=".../rest of your app.js">  <script>    JSON.noConflict();    // JSON is back to the previous one (or null), JSON2    // still contains the new object for future usage  </script>

If you hook your JavaScript to multiple places, you would need some helper method to switch between the library versions, but you already have your own jQuery, so you should be ready for it.

CS UI Widgets use RequireJS and modified jQuery, JSON2 and other libraries to have total encapsulation and avoid collisions, at least in the JavaScript context.

Ferdinand Prantl

If you wanted to fix a broken JSON object implementation, not only to provide yours if none is available, you could detect if the browser really supports the JSON or if the existing JSON is a (possibly broken) polyfill. You could use the iframe trick for the detection, or a simpler, but arguably more fragile method:

  // Usage: isNative(JSON && JSON.stringify);  function isNative(method) {    // The behaviour of the toString is not specified for native methods.    // The trick below works in Chrome, IE8-11 and Firefox.    return method && method.toString().indexOf('[native code]') > 0;  }

Chris Meyer

Hi Ferdinand,

Excellent idea. I'm using this with a 3rd party module (knockoutjs if you're interested), which fortunately assigns an internal local variable to JSON (e.g., var JSON=window["JSON"]) when loaded. This means I can do the following...

<script>    // hold a reference to the existing JSON implementation    window.___JSON = window.JSON;    // reset window.JSON to an empty object    window.JSON = {};</script>// load the latest json2.js, which modifies window.JSON<script src="{{ img }}mymodule/json2.js"></script>// load knockout, which assigns the internal JSON to window.JSON<script src="{{ img }}mymodule/knockout-3.2.0.js"></script><script>    // return window.JSON to the original value    window.JSON = window.___JSON;     // cleanup    delete window.___JSON;</script>

I think that's the solution for now. Thanks!

David Templeton

Chris

For this reason you might consider leaving it in there to support older browsers.

According to the can I use link, all the browsers we support for 10.5 now are covered with native support. Any changes we would make to the product would be forward moving anyways ie: would not go back and update CS10

David