Archive for the 'CFJSON' Category
CFJSON 1.9, about time
Wednesday, February 20th, 2008

It’s been way too long I’ve owed an update of CFJSON. There were a few nagging bugs that needed to be addressed and I did my best to fix them. Another notable improvement was related to performance. Ray Camden pointed out that string concatenation wasn’t using the Java StringBuffer object. Doug Boude provided me with some code and I plugged it in, so encoding should be considerably faster when dealing with a lot of data.

Apologies to those who submitted other fixes/suggestions that are not addressed by this release. Either I found problems with the submission or including it would have further delayed a long-overdue release, so I figured I’d keep it for the next one. Either way, thanks for all the comments and code contributed.

For more details on the changes and to download the latest version, go to the CFJSON site.

CFJSON 1.8 is out
Saturday, May 12th, 2007

It’s been a while I’ve updated CFJSON, I just finished looking over some suggestions I’d received by email and took a little time to implement and test them. One fix could be considered critical depending on your needs. Ray Camden pointed out that Yahoo’s JSON feeds escaped the forward-slash character, so a url was coming up as http:\/\/someURL.com . This was not being decoded correctly by CFJSON, which I fixed for this release. For consistency, I also modified the encode function to escape the forward-slash.

The next two changes are some optional features that might make your life easier. The first was a suggestion by Carl Anderson for the handling of numeric fields. He was having problems because he had some project codes like “5.10000″ which javascript would convert to 5.1. He recommended that numbers be converted to strings by default in JSON. Because So he added a stringNumbers argument to the encode() function, when set to true it will encode numbers as strings. Because I don’t like to tamper with data unless necessary, I preferred to set the default to false.

Next up was the handling of dates. Thomas Jaworski pointed out that dates in an ODBC format like {ts ’2007-04-15 16:03:25′} would be troublesome to parse, so he provided some code for the encode() function to format dates in a way that was friendly to javascript’s new Date() constructor. Again, because I don’t like to tamper with data I preferred to implement this as an option that is false by default. The encode() function takes an optional formatDates boolean argument which will format dates as follows: May 12, 2007 3:00:45 PM .

Hopefully these features will come in handy. As always, your feedback is welcome, keep the requests/suggestions coming!

JSON schemas/validation with CFJSON
Sunday, March 25th, 2007

I’ve made it no secret that I’m not a fan of XML. However, one of the advantages of XML that is constantly brought up is the ability to validate XML documentes using an XML Schema or DTD. I haven’t had much use for them myself, but seeing as many people consider this important, I figured there was no reason the same couldn’t be done in JSON. So I came up with a format for a JSON schema file (written in JSON, of course) and added a function to the CFJSON library to validate a JSON document based on a schema.

While I don’t have docs written for this, it’s pretty self-explanatory. Here’s an example of a schema that shows pretty much all the features I’ve put in it so far:

{
   type: "struct",
   keys: ["title","body","categories","start_date","active"],
   items: {
      title: {
         type: "string", maxlength: 20, minlength: 8
      },
      body: {
         type: "string", minlength: 1
      },
      categories: {
         type: "array",
         minlength: 1,
         maxlength: 4,
         items: {
            type: "struct",
            items: {
               id: {
                  type: "number", min:6, max:10
               },
               name: {
                  type: "string"
               }
            }
         }
      },
      start_date: {
         type: "date", mask: "mm-dd-yyyy"
      },
      active: {
         type: "boolean"
      }
   }
}

In a nutshell, your schema is always an object/struct and it must always have a “type” key set. Then you go on nesting more definitions under the “items” key if you have more complex data types like structs or arrays. The valid types right now are “struct”, “array”, “date”, “number”, “boolean”, and “string”. Each of these data types have some additional options, which are explained below.

struct
For a type “struct, you have two additional keys you can add. The first is “keys”, in which you can provide an array of the keys that this structure MUST have. The second is “items”, which is a structure with keys for each structure key you want to add validation rules for. The “keys” and “items” values are both optional. You can specify an array of keys without providing “items” and vice-versa.

array
An “array” type can take 3 additional parameters, “minlength”, “maxlength”, and “items”. The first two are pretty self-explanatory, they check for a certain array length. The last is similar to the “struct” type’s “items” key, except inside that structure you do not list validation individually for keys since arrays are just numeric. So you simply put in the structure you want for all the items in the array.

date
The only option for the “date” struck type is “mask”. In it you can specify a date mask that you want the date to conform to. The possible masks are the same as the ones used by ColdFusion’s DateFormat function, although this could change because JSON is a universal format not restricted to CF.

number
A “number” type provides additional options of “min” and “max”, which allows you to specify minimum and maximum values for a number. Note that right now the “number” type allows for floats too, this will eventually be updated to allow for validating for integers, floats, unsigned numbers, etc.

boolean
The boolean type has no additonal options, although eventually it’ll probably allow for choosing what can be considered a valid boolean.

string
The “string” type can specify a “maxlength” and “minlength” option that will make sure the string is not longer or shorter than the values specified. Note that the “string” type will actually accept booleans and numbers. Right now I’m not seeing a way around it given the way I implemented things, and I’m not sure it’s really a big deal.

After defining the JSON schema standard I added a validate() function to CFJSON that validates a JSON document based on a schema conforming to the format described above. I also made a small example, creating a JSON document that conforms to the schema above and running the validate function against it. There’s a link to download the example below, all you have to do is change some values in the document or in the schema to see the validation working. There are a few more options that are probably easy to figure out looking at the code, such as the “errorVar” and “stopOnError” arguments. If anybody has any feedback on this I’d love to hear it.

DOWNLOAD CFJSON DOCUMENT VALIDATION EXAMPLE (includes the latest CFJSON)
FIND OUT MORE ABOUT CFJSON