The built in CF debugging information displayed at the bottom of every page is very useful. But there are times where it doesn’t work very well. For example, any time you are using a framework, or where you are passing content around to CFC methods. Any data passed to a CFC method will be shown in the standard debugging information. This can cause havoc if the content contains some JavaScript. I use the datatables jQuery plugin on my site, so I have some JavaScript calls that turn a regular HTML table into a “datatable”. But when debugging info is on, this JavaScript code can get run several times, since the browser doesn’t know to ignore the JavaScript listed in the debugging information. This causes problems.

So I have an interest in getting rid of some of the info, but I do want some of it, mainly the queries. Its actually very easy to customize the ColdFusion debugging information. In the ColdFusion administrator, under the Debugging Output Settings menu there is a drop down to select the debugging format.

CF Debugging drop down

The files listed here are the contents of the C:\ColdFusion9\wwwroot\WEB-INF\debug directory. To create a custom debugging output all you need to do is drop a new file in this directory. Start with an existing one and customize it to your needs.

Here is one I’ve created that only shows database queries: Download queriesOnly.cfm

Did you know there is an IsDebugMode() function in ColdFusion? I just discovered this. This will be great for showing additional data when you are debugging your app. For example, you could leave this code in your order view page all the time:

<cfif IsDebugMode()>
    By the way here is the complete order:
    <cfdump var="#orderBean.toStruct()#">
</cfif>

IsDebugMode() will return true whenever you have debugging enabled in the Administrator and you are coming from one of the allowed debugging IP addresses. This works in Railo and OpenBD, too.

There is an interesting change in the CF9.0.1 updater that will make CF sites more secure. The CFID and CFToken cookies will now be marked as httpOnly. What this means is your browser will not allow JavaScript to access the CFID and CFToken cookies. I think this will greatly help to reduce XSS hacks on CF sites.

If you are using jSessionID instead of CFID/CFToken, you need to take an additional step. jSessionID is a session cookie, session cookies aren’t httpOnly by default. But if you add a “-Dcoldfusion.sessioncookie.httponly=true” argument in your jvm.config file, all your session cookies will be httpOnly, including jSessionID.

It would be nice if there was an option to the CFCOOKIE tag to mark a cookie as httpOnly or not. Lacking that, you could always send the cookies yourself using cfheader or java.

Here is a little ‘Apply To All’ feature I added to a large form we had. There were many rows of data, each with several columns the user needs to fill out. Most of the time the values they were entering in the top row ended up being what they would set all the subsequent rows to. So I wanted to add an easy way they could set all the later rows to the value of the first.

This was actually very easy to do with jQuery. I added a class to each form element, and links on the first row, so my code ended up looking something like this:
Continue reading ‘Making an ‘Apply to all’ with jQuery’ »

We have a new ColdFusion book! The CF community has not been blessed with an abundency of printed materials, so I was excited when I heard this book was coming out. Adobe ColdFusion Anthology is a compilation of Fusion Authority Quarterly Update articles. FAQU is a great publication that has contributions from many smart ColdFusion developers.

This book is 476 and covers a lot of interesting things. I’ve been using CFCs for years but I learned some new things in Michael Dinowitz’s chapters on Components. There are articles on all the major frameworks, there is even one on the new FW/1 framework.

Pete Freitag has a good article on image processing that also covers creating your own captchas. Did you know ColdFusion can read EXIF data?!

I also found John Mason’s article on BlazeDS interesting since I’ve never used BlazeDS before. I’ve always been confused about the differences between BlazeDS and LiveCycle Data Services, and this article helped clear some of that up.

This isn’t a beginner book, I’ll bet every CF developer out there could learn a few things from this book. Also they’ve done a nice job with the editing, everything is clearly explained.

Adobe ColdFusion Anthology
http://www.amazon.com/dp/1430272155/

If you’ve ever had the need to convert a query column to an array, there are a couple ways to do it. There is a queryColumnToArray function on cflib, or you could roll your own, but you can also do it with the built in ValueList and ListToArray functions.

Given the query “myQuery”, and a column called “name”, you can turn that into an array with this:

<cfset myArray = ListToArray(ValueList(myQuery.name)) />

The only problem with this is if the name column were to ever contain a comma, that value will get split into separate values, probably causing problems later on in your code. I ran into this issue with some old code the other day. The quick solution was to use a different delimiter than the default, which is a comma. You can pick a bizarre ascii character that you are unlikely to encounter in your data. I usually use one of the unprintable characters like 31, a “unit separator”, which sounds like a good one, doesn’t it?

<cfset myArray = ListToArray(ValueList(myQuery.name, Chr(31) ), Chr(31) ) />

In our application we create some large queries using QueryNew(). Before we started specifying the datatypes we would run into strange bugs occasionally. When you don’t specify the data type ColdFusion makes a guess. So if we had some code like this:

<cfset myQuery = queryNew('name,age,address,code')></cfset>

Then populate that query with data from another system (in our case, its often SAP) everything usually works fine. But ColdFusion is guessing the datatype based on the first 50 records, which can sometimes cause problems.

If for example, the first 50 records contain a ‘code’ value that is all integers, ColdFusion will give that column a datatype of integer. Then if the 51st record contains a varchar value, ColdFusion will blow up.

The solution is to declare the data types when creating the query, like this:

<cfset myQuery = queryNew('name,age,address,code' , 'varchar,integer,varchar,varchar')></cfset>

This can get a little harder to manage when the query has many columns in it. We have some with over 40 columns and it’s hard to keep track of which datatype is for which field.

I wrote this little helper function to make it easier:
Continue reading ‘Little UDF for creating typed queries: TypedQueryNew()’ »

The CFWindow tag can be useful to prompt for information on a form. We use this sometimes after a user has clicked the submit button. We do some client side validation in JavaScript, and if certain conditions are met, we use CFWindow to prompt for some additional information.

Its a little tricky though. If you try to use a CFWindow tag inside a CFForm tag you will get a ColdFusion error. If you use it inside a regular form tag you won’t get an error, but it won’t work like you expect. Lets take this code for example:
Continue reading ‘Using CFWindow within a form’ »

Capitalizing the first letter of each word – a common need for sure. There is a function for this on cflib but it didn’t work for me. No errors but it wasn’t returning what I expected. I came across this function that works, and does so with much less code:

<cffunction name="CapFirst" access="public" output="false" returntype="String">
        <cfargument name="inputString" required="false" type="String" default="" />
        <cfreturn rereplace(lcase(arguments.inputString), "(\b\w)", "\u\1", "all") />
</cffunction>

I found this snippet on the WeCodeThings blog. Good stuff.

One of the problems I looked into this week was why some items on our site that used to be in bold were no longer displaying as such. Viewing the source showed me that the text was indeed surrounded by <strong> tags.

Using the awesome Firebug extension for Firefox, I could see that the ext-all.css file was disabling the font-weight on the strong tag. This was quite surprising to me!

The ext-all.css file will automatically be included on your page whenever you use almost any of the UI features such as cfgrid, cflayout, etc.

You can easily reproduce the problem with this minimal code:

<cflayout type="tab"></cflayout>	
<strong>This should be bold but its not.</strong>

You can fix the problem by adding this to your site’s style sheet, if you have one:

strong { font-weight: bold; }

If you don’t use a separate style sheet you can just put it directly into your page like this:

<style type="text/css">
strong { font-weight: bold; }
</style>

Hopefully this can be fixed before 9.01 comes out. I think its a pretty big deal, it disabled tons of bold content on our site. A lot of our content is created using the FCK rich text editor, which uses strong tags to indicate bold. I’ve file a bug report with Adobe, you can vote for this bug here: http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html#bugId=82156

After looking through the EXT documentation, I think this css originates with the EXT group. But when Adobe repackages EXT into CF, they need to either override this style it or take it out of the css file completely.