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.

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.

http://www.smashingmagazine.com/2007/04/20/35-designers-x-5-questions/

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

I decided to look for some kind of algorithm that would allow for matching words that are similar. This would inevitably be to retrieve records from a database based on some search criteria. So I search google and find something about a Soundex algorithm. The algorithm goes as follows (copied straight from Wikipedia):

1. Retain the first letter of the string
2. Remove all occurrences of the following letters, unless it is the first letter: a, e, h, i, o, u, w, y
3. Assign numbers to the remaining letters (after the first) as follows:
   • b, f, p, v = 1
   • c, g, j, k, q, s, x, z = 2
   • d, t = 3
   • l = 4
   • m, n = 5
   • r = 6
4. If two or more letters with the same number were adjacent in the original name (before step 1), or adjacent except for any intervening h and w (American census only), then omit all but the first.
5. Return the first four characters, right-padding with zeroes if there are fewer than four.

But that’s not the good part… The good part is that this algorithm is implemented in some DBMS systems. And apparently, you guessed it, it’s implemented in the most popular ones, SQL Server, Oracle, and MySQL. How does it work? It’s oh so difficult… Check out the code below:

SELECT *
FROM address
WHERE SOUNDEX(city) = SOUNDEX('Washgton')

If you have any records in the database for Washington (note in the query it’s missing the “i”) it will be returned. Wonderful! I could probably have used this before. And for those who have the possibility of adding UDFs to their DB server, there are implementations of other algorithms such as Metaphone and Similar_text.

Note that Soundex is a phonetic algorithm, so it looks for words that would sound similar. So you might not always get the results you want. When I searched my person table using SOUNDEX(first_name) = SOUNDEX(’Tomas’) I did get a bunch of “Thomas” records back, but if I use SOUNDEX(’Thomas’) I did not, I got a bunch of “Tom”, “Tommy”, and even “Tony” records, but no “Thomas”. Oh well, still better than nothing. I bet that using a combination of different algorithms you can probably get some good results. More research to be done…

Besides the tags, you can set output=”no” on both your <cfcomponent> and <cffunction> tags, and it’s often necessary to do so. Finally, there’s an option in the Settings section of the CF Administrator that you can use to let CF manage whitespace suppression.

So I had a whitespace problem the other day and I was trying to get rid of it by all means necessary. I have all these options right? Something’s gonna work, right? Wrong! None of these things did it for me. I had a function in a component that you pass some arguments to and it outputs a <select> field populated with <option> tags. So I was calling the function something like this

<cfsetting enablecfoutputonly="yes" />

<cfoutput>Label: #selectBox(options)#</cfoutput>

<cfsetting enablecfoutputonly="no" />

This was part of a larger framework, but everything was wrapped in a <cfsetting enablecfoutputonly=”Yes”> and all components and functions had output=”no” where possible. I was really starting to get pissed when I had one of my Einstein moments. I took the code out of the <cfoutput> and changed it to the following and all was well:

<cfsetting enablecfoutputonly="yes" />

<cfoutput>Label: </cfoutput><cfset selectBox(options) />

<cfsetting enablecfoutputonly="no" />

Presto! Like magic it worked. I’m glad I found a workaround, but I still think it’s pathetic that CF can’t handle this for me.

After implementing Larry’s changes I so happened to read a post on Ben Nadel’s blog about a problem with a JSON string that had a carriage return. This incited me to go and check if special characters were properly handled, and I discovered that while they were as far as encoding, the decoding was not correct. In the process of fixing this I discovered a serious bug that caused errors when there was one double-quote in a string within a complex data type. I tracked it down to an inexplicable problem with a loop, whereby I incremented the loop’s index value to essentially skip an iteration, but for whatever reason on the next iteration the value of the index was reset to the original value it would have had if I hadn’t incremented it. Mystery… I just changed the loop to a conditional loop where I incremented values myself and that solved my problem.

So given the bugs mentioned above, this version of CFJSON is a must download. Hopefully there won’t be too many serious problems from now on, the transition from one owner to the next and implementation of accumulated code/bug fixes/features made it so some unpleasant stuff crept in, but it’s looking under control now. Thanks again to all the contributors!

DOWNLOAD CFJSON v1.7
GO TO THE CFJSON SITE

Both Mach-II and Model-Glue don’t really turn me on, at least not at first glance. Maybe I have to let them grow on me. Right from the beginning, at the very core of them, there’s XML. I can’t stand XML, I just can’t help it. In both Mach-II and Model-Glue, there’s a considerable amount of stuff that gets set up in XML files, they’re a fundamental part of the frameworks, unfortunately for me. Essentially, you define events that broadcast messages heard by listeners that provoke some action to be taken, and possibly generating output to the screen. In essence, I like the principle, I guess I may just not like the implemementation.

So that I don’t come accross as a total framework hater, I have to say that I’m quite a fan of Ruby on Rails. I think the way they go about it is more intuitive to me, I think their approach of using a lot of naming conventions helps minimize the amount of configuration needed. Just follow the conventions and things get magically connected and meshed in the background. I like that. On the ColdFusion end of things, from my (very) limited experience with it, I’d say that I also like Reactor as a framework, although we’re talking about totally different kind of framework here.

Bottomline, I think I may have to come up with a real project to get a better feel for the existing ColdFusion frameworks. In my case I’d go with Model-Glue:Unity, with Reactor plugged in. That way I get the benefit of testing 3 frameworks at once. And I could also take the opportunity to throw YUI and YUI-Ext into the mix to get my javascript groove on. I don’t know where I’ll find the time, but hopefully I can sneak in a few minutes here and there for the sake of knowledge.

Web Payment Standards accomodates a number of different scenarios, I’ll only describe mine. I wanted PayPal to handle only the payment part of the transaction, as I already had a shopping cart built. No problem, says PayPal’s documentation. Integrating basically consists in posting a form to a PayPal URL including a number of hidden fields. Among those hidden fields are required fields, like the account the payment is to be made to, the information for the items in the shopping cart, etc. You can also include some optional fields that allow you to customize the header of your payment page, background color, the URL the user will be returned to once they complete their payment, etc. It’s really that easy. Pass that information and PayPal will do the rest. While they collect a small percentage on transactions, I think the convenience of not having to look into merchant accounts as well as implement all the payment stuff is well worth it.

Now, for IPN. IPN is basically a good way for you to record the transaction on your end. Sure, you could just do that when PayPal returns the user to your page, but what if the user doesn’t go? I discovered that PayPal will NOT redirect the user to your page if they don’t have a PayPal account and just pay by credit card, which is a pretty common case. The user has to click on a button to return to your site. So you can’t rely on the user clicking on that button to record the transaction. Enter IPN. With IPN, PayPal makes an HTTP post to a page of your choosing. On that page, you can receive the HTTP post which has all the variables you’ll need to store the order in your database, email the customer, and whatever else you want to do. But before, there are some security mechanisms to verify the data. You will need to do an HTTP get request to PayPal’s server sending it back all the variables you received. You will then receive a status of INVALID or VERIFIED. Once your transaction is verified, there are a few more instructions that I won’t get into of things you can check before actually processing the order. So by using IPN, you make sure that your system records the transaction, independent of what the user does. If they paid, you’ll know about it, even if they wander off after they’re done paying.

Finally, it’s worth mentioning that you’ll be able to test this entire process on PayPal’s sandbox server. All you need to do is sign-up for a free account on the developer site. You will then be able to create accounts for testing purposes on the sandbox. The sandbox works exactly like the live PayPal site except financial transactions don’t actually go through. It even has a built in email reader so you can see the emails that would go out. Nifty.

I’m pretty happy with this system so far. The only disappointing thing is that the customization options for the look of the payment page are very limited. Also, I was disappointed about the auto return not working for non-PayPal account holders. But overall, I’m satisfied, and I can’t wait to have this live. Show me the money!