Most Read This Week
Introducing...ColdFusion MX 7
After an entire year spent meeting with and speaking to thousands of ColdFusion developers...
By: Ben Forta
Mar. 15, 2005 12:00 AM
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:
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:
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
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:
<!--- 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.
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:
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
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:
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:
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:
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
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:
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
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.
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads