Google Analytics depends on JavaScript to make image requests to GA servers, and therefore only tracks your JavaScript enabled visitors. This is why Remy Sharp wrote a blog post a few weeks ago called "The Missing Stat: noscript" where he outlined some work he'd done on how to track your noscript visitors with Google Analytics and PHP.

If you read the comments on Remy's post, you will see that his PHP code was ported to .NET by Erik Zaadi which is available at Github here and called "GA.NET". Erik also wrote about his project here.

So after reading all of this I decided to port the code to ColdFusion, but after reviewing the code Remy wrote I started to see some real potential for handing the GA tracking logic for the image requests made to GA servers with server side code. In other words, you should be able to track page views, events, and more on your visitors that have JavaScript disabled.

So I started GA.CFC for ColdFusion and put it on GitHub, it's basically Remy's PHP code ported to CF, with the one difference being that when using GA.CFC you must provide the domain hash which GA generates to GA.CFC, which I guess Remy thought was a random number; his code worked anyhow apparently though.

I plan to extract GA's hash function later so that you won't have to input the domain hash, and I have plenty more updates planned for the future, but I decided to upload GA.CFC to GitHub now so that others can use it in the meantime.

Currently you can track pageviews, but each page view is considered a new visitor. Please read the README file for GA.CFC for usage instructions.

Get GA.CFC at GitHub here

Well it doesn't happen often, but today it has happened again, I was blown away by another Firefox extension, and even less frequently I'm blown away to a new level, well today is another one of those days, welcome Ubiquity. I recommend you read Aza Raskin's post, because it is well worth it. But my short summary of the Ubiquity extension is that you can easy make command's for firefox with javascript, and furthermore, it's extremely easy to share these commands, and send updates.

I've been playing with it for about 2 hours now, since I read Aza's post, and I have already have got my first command published, here it is:

• coldfusion: Searches the Coldfusion 8 LiveDocs for a term.

An example command would be:

I put the following code after the first line of code of my blogCFC's application.cfm (and the comments), for a application.cfc converted site, this should go in the onRequestStart method:

Duplicate content is bad, mmmm K..

So to avoid it, redirect your www.domain.com to domain.com, or I'm sure anyone can alter this quickly to do the reverse.

I'd love to see any https alterations, or I'll probably do my own eventually too..

For today's post I thought I would write about the CFFORM tag, and why it sucks. There has been plenty said about why it's so useful already, so I thought something should be said about it's faults.

The main problem I see, is simply that using cfform means coldfusion will inject javascript on to the page. Now that doesn't sound too bad to some of you, but anyone that thinks unobtrusive javascript is a good thing may disagree.

To use an analogy, using cfform is like fast food, it's fast, it's easy, it's cheap, and it gets the job done, but it's sooo unhealthy. All javascript should be in a javascript file so that it's cached and downloaded once, this is the healthy way. And if you use a javascript library hosted at google code, then your users will only download the version of javascript you are using once, no matter how many sites they visit, using the same google hosted code. To put that another way, if you're using jQuery 1.2.3 hosted by Google, and someone else is too, on their site, then any visiter of both sites will only download jQuery 1.2.3 once!

So, I was reading a recent discussion on the difference between the switch statement and the if...else statement, on the CF-Talk Mailing List, and I thought I'd write about just how cool switch statements really are.

First I want to point out a couple of clear advantages of the switch statement over the well known if...else statement:

• We have a single expression that is only evaluated once.
• We can run multiple segments of code for a given value, which handy for clean code reuse.

Now let's consider the downside of a switch statement:

• The switch statement handles a subset of problems that the if-else statement can handle, albeit more efficiently in many cases where they overlap. I like to think of the switch statement as a logic factoring solution which is available to me for simple types of if...else statements.
• Cannot use variables in the case statement (unless your using Javascript!)

Here's an example of a Coldfusion if...else statement that can be simplified with a switch statement:

Now here is the simplified switch statement version:

So in this example, not only is the switch statement version reusing code, making it less lines, but it should run faster, especially if you eat a lot.

Now, the thread I read on Cf-Talk began with someone asking why one cannot use a variable in a Coldfusion case statement, and the short answer to this was that Java won't let you do this in a switch statement either. Java will allow you to use constants in a case statement, as was pointed out in the thread, but since constants do not exist in Coldfusion, they cannot be used in a Coldfusion case statement. I suppose this functionality could be implemented into the Coldfusion switch statement, but that would mean that Coldfusion switch statements would simply be converted to Java if..else statement, and lose the performance gained by being a Java switch statement.

But anyhow, the point I wanted to make was that in Javascript using a variable in the case statement is possible! so when you Coldfusion/Java programmers are writing some Javascript next time, heads up.