The banner ad is a bit of a curious creature.

It wasn't so long ago (say, 1998) that the pundits who had for so long decried the gluttonous, indelicate banner ad were immersed in self-congratulation. Click-through rates were dropping below 1% down to .5% by the start of 2000.

Users don't even see them, the pundits claimed. They've learned to block out the banners and scroll past them; people will turn to other forms of advertising, such as the content ad. And perhaps, to an extent, they have.

Consider the number of Web sites you viewed today. How many of those sites feature banner ads? A large percentage I wager.

The curious thing about banner ads is that everybody hates them, everybody "ignores" them, and yet they continue to exist with Terminator-like persistence. The bottom line is this: as long as the marketing people are expecting us developers to schlepp banner ads from site to site, we might as well make it quick and painless. As you know, the best way to make code portable and to hide its implementation is to write it as a custom tag. Hence, <cf_BannerAds>.

In this article we write a custom tag that does the basic things a banner ad needs to do. We need to generate a random banner ad from the database that stores the ads, display it back to the page at the point the custom tag was called, and then update the number of times that particular banner has been displayed. Finally, we need a way to record a click-through and redirect the user to the target site.

We can fulfill all these requirements in fewer than 50 lines of code in a custom tag. We'll use a Microsoft SQL Server database to hold our data, though an Access database could be easily substituted here. You should come away with a custom tag that you can use without hassles in a production environment.

Defining the Application
We begin writing our tag (see Listing 1) by defining a banner ad in specific terms. It's comprised of an image and a URL to open if the user clicks on the ad and is often a constant width and height (468 x 60). A company name is associated with it, which we can use in the Alt attribute of the HTML <img> tag.

It's probably a good idea for each banner ad to have an associated unique identifier. In the real world, somebody in accounting is making sure these ads are paid for. Although here we're simply making the banner ad rotator work, a unique ID allows each banner to be associated with a customer account.

What we've done so far allows the banner ad to be displayed. That's only one possible action, however, it can also be clicked on. When that happens, we need to update the number of times the ad has been clicked on and then redirect the user to the URL associated with the ad.

Because this month's issue of CFDJ focuses on custom tags, let's detour for a moment to examine why this required functionality is a good candidate for a custom tag. What do you do when you work on a Web site? You don't say to yourself, "Hey, Earl, I think I'll write a custom tag. Now what should that sucker do...?" The process generally starts from the other end. Upon defining a feature set for some required function (e.g., the client wants rotating banner ads), you determine whether or not you should make it a custom tag.

There are a number of good ways to make this determination. I'm sure you've read about the general criteria: will you want to reuse this code, encrypt it, conceal complexity from less experienced developers, conceal variables from exposure on the calling page, and so on? If you've worked with Java, you might ask yourself: If I were writing in Java, would I make this an object? A banner ad is fairly discrete. It has a couple of different modes: it can be displayed or it can be clicked on, and it behaves differently in each instance. It can have methods (getBanner,setClickThroughs, etc.). You might ask, "Will I need to reuse this code frequently and be able to port it easily to different applications?" As it happens, a banner ad rotator is a good example of when to incur extra application overhead (and possibly extra development time) and write it as a custom tag.

Building the Application
Now that we've determined what needs to be done and that it's best implemented as a custom tag, we can figure out how to write it. Let's start by writing the banner ad into a database table. This table (see Table 1) will be implemented in Microsoft SQL Server, though it should run with little or no modification on other systems.

Once we have our database table, we can enter a quick row of dummy data and then write the query to return the result set. This makes sure that everything is working properly, and it throws us impatient, instant-reward types a bone. Let's walk through the code and see how it works.

Displaying a Random Banner
First, we have to determine what action should be performed. We create a regular local variable called banner.action that we'll use to switch against in the main body of the tag. Possible values are display (the default) and click. We use the Immediate If (IIF) function to determine the value of banner.action. If the variable URL.AdAction is defined, the user has clicked the banner ad; if it isn't defined, then we need to retrieve a new ad and display it.

Certainly the most complicated aspect of the tag is retrieving a banner randomly. Here's the code that does it:

<cfset RandomID = RandRange(1, getBannerIDs.RecordCount)>

<cfset thisBannerID = ListGetAt((ValueList(getBannerIDs.BannerID)),RandomID)>

First, create a local variable called RandomID that will hold a random number between one and the number of banners currently in the database. Next, create a local variable called thisBannerID to hold the banner we'll display in this call to the tag. As you may know, the ValueList function returns a comma-separated list of the values of each record returned from an executed query (in this case, "getBannerIDs"). We then pass the result of the ValueList as an argument to the ListGetAt function, which retrieves the element in a list from the given position (in this case, the value of the RandomID variable).

Now we've got a primary key, which we use in another query to retrieve all the information required to display an ad: the name of the image, the URL of the advertiser's Web site, and the AltText. Then we simply write out the HTML with the appropriate tag attributes populated with the results of our query. Note that we're storing the name of the image in the database - you need to have the actual image stored somewhere on the Web server (here images/banners/).

When we create the ad for display, we include three parameters in the construction of the link: AdAction tells the custom tag that we need to run the code inside the "click" case; the "thisURL" parameter will tell the tag the address of the Web resource to display when the user clicks on the ad; finally, the "BannerID" parameter is passed to tell the tag which banner to update the number of click-throughs for.

Now we need to update the number of times this particular ad was displayed, so we hit the database again and set the Times-Displayed column for the ad with the current BannerID to Times-Displayed+1.

As these are all the requirements for displaying an ad, we exit the case, and thereby the switch and the tag.

Now we need to create the code that runs in the event that a user clicks on a banner.

ClickThroughs
All that remains in the "click" case is to handle two events: update the number of click-throughs for this particular ad and relocate the user to display the Web resource associated with the ad. We update the ClickThroughs in much the same way we updated TimesDisplayed. Using the "thisURL" parameter we set up in displaying the ad, we simply pass it to a <cflocation> tag and we're done.

To use the tag on your site, set up the database and populate a few rows, then call <cf_banner>. Listing 2 shows a simple table and how to call the custom tag for use on your site.

As you can see, this setup is compact and easy to use. You can expand and improve on this basic tag a few ways. For instance, instead of hitting the database so much, try using the <cfsavecontent> tag, new with ColdFusion 5, to store your banner info. Also, you might create a "data source" attribute of the tag to make it more flexible. Last, if your system requires it, add a column to the database called "weight", and use it to calculate which banners should be shown more frequently.

• Source Code
• Figure 1