Any issues switching from WDDX to JSON?

[Mike Chabot]

JSON is much more compact than WDDX, and both technologies solve roughly the same goal. WDDX seems to be fading away with the increasing popularity of JSON.

What issues have people run into when switching from WDDX to JSON, or using JSON in general? I am interested in problems that would impact the storing application data structures in a database, which is what I mainly use WDDX for. Thank you.

[Dave Watts]

As far as database storage goes, you shouldn't run into any issues. However, you can't parse JSON as easily as WDDX in generic (non-JS) environments, so that might trip you up. But if you don't really have that requirement, you should just go ahead and use JSON.

Dave Watts, CTO, Fig Leaf Software

http://www.figleaf.com/

http://training.figleaf.com/

Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on

GSA Schedule, and provides the highest caliber vendor-authorized

instruction at our training centers, online, or onsite.

Read this before you post:

http://forums.adobe.com/thread/607238

[Mike Chabot]

The only issue I saw in my testing was that all number-like variables were converted to numbers, such as zip codes. Leading zeros are removed, which is an undesired behavior. The serializer that comes with ColdFusion does not seem to have many configuration settings to tweak. Treating all simple variable types as strings seems like an acceptable behavior when it comes to storing data in a database for later reuse by the application. Some of the open-source JSON converters might allow for this.

JSON takes up less space in the database and it is likely faster to serialize and deserialize. Switching from WDDX to JSON seems like a decent switch to make if I can turn off the potentially risky automatic conversion to JavaScript variable types. Maybe it is better to create my own serializer optimized for putting variable structures in a database column.

[BKBK · Accepted solution]

ColdFusion 8 has an annoying bug, where a method returns a JSON object. ColdFusion imposes the following conversion on parameter values:

leading 0 removed: 01234 becomes 1234

int converted to float: 567 becomes 567.0

forced scientific notation: 12345678 is converted to 1.2345678e7

the string 'yes' becomes True

the string 'No' becomes False

This issue has apparently been resolved in ColdFusion 9, but it causes havoc in ColdFusion 8. In fact, I don't think there even a fix for it yet.

[Mike Chabot]

Thanks for the list of data conversion issues with the built-in functions. Perhaps I should explore using an open-source serializer so I can guarantee the behavior that I am looking for. It would help if these subtle details were documented in the Adobe reference guide. They are somewhat important.

I just read this post on Ray Camden's blog:

http://www.coldfusionjedi.com/index.cfm/2010/11/3/Best-JSON-option-for-folks-not-running-ColdFusion-9

The JSON serialization behavior is potentially different in CF8, CF9, CF901 and CF901 with a hotfix. Using an open-source solution is looking more attractive.

[BKBK]

Mike Chabot wrote:

The JSON serialization behavior is potentially different in CF8, CF9, CF901 and CF901 with a hotfix. Using an open-source solution is looking more attractive.

Indeed. I have given JSONUtil a go on ColdFusion 8. It does the job.