Support for user-defined functions is easily the most requested and anticipated enhancement to the ColdFusion Markup Language (and the announcement of this feature at last year's Developer Conference was met with an applause that can only be called thunderous).

We've come a long way in the past couple of years. Not that long ago I was teaching how to write simple custom tags and encouraging developers to experiment with them.

At the Developer's Conference a few months back I was fortunate enough to introduce and first demonstrate the next major version of ColdFusion - CF5. However, time constraints prevented me from going into as much detail as I would have liked. As this issue of CFDJ is all about databases, I thought I'd take the opportunity to tell you about two very important and exciting database-related features that will make their debut in CF5.

Fourteen columns ago in CFDJ (Vol. 1, issue 6) I wrote about wireless computing having finally come of age, the importance of WAP, and that ColdFusion developers could leverage this new and exciting technology quickly and easily.

In this article we describe how combining WML, ColdFusion, and the Fusebox methodology enables wireless data updates of the data- base of a working e-commerce Web site. To provide some context, we begin with a discussion of what this Web site is and what it does.

LizardTech Shipping Promotional Bundle (Seattle, WA) - For a limited time, LizardTech Content Server 3.0 can be purchased at an introductory rate bundled with LizardTech's MrSID and DjVu technologies.

In my last two columns we looked at JavaServer Pages (JSP) and compared ColdFusion development to JSP development. As explained, JSP is designed to dramatically lower the cost of entry into the Java development world, and JRun, in particular (with its tag libraries), does even more to deliver on this promise.

As I explained last month (and in several columns earlier this year), Java is here to stay, and Allaire is fully embracing the technology. For ColdFusion developers this is a scary proposition. The thing we love most about CF is that it's easy, simple, and rapid - and those arent adjectives usually used to describe Java.

Java is a reality. But for many CFers the buzz and hype surrounding Java is cause for much concern. For those of us who love ColdFusion because of its simplicity, Java can indeed seem intimidating. Much of that concern is legitimate. The fact of the matter is, there's no way you'll learn Java as quickly as you learned ColdFusion, and you'll definitely not be as productive as quickly.

It's been about five years since I inscribed my 'Ten Commandments of ColdFusion Development' for my first ColdFusion book, and as Commandments should, they've remained the same (more or less) with each subsequent revision.

ColdFusion features support for several different types of variables you can use in your applications...some types are simpler than others to use. When determining the type to use, simplicity and ease of use shouldn't be the only deciding factors. Use the wrong type...and performance can suffer

We all know that locking is important. Most of us even understand why locks are needed. But exactly where to use a lock, which lock type to use and what code to put within the lock remains confusing at best.

One of CFML's most misunderstood (and thus least used) features is the tag and its supporting scripting language. At the request of several readers (yes, I do take requests, and my e-mail address is at the end of the column), this month we'll spend a little time together exploring this mysterious tag.

As a rule I try to avoid the Access/CF discussion as it in-evitably provokes strong debate and even stronger emotions. Besides, the truth is - regardless of what I might suggest - Access remains an inexpensive and easily implemented solution. So why am I writing about Access now? Because I have come to realize that many users are considering only cost and performance in their decision-making process and are overlooking the bigger issues.

Personalization is the hottest trend in Web application development and for CF developers implementing basic personalization isn't difficult at all. In this month's column I'd like to explain what personalization is, why you should implement it and how to go about doing so.

Last month I stated that server-side Java was an ideal way to extend ColdFusion, and that Java would be playing a key role in ColdFusion's future. This month I'd like to continue this discussion with an overview of what Java is, what some of those acronyms mean — and what all this has to do with ColdFusion.

Yes, you read the title correctly, and no, I'm not losing it. I really do believe there are times when you should not use ColdFusion. And before crowds start gathering in the streets to burn my effigy, let me explain.

Doing so gave me the chance to clean up lots of old code (updating it to use new CF features in the process) while rethinking the organization and management of code to facilitate better reuse of common code and components. Code organization and reuse are important topics, and judging by lots of code I've seen at customer sites of late (production code nonetheless), they are topics that need clarifying and addressing. So I'd like to use this month's column to share some of these ideas with you.

I'm not talking about the obvious enhancements, things like: Linux version Native Solaris code Service-level failover Cisco LocalDirector integration Server-side Java support

Wireless computing isn't a new concept. In fact, almost every year of this decade has been proclaimed as the year in which wireless will finally catch on. And each year has come and gone without that happening. Wireless computing, it seems, is always just beyond the scope of the mainstream.

No one wants to write buggy code, at least no one I choose to know. Bugs are annoying, bugs are embarrassing. And bugs can cost you (and your clients) lots of time and money. Bugfree code is the ideal all developers strive for - at least should strive for - but it's a lofty goal not easily attained.

Barely a day goes by without someone wanting me to reassure them that ColdFusion scales. Whether it's Web administrators who are experiencing poor application performance, partners who want to be sure ColdFusion can handle their anticipated load, developers whose bosses are threatening their jobs over failed deployments, or press and analysts positioning ColdFusion as a 'low-end solution.' Whichever it is, inevitably I end up in the position of defending ColdFusion and its scalability.

In my last column (CFDJ Vol. 1, Issue 2) I discussed database query caching - how to improve application performance by eliminating unnecessary database access. While caching query results will improve application performance, optimizing your application doesn't stop there.

There's nothing that can kill your application's performance as quickly as database access. This is a shame, considering that almost every ColdFusion application you'll ever write will incorporate some sort of database integration.

There are lots of ColdFusion developers out there - that's good for us. There are also lots of ASP developers out there - that's good for them. ColdFusion developers are empowered with multiple ways to extend the     ColdFusion language - that's good for us. ASP developers are not as lucky - that's bad for them. ASP developers rely on COM objects to extend ASP - that's good for us. COM objects are usually DLL or EXE files and can be written in almost any language imaginable, such as C/C++, Visual Basic, Java and Delphi. Once the object is written, it's installed and registered on the computer it will be used on. Registering the COM object publishes it (and its interfaces) to other applications so they can use it. Almost all COM objects come with installation and registration instructions. Those instructions are the same regardless of the application using the COM object. Instantiating COM Objects To use an installed COM object, the first thing you have to do is initialize it for use. Usually this involves instantiating the object. To initialize COM objects in Cold Fusion, you use the tag, which takes the name of the object as an attribute and a name that you use to refer to that object once it's been initialized. The code to initialize AspChart looks like this: In this example the tag is creating an instance of the chart object. The object's name is 'ASPChart.Chart' (every object has a unique name) and it is passed in the CLASS attribute. instantiates the object, which can now be referred to as 'Chart' as specified in the NAME attribute. Just as a point of reference, here's the ASP code that does the same thing: Set Chart=Server.CreateObject ('ASPChart.Chart') As you can see, converting the sample ASP instantiation code to ColdFusion code is pretty simple.