BF on CF

In the May issue of CFDJ (Vol. 4, issue 5) I introduced you to ColdFusion MX - the just-released ColdFusion upgrade that is nothing short of revolutionary. As I explained in that article, CFMX features lots of incredible new technologies and features. But the one I think is most important (in terms of how it will, or should, impact your development) has to be ColdFusion Components. This month (and continued next month) I'd like to explain in depth what CFCs are and how they should be used.

CFCs Are Objects, Kind Of
To understand CFCs it's important to understand a bit about objects.

But first, a necessary qualification - CFML is not an object-oriented language, and CFCs don't provide all the features and functionality typically provided by OOP languages. This isn't a bad thing - actually, I think the opposite is true. Objects have too long been the exclusive property of languages and syntactical rules that are unnecessarily complicated. There's no reason for developers using rapid development languages, like CFML, not to be able to leverage this type of technology too. Thus the CFC.

At their simplest, and at the risk of offending OOP purists, objects are simply reusable application bits. They are black boxes - magical things that do stuff, whatever you define that stuff to be. If this sounds a bit like custom tags, well, there are similarities, but objects typically do more than custom tags. For example, they often contain not just code (like custom tags) but also data, allowing data and any code that accesses it to be cleanly encapsulated. Objects usually have multiple entry points (methods). They provide a mechanism to automatically run initialization code regardless of the entry point (a constructor). Objects can be adapted and modified, leveraging existing code without actually modifying (and potentially breaking) any of it in the process (inheritance).

If this all sounds a little esoteric, an example should help clarify things.

Objects Demystified
Almost any ColdFusion developer has had to deal with users in their applications. You've probably done things like:

• Used <CFQUERY> to check a user-provided name and password
• Used returned database rows to obtain a user's name and e-mail address
• Used programmatic flow-control to grant or deny access to features based on login name, access level, or security equivalences
• Saved and read user preferences like colors, fonts, language choices, topic and category selections, and more
• Added new users or updated or deleted existing ones
• ...and so on

In doing these things, how many places in your code ended up referring to users in some way, shape, or form? How much code did you end up repeating (or copying and pasting)? What would happen if the user tables had to change, and how much code would that affect? What if your databases were replaced entirely by an LDAP server, or new sets of rules and levels had to be applied? How much did nonprogrammers have to know about the guts of your user management to be able to do simple things like display a personalized welcome message?

In an object world you'd have written your application very differently. You'd have created a user object - a black box that contained everything and anything you'd ever need to do with users, as well as all the database (or LDAP) access needed to perform those operations.

To perform operations on a user, you'd then create an instance of the user object, perhaps specifying the user ID in the process. Then you'd be able to use methods (functions) like:

• Add()
• Delete()
• Update()
• Get()

Or even more specific ones, like:

• VerifyPassword()
• GetEMail()
• GetColorPrefs()
• GetDisplayName()

...the idea being that any and all user processing would happen inside the user object. You'd never access user tables directly. Actually, you wouldn't even know (or care) that the data is being stored in a table - that wouldn't matter at all. You'd just invoke methods as needed, letting the code inside the object do its thing.

This is the kind of functionality made possible using CFCs.

Introducing CFCs
Now that you know what CFCs are, let's look at how they're created. True to ColdFusion and its mission, CFCs are incredibly easy to create. In fact, only two steps are involved:

1.   Create a file with a .CFC extension (this distinguishes CFCs from ColdFusion templates, which have a .CFM extension).
2.   Use four new tags to create the components, define their functions and arguments, and return a value.

The four new tags are:

• <CFCOMPONENT>: Defines a CFC
• <CFFUNCTION>: Defines the functions (methods) within a CFC
• <CFARGUMENT>: Defines the arguments (parameters) that a function accepts
• <CFRETURN>: Returns a value or result from a function

Other than these new tags (which, incidentally, are the same ones used to create tag-based, user-defined functions in CFMX), CFCs are plain CFML. Within a CFC you can use any tag, function, custom tag, component, and more.

Creating CFCs
Listing 1 offers a simple example to clarify all this, a component that does basic browser identification (determines the browser being used).

This is a simplified version of a file named browser.cfc. As you can see, the code is wrapped between <CFCOMPONENT> and </CFCOMPONENT> tags. The component itself has a single function, IsIE (as in "Is Internet Explorer"), and is defined and named with a <CFFUNCTION> tag. Within the function a variable named result is defined and initialized; if the browser identifier contains the Microsoft Internet Explorer identifier, that variable is then set to "yes." And finally, <CFRETURN> returns "result."

This isn't a complete example yet (although it's actually workable as is), but it's a good starting point.

How would you use this code? Save it as browser.cfc, and in the same directory create a test.cfm file that should contain the following:

<!--- Invoke browser CFC --->
<CFINVOKE COMPONENT="browser"
METHOD="IsIE"
RETURNVARIABLE="result_ie">

<!--- Feedback --->
<CFOUTPUT>
Your browser is:<BR>
IE: #YesNoFormat(result_ie)#<BR>
</CFOUTPUT>

<CFINVOKE> is a new tag in CFMX and one of its jobs is to invoke component methods. As seen here, <CFINVOKE> takes the name of the component (browser, minus the extension) and the method to execute. To access any returned data, the RETURNVARIABLE attribute provides the name of a variable to contain whatever the function returns.

You can try running this code. If you are running IE it will tell you so, and if not it'll tell you that too.

Writing Complete CFCs
Now that you're familiar with how CFCs work, take a look at Listing 2, a complete version of browser.cfc. This new version is a bit more complex, so let's walk through it together.

<CFCOMPONENTS> now contains four methods:

• IsIE: Checks for IE, returning "yes" or "no"
• IsNetscape: Checks for Netscape, returning "yes" or "no"
• IsDreamweaver: Checks for Dreamweaver (the browser built into Dreamweaver), returning "yes" or "no"
• Identify: Checks for all three, returning "IE" if Internet Explorer, "NS" if Netscape, "DW" if Dreamweaver, and an empty string if unknown (none of the above)

You'll notice that we've added two attri-butes to every <CFFUNCTION>:

• RETURNTYPE: Specifies the type of the return data. This is used to validate returned data (if it's the wrong type, an error would be thrown) and to document the function.
• HINT: A text description used when the function is documented (more on that in a moment)

In the earlier version of browser.cfc the code checked the CGI variable HTTP_ USER_ AGENT to determine the browser used. But that's not ideal because these functions should be able to check any browser ID passed to them (assuming they're not always checking the current browser).

And so, each of these new functions takes an optional parameter defined with the <CFARGUMENT> tag, which can be used in two distinct ways:

1.   To check for required parameters, set REQUIRED="yes"; if the specified parame-ter isn't passed, an error will be thrown. Additional validation may be performed by specifying a TYPE, in which case ColdFusion checks that the parameter exists and that it is of the correct type.
2.   To check for optional parameters, set REQUIRED="no" and specify the DE-FAULT value to be used if the parameter isn't provided.

In all four functions <CFARGUMENT> defines a single parameter, browser, allowing calling code to pass any string as needed. If the parameter isn't provided, the default CGI variable is used as before.

The first three functions are basically the same as the one we looked at earlier, but the fourth, identify, which provides an alternate interface to the browser identification code, warrants special mention. Instead of checking for a specific browser (as the three prior functions do), this one checks for them all and returns an ID based on which browser it is. Rather than copy all of the previous code into this new function, it simply invokes those functions directly. But it doesn't invoke them using the <CFINVOKE> tag seen previously; rather, it uses them as functions (which they are), making the syntax much cleaner and simpler.

Listing 3, a revised version of test.cfm, can be used to test all the functions.

It's as simple as that.

Documentation
I mentioned that HINT and RETURNTYPE are used in documenting CFCs. So where is the documentation?

CFCs may be introspected - a fancy way of saying that they can be asked to describe themselves. As they know all about their functions and what they do, they can fulfill this request quite admirably.

Here are two ways to introspect a CFC:

1.   Execute a CFC directly in your browser, providing a URL directly to it (something like http:// local-host/path/browser.cfc). ColdFusion will generate cleanly formatted documentation on-the-fly, using everything it knows about the component (including the specified HINTs).
2.   If you're using Dreamweaver MX, select the Components tab in the application window to have Dreamweaver scan for available CFCs. Dreamweaver will then build a tree control containing all components and their methods. You may right-click on any component or method for more information (or to edit the code), and may even drag a method into the editor window to generate a complete <CFINVOKE> tag.

There's more to introspection, but we're out of space for now.

Summary
CFCs provide the power of objects with the simplicity of CFML. As seen here, CFCs are created using four new tags, saved as .CFC files, and invoked using the <CFINVOKE> tag. But we've barely scratched the surface here. In fact, thus far we've been using CFCs merely as glorified custom tags. Next month I'll show you alternate ways to invoke CFCs, how to make them persist, how to use constructors and inheritance, and much more. And we'll come back to the user explanation we started with.