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.

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!

The ColdFusion Report Builder was a welcome addition to CF, allowing for report generation without using third-party software like Crystal Reports. The problem with it is that documentation and examples are sparse. And the CFREPORT site doesn’t seem to have a lot of activity lately (in all fairness, I did not contact the site owner, maybe he’d have a solution for me). Granted, it’s not really that complicated to pick up, but there are some cases that leave you scratching your head. I recently ran into one such case.

Basically, the report builder allows you to put some fields on your report and you can make them a certain size. But what if you have text of variable size and you’re not sure how long it’ll be? No problem, you can just set it to whatever width you want and then set the “Stretch With Overflow” field to true. That way when the text is too long to fit within the pre-defined width it’ll wrap to the next line. That’ll solve all your problems, right? Nope…

This solution will work if your report is a simple table, with a single row of fields put one next to the other. If you have a field that requires more space, the text will wrap and push down thenext record. But what if you have something like the following?

Suppose the Office field got long and you set its “Stretch With Overflow” property to true, guess what would happen? Yeah, the text would wrap alright, but it wouldn’t push the stuff below it down, instead it would overlap it, and that’s obviously not good. I searched around and didn’t really find an answer to my problem. So either I didn’t search enough and wasted my time with a hack when there’s a built-in solution, or else I’m very clever and came up with a brilliant hack. I hope the latter is true!

I figured the way to make things stretch properly would be to put things in different bands. But you can’t randomly insert bands. So to get an extra band, we need a hack. I did it using groups. Basically, whenever you add a group you get a new band for that group. So my idea was to add groups on a field that is unique. That way you get extra bands but they actually aren’t grouping anything. I just used the primary key of my records as the group by field. And to be able to get more bands, I modified my query and to something like this:

SELECT
	JournalID,
	JournalID AS StretchHack1,
	JournalID AS StretchHack2,
	...
FROM Journals

Then you go under “Report > Group Management” and use those fields for Groups. You can put in as many groups as you need bands and then break down your fields/labels into the different bands. Here’s the result for my example:

I set the “Stretch With Overflow” property to true for Office, Contacts, Categories, and text. Because they are all in separate bands, if their content is too long to fit on one line it’ll wrap to the next line and push down the content below. Neat huh?

I’m sure this is not a bulletproof solution and there are certain types of layouts where this might either not work or be a real pain in the ass to use. But I think it should come in handy in cases resembling the one I illustrated above.