Product Review

After an entire year spent meeting with and speaking to thousands of ColdFusion developers, the CF team at Macromedia are unleashing this month the feature-rich new release, CFMX 7.

It's been three years since we released Macromedia ColdFusion MX, the most dramatic and ambitious ColdFusion update ever. ColdFusion MX marked an important milestone in the ColdFusion story. It was a chance for the team to take a big step back and rebuild ColdFusion from the ground up, taking into account everything we had learned about web applications and how they are built.

ColdFusion MX was primarily an architectural release. It featured things like the following:

• A brand-new, Java-based engine
• A true compiler
• Deployment on top of industry standard J2EE servers
• Better support for XML, SOAP, and other standards
• Access to the world of Java

Of course, ColdFusion MX (and ColdFusion MX 6.1) also boasted important new features, language enhancements, improved performance, as well as greater scalability and reliability. But at its core, ColdFusion MX was all about architecture, an incredible investment in the inner workings of ColdFusion so as to facilitate a world of new functionality. ColdFusion MX has been an incredibly successful product, and a large portion of the ColdFusion user base is already taking advantage of all it has to offer. And so with ColdFusion's new engine proving its mettle and developers busily exploring the opportunities it presents, the ColdFusion team was able to spend time building new features and functionality that were not possible in the past.

For over a year we met with and spoke to thousands of ColdFusion developers. We presented ideas and previews to hundreds of user groups worldwide, brainstormed with countless partners and customers, waded through mountains of wish-list feedback, and chatted with numerous users (both current and potential). When the dust settled, a series of goals emerged:

• Make new users far more successful. ColdFusion has always appealed to new developers. There is no other language or product as well suited to their needs as ColdFusion. New users (primarily those with a background in building web pages and static sites) are an important part of the ColdFusion user base, and ColdFusion must remain dedicated to making successful development easier for these users. This involves the creation of Dreamweaver extensions and configuration screens, providing better out-of-the-box education, delivering more usable value, and more.
• Provide existing users with feature and functionality that they can use immediately. Developers are never shy about what they want. We need to deliver the features and functionality they ask for.
• Help developers (our users) make their users happier. Consumers of ColdFusion applications have common requests - things they'd like to see in the applications created for them. Many of these requests revolve around how the application captures and presents data. You said that ColdFusion must provide powerful new capabilities for forms, reporting, and printing.
• Improve reliability and deployment options. ColdFusion's Java internals opened up all sorts of powerful and important deployment and reliability options. Now ColdFusion needs to make this more available to you and your applications, more than ever before.
• Innovate, innovate, innovate. ColdFusion pioneered rapid development on the web. Indeed, there still is no quicker way to build web-based applications. The ColdFusion development experience needs to be applied to new platforms and technologies, making them just as readily usable.

These are significant, even lofty, goals. We invested tens of thousands of development hours, launched the largest beta test program to date, and maintained regular contact with our customers so that they could keep us focused and on track.

The result is the most customer-driven ColdFusion version ever, a feature-rich release that solves real problems for real developers building real applications, a product that meets and exceeds the enumerated goals.

And so I'd like to take this opportunity to formally introduce you to ColdFusion MX 7.

Improved Form Field Validation
Data-entry forms have long been the Achilles heel of web-based applications. Without bad-mouthing HTML forms (actually, there is little need to - you've all experienced the pain firsthand), ColdFusion MX 7 improves forms in several ways, starting with improved form field validation.

For starters, ColdFusion contains additional validation types, including the oft-requested validations for e-mail and URLs. In addition, the JavaScript error message that appears when using client-side validation displays all of the validation errors at once, not just the first validation error.

Perhaps more importantly, it is now simpler to perform both client-side and server-side validation at once. The cfinput tag has a new attribute named validateAt that accepts three values:

• onSubmit (the default value) specifies client-side validation when the client submits the form, just like client-side validation in the current cfinput tag.
• onBlur specifies client-side validation as soon as a field loses focus (user tabs to the next field or clicks another field, for example).
• onServer specifies server-side validation, the same type of validation that hidden form fields perform. However, it does not require you actually to define those fields (the fields are still present, but are generated and embedded automatically).

Look at the following code:

 <!--- Client-side validation on submit --->
 <cfinput type="text"
          name="quantity"
          validate="integer"
          validateAt="onSubmit"
          required="yes"
          message="Numeric quantity is required!">

 <!--- Client-side validation on loss of focus --->
 <cfinput type="text"
          name="quantity"
          validate="integer"
          validateAt="onBlur"
          required="yes"
          message="Numeric quantity is required!">

 <!--- Server-side validation --->
 <cfinput type="text"
          name="quantity"
          validate="integer"
          validateAt="onServer"
          required="yes"
          message="Numeric quantity is required!">

All three cfinput tags perform the same validation but at different points within the form submission process. The best part is that validation methods may be mixed. So to validate on the client and server you could do the following:

 <!--- Client-side validation on submit --->
 <cfinput type="text"
          name="quantity"
          validate="integer"
          validateAt="onSubmit,onServer"
          required="yes"
          message="Numeric quantity is required!">

Here the validateAt attribute specifies two values (onSubmit and onServer) so that ColdFusion generates client-side validation code and embeds hidden form fields for server-side validation.

Another validation enhancement is input masking. ColdFusion MX 7 introduces a new attribute to solve this problem: mask takes an input mask and uses it as a data input filter. A mask is a string comprised of special characters which are used to validate data entry: A question mark (?) allows any character, the letter A allows only alphabetical characters, the number 9 allows digits, and an X allows alphanumeric characters. Any other character is a literal and is itself embedded in the input.

For example, to validate a three-digit age, you could do the following:

 <cfinput type="text"
          name="age"
          maxlength="3"
          mask="999">

The mask filter "999" would only accept digits. If a user entered anything other than a digit, the tag would simply ignore that input. Similarly, to validate a US-style phone number in the format (123) 456-7890, you could use the following code:

 <cfinput type="text"
          name="phone"
          maxlength="13"
          mask="(999) 999-9999">

Again, the mask attribute value allows only digits, but inserts the other characters automatically. For a Canadian postal code you could use the following:

 <cfinput type="text"
          name="postcode"
          maxlength="7"
          mask="A9A 9A9">

You get the idea. Input masking does not negate the need for input validation, but it does make for a far better user experience.

Flash Forms
Another important enhancement to forms is less of an enhancement and more of a drop in replacement. Macromedia Flash has long been a potential replacement for HTML forms, enabling developers to leverage the capable Flash Player to deliver a better user experience. Of course, that has meant learning Flash or deploying Macromedia Flex. For ColdFusion developers who simply want better forms, there needs to be a simpler solution.

To make the creation of Flash-based forms easier for coders, ColdFusion MX 7 introduces a series of tags that make building powerful and sophisticated data-entry forms as simple as, well, ColdFusion. For example, if you need to prompt a user for a date (perhaps a date of birth), you can replace the HTML code:

 <form action="" ...>
 <input type="text" name="dob">
 ...
 </form>
 with the following:
 <cfform format="flash" action="" ...>
 <cfinput type="datefield" name="dob">
 ...
 </cfform>

This creates a form with a text field, just like the HTML text field, except that this one displays a pop-up date chooser when a user selects the field. It's that simple. Using a combination of cfinput tags to create controls, and cfformgroup tags to group them as needed, ColdFusion developers can generate Flash forms without knowing (or even owning) Flash.

A pop-up calendar is just the start of it. Other features include the following:

• Tree control
• Data grid
• Multipane forms (using tab or an accordion-style interface)
• Input masking
• Data binding between form controls
• Client-side events
• Integrated error checking and validation feedback

How does this all work? When ColdFusion processes a page containing these tags, it generates the Flash ActionScript needed to create the form and then compiles that code into a SWF file and embeds it in the page. All of that is hidden from ColdFusion developers who simply use CFML tags, just as it is already.

In other words, you can create forms that leverage the power of Flash while retaining the productivity and simplicity that has become the hallmark of ColdFusion. Stay posted to the ColdFusion Developer Center, as it will feature an article from the ColdFusion engineers who worked on Flash forms.

Printable Web Pages
Considering that most ColdFusion development involves applications that search and display data, it should come as no surprise that printing (or the inability to do so easily) has long been a source of aggravation for ColdFusion developers. After all, if you were to generate a web page and then select File > Print in your browser, well, you'd never really know what to expect the printed output to look like.

Developers have had to resort to all sorts of tricks to control printed output generation, with varying degrees of success - until now.

ColdFusion MX 7 introduces a new tag (a family of tags, actually) that makes turning web pages into printable content as painless as you'd expect from CFML. Look at the following code snippet:

 <cfdocument format="pdf">
 Here is some text.<br>
 <img src="image.gif">
 </cfdocument>

The cfdocument tag takes whatever code you provide and generates printable documents in Adobe PDF and Macromedia FlashPaper formats. In this example, the PDF would contain a single line of text followed by an image on the next line. That's all it takes.

The cfdocument tag is designed to work with any web pages. There is no need for XHTML or specific formatting. You can use inline formatting or CSS, you can embed images and links, you can use tables and <p> tags for alignment - it'll just work.

In addition, cfdocument tag supports the following, among other things:

• Page orientation of portrait or landscape
• Different (and custom) page sizes
• Headers and footers
• Different formatting options (page size, headers, and footers) for different sections of a document
• Saving generated output to disk

If you have web pages that you'd like to print - just about any pages - one simple set of tags will solve the problem for you quickly and efficiently.

Reporting
In addition to free-form page printing, ColdFusion developers often have another printing-related need: structured reporting. Third-party reporting tools have long been difficult to integrate with ColdFusion applications. ColdFusion MX 7 introduces its own reporting solution, a Report Writer and a reporting engine.

ColdFusion MX 7 introduces a new file type, the CFR (ColdFusion Report) file. CFR files are report templates you create with the new ColdFusion Report Writer, which looks a lot like other report-building tools you may have used. Once you have created a report, you can embed it in your applications using a cfreport tag, like this:

 <cfquery datasource="mydsn" name="myQuery">
 SELECT * FROM myTable
 </cfquery>
 <cfreport format="FlashPaper"
           template="myReport.cfr"
           query="myQuery">

As you can see, queries are passed to the cfreport tag at runtime. This means that a CFR file is actually more of a report template than an actual report, but you can use it to construct any SQL - dynamically if required. You have complete flexibility and control over how your ColdFusion application creates reports.

The ColdFusion reporting features the following:

• Reports that can be generated in PDF, FlashPaper, and Excel formats
• Intuitive report creation tool featuring report bands, data aggregation functions, embedding charting, and more
• Toolbars used to insert images, text, lines labels, as well as to manage data alignment
• Integrated SQL query builder
• Support for subreports (reports embedded within other reports)
• Report creation wizard
• Charting wizard
• Full zoom and preview support

ColdFusion reporting is available in all editions of ColdFusion, and ColdFusion Enterprise provides greater control so as to manage report creation in high-usage environments. Read more about reporting in the other CFMX 7 article in this issue Collin Tobin & Dean Harmon's article, "Building Reports in ColdFusion MX 7."

Event Gateways
ColdFusion has long been an incredibly simple way to build web applications. That's why we all use ColdFusion - for its simplicity (and therefore productivity). But ColdFusion is not exclusively tied to the web. In fact, ColdFusion does not even talk to web browsers; that is the web server's job. ColdFusion simply executes scripts on the server in response to requests - requests which (thus far) have been originated typically through HTTP.

Could ColdFusion respond to other requests - for example, data sent to a specific port, or changes in a folder, or inbound SMS and IM messages, or database table changes, or...? The answer is yes: ColdFusion can respond to any and all of those; it just needs a way to know when those events occur. It needs gateways.

Gateways are interfaces to other systems, ways for events to trigger ColdFusion processing. A gateway watching a folder on a server can trigger ColdFusion execution when folder contents change. A gateway connecting to an SMS provider can respond to inbound SMS messages (and send SMS messages as well). A database trigger can ping a gateway so that a database event forces ColdFusion processing (imagine being able to generate static HTML pages automatically and dynamically whenever back-end databases change).

Among the gateways included with ColdFusion MX 7 are the following:

• Asynchronous processing gateway
• Folder watcher gateway
• Socket gateway
• JMS gateway
• Lotus Sametime gateway
• XMPP protocol gateway
• SMS gateway

Third-party vendors are already hard at work creating ColdFusion MX 7 gateways. You could write your own gateways, too. The result is that ColdFusion is now able to interact with just about any back-end and technology available to you. You will be able to read more about event gateways and what you can do with them in Jim Schley and Tom Jordhal's article next issue, "Writing and Using Event Gateways in ColdFusion 7."

Improved Deployment
ColdFusion (as of ColdFusion MX) is a Sun-verified Java application, and is installed on top of J2EE servers like any other Java applications. Well, kind of. You can deploy ColdFusion MX (including ColdFusion MX 6.1) on top of a J2EE server but the complete process is one that does not excite J2EE administrators.

In J2EE-land, administrators are typically given an application to deploy, and they don't pay a whole lot of attention to what that application is and how it works. Nor should they. Developers should worry about applications and J2EE administrators should worry about servers staying up and running well.

How does this work? Applications to be deployed on a J2EE server are packaged as a single file, a Java archive file (usually with an EAR or WAR extension). The archive file contains everything needed for an application to run: source code, configuration settings, supporting files - everything. Once an application has been tested and is ready for deployment, it is packaged-the package itself being test-deployed - and handed off to the J2EE administrator, who drops it onto the J2EE server. (I am simplifying things a bit, but the basic flow is accurate.) What J2EE administrators don't do, or don't like doing, is running through a post-installation to-do list containing things like creating a data source, setting up some mappings, installing these extensions, and so on.

Yet J2EE administrators deploying ColdFusion MX must do just that. You can deploy ColdFusion itself - core engine, compiler, and runtime services - like any other Java application, but that is just ColdFusion itself. Once you deploy ColdFusion, someone still needs to move all the CFML and CFC files over and use the ColdFusion Administrator to define data sources and mappings and more. In other words, while ColdFusion itself is deployed like any other J2EE application, the total experience of deploying a ColdFusion application is not.

ColdFusion MX 7 changes this by giving you the ability to build complete J2EE deployment packages. It comes with a packaging tool that creates a complete EAR or WAR file that can contain the ColdFusion runtime (with or without specific features), application code, data sources, and more. The tool can take some time to run because building a complete, deployable EAR or WAR file is not a quick process. When it's finished, however, you can give that package to a J2EE administrator to deploy just like any other Java application. This means you can deploy ColdFusion applications on a J2EE server that is not running ColdFusion because your Java package file will contain the ColdFusion engine.

This is an important, and much-needed enhancement. >From a J2EE administrator's perspective, deploying ColdFusion MX 7 applications will be just like deploying any Java applications. Actually, J2EE administrators don't even have to know that it is a ColdFusion application. To them, it's Java pure and simple.

Multiple Instances Made Easier
ColdFusion MX Enterprise supports multiple instances of ColdFusion - although that is less a ColdFusion feature and more a J2EE-server feature that ColdFusion users can take advantage of. After all, ColdFusion MX is a Java application. I've discussed the benefits and importance of using multiple instances before but, simply put, using multiple ColdFusion instances provides greater security, stability, and scalability. It's almost like having ColdFusion installed on multiple physical servers, except it's all on one server.

If you have an existing J2EE server, you can create multiple EAR or WAR files and then deploy them as you would any other Java application. If you do not have an existing J2EE server, the ColdFusion installer can install JRun 4 for you. In doing so, it creates and deploys the first ColdFusion instance so that you can be up and running immediately. But when you want to deploy additional instances, things get a little tricky for users without experience in J2EE server administration. You need to use the J2EE server administration tools to create a new server, run the ColdFusion installer to create the EAR or WAR, expand the files (if using JRun), make tweaks to an XML file, and then copy the expanded files into the server folders. This is all feasible, but not exactly a trivial process. Unfortunately, this is why so many users have yet to deploy multiple instances.

ColdFusion MX 7 make this process much simpler. It has the same three installation options as ColdFusion MX 6.1, but selecting the JRun + ColdFusion option in ColdFusion MX 7 installs additional administration screens that make the deployment of instances (and even the creation of clusters of instances) as simple as any other ColdFusion administration processes. You'll be able simply to fill in a form and click a button to create a new instance - without needing to use the JRun management tools or the ColdFusion installer, without needing any XML tweaks, and without even knowing what an EAR or WAR file is.

How could you use this new functionality? Consider these use cases:

• You deploy a brand-new application, one that uses its own data sources and is built by a different development team (that needs ColdFusion Administrator access). You want the new application to be safely isolated from your existing production applications. Simply create a new instance, launch the ColdFusion Administrator for that new instance, define the data sources and any other needed settings, copy the code, and you are good to go.
• You are about to deploy an update to your application code and you need to maintain the existing application as a fallback, just in case something goes wrong. Simply create a new instance (you could even create a CAR file using the old instance to save data sources and any other needed configuration, launch the ColdFusion Administrator for the new instance, and import the CAR file to import those settings), copy the code, associate your web server to the new instance, stop the old instance (to prevent resources from being used unnecessarily), and you are done. If you then need to roll back, start the old instance and associate your web server to it again. Clean and simple.
• You have an existing application that spikes in load (holiday shoppers maybe), and you want an additional server running the same application so that you can handle a greater load, and also provide failover in the event that a server problem occurs. Simply create a new instance, point to the Java package containing the code and settings used for the first instance, and let ColdFusion do its thing. You'll have a second instance created, configured like the first, and containing the same application as the first. You can then use a second screen to create a cluster - perhaps to enable session sharing between the instances.

You Get the Idea.
Of course, for those who want more control, the installer will still install JRun with its own management software just as it does now - and you can deploy and manage applications just as you can now. But for those of you who simply want to leverage what is undoubtedly the most significant benefit of ColdFusion Enterprise over ColdFusion Standard, ColdFusion MX 7 makes life much simpler. Stay posted to the ColdFusion Developer Center; it will feature an article from the ColdFusion engineers who worked on the Enterprise Manager.

Lots of Other Goodies
This is just the start of it. Other ColdFusion MX 7 goodies include the following:

• XForms support
• Administration API Improved web services support
• Dreamweaver extensions
• Simplified authentication against NT domains and Active Directory

ColdFusion MX is the most eagerly anticipated version of ColdFusion in a long time. This is ColdFusion designed by developers, for developers; ColdFusion created in response to vast user feedback; and thus ColdFusion that solves real problems right out of the box.

If you are using an older version of ColdFusion, now is the time to upgrade. If you have yet to experience ColdFusion development, there has never been a better or more exciting time to start than now. Check out the upgrade options for ColdFusion MX 7.