If you've ever needed server-side printing under programmatic control, ColdFusion 8 introduces a new <CFPRINT> tag. <CFPRINT> prints PDF files (including those created using <CFDOCUMENT>, <CFREPORT> and <CFPDF>) to a printer of your choice. At a minimum, <CFPRINT> requires just the name of the PDF file to be sent to the default system printer, but additional attributes can be used to specify the printer, copy count, the pages to print, as well as to pass lots of other printer settings. The list of available printers (and their names, as must be passed to <CFPRINT>)is listed in the ColdFusion Administrator. And a new supporting GetPrinterInfo() function returns all sorts of information about specified printers.

The basic pre-populated data grid functions much like the <CFGRID> of old, pass it a query and it displays the data. Here is an example (which uses the example tables that come with ColdFusion):

Here a <CFQUERY> retrieves data, and <CFGRID> displays the results. The grid is straight client side HTML with CSS and JavaScript. You have control over look and feel including size, columns, colors, and fonts. And users can sort up and down, resize columns, and more.

The new <CFGRID> also supports Ajax type interaction, where data is not pre-populated, but is asynchronously loaded as needed. Here is a sample data grid:

This data grid is displayed in a window created using the new <CFWINDOW> tag (for no good reason other than I like the look of it). The data grid itself has no passed query, instead, it is bound to artists.cfc. When the data grid needs data it fires an asynchronous call to the getArtists() method in artists.cfc, and passes it four pieces of information: the current page, the page size (specified previously in the pagesize attribute), and the column being sorted on and sort direction (if the user opts to sort data). <CFGRID> thus requests data, and simply displays whatever ColdFusion returns, automatically supporting paging (assuming there are enough rows to so warrant).

Now for the CFC:

The getArtists returns a structure (containing data in the format required by the data grid), and accepts four arguments, the same four arguments passed in the client side bind attribute. The first two are always passed by the client, and so they are required. The latter two are only passed if the user clicks on a column header to sort the data, and so those arguments are not required and default to "". <CFQUERY> performs the actual data retrieval, conditionally sorting the data if sorting is required. And finally, the new QueryConvertForGrid() function extracts the desire data subset (using the passed page and pagesize values) and formats it as a structure which is returned to the data grid.

This is a basic example, and we'll look at additional functionality in future posts.

These controls are typically implemented using client side JavaScript to process arrays of data embedded in the page itself. Every possible combination and option is embedded in JavaScript in the page, and client side scripts update controls based on selection changes in other controls.

ColdFusion 8's new Ajax functionality makes this kind of interface really easy, without requiring any client-side scripting, and without requiring that all of the data be embedded in the generated page. Rather, <CFSELECT> controls may be bound to ColdFusion Component methods that are asynchronously invoked as needed.

To demonstrate this, here is a complete working example which uses one of the example databases that comes with ColdFusion. First the ColdFusion Component:

This CFC contains two methods. getMedia returns all of the media types in the art catalog database, and getArt accepts a media id and returns any art that is associated with that passed id. Both methods convert their results into two dimensional arrays, with the first dimension containing the id (to be used as the value in the <SELECT> control) and the second containing the display text. (For now, this two dimensional array is the format required by <CFSELECT>).

Now for the form itself:

The form contains two <CFSELECT> controls, one named "mediaid" and the other named "artid".

"mediaid" is bound to cfc:art.getMedia(), and so to obtain the list of media types to populate the control, the client makes an asynchronous call to the getMedia method in art.cfc, and populates the list with the returned array. As we'd want this control to be automatically populated when the form loads, bindonload is set to "true", this way the getMedia() call is fired automatically at form load time.

"artid" is bound to the getArt method in art.cfc. This method requires that a mediaid be passed to it, and so {mediaid} is used so as to pass the currently selected value of control mediaid (the first <CFSELECT>). Because these two controls are bound together, the second dependant on the first, ColdFusion automatically generates JavaScript code that forces artid to be repopulated with newly retrieved data whenever mediaid changes.

This example binds just two controls, but this mechanism can be used to relate as many controls as needed, and not just <CFSELECT> controls either.

Here's a simple client-side data example (which uses one of the CF8 example databases, so this should work for you as is):

This form displays a simple text box, but as text is entered, suggestions are displayed. The list of suggestions are passed to the autosuggest attribute which accepts a comma delimited list. The list could be hardcoded, but here ValueList() is being used to dynamically build a list based on a prior database lookup.

This is not an Ajax control in that lookups are not asynchronous, there is no communication back to the server to retrieve data, all data is local. This is actually a preferred form of auto-suggest for smaller lists.

For longer lists asynchronous interaction is indeed preferred, and the auto-suggest control supports this by allowing asynchronous calls to a ColdFusion component. Here is a sample CFC:

This CFC has a single method named lookupArt which accepts a string and performs a query to find all matches that start with the specified value. Auto-suggest requires that results be returns in a single dimensional array (for now, hopefully this will change before we ship the final product), and so the code populates an array with the results which are then returned.

Now for the modified form code to use this CFC and method:

Here the autosuggest points to a CFC, and as the CFC (I named it art.cfc) is in the current folder, no path needs to be specified. When a user enters a value, generated JavaScript code triggers an asynchronous calls to the lookupArt method in art.cfc. {cfautosuggestvalue} gets automatically replaced with whatever value the user has entered, and that value is then used by the CFC in the lookup. When an array of results get returned the auto-suggest list gets populated.

Auto-suggest does not get any cleaner and simpler than this.

Here is the code:

And here is a simple test example:

Wonderful! This just made my day (well, on top of the CF8 public beta making my day, of course).

First of all, you need ColdFusion 8. If you don't have it yet, get it!

You'll also need the ColdFusion 8 Eclipse extensions, and these must be installed (here is some installation help).

Before you can use the interactive debugger you need to enable debugging support in ColdFusion. Here's what you need to do:

1. Open the ColdFusion Administrator.
2. Select "Debugger Settings" in the "Debugging & Logging" section.
3. Check "Allow Line Debugging".
4. The debugger needs a port to communicate over, if you can't use the default change it (just be sure to use an unused port, and you can't use the port that ColdFusion itself is on).
5. By default ColdFusion allows up to 5 concurrent debugging sessions, you can raise or lower this value as needed.
6. Click "Submit Changes", and restart ColdFusion is you are instructed to do so.

Once you enable line debugging it will remain enabled even if ColdFusion is restarted. As a rule, do not enable line debugging on production servers, and you may want to always leave it enabled on development boxes.

Now that debugging is enabled, you need to configure Eclipse to tell it what ColdFusion server to debug against. Servers need to only be defined once, and once defined you may debug against them as needed. You can define as many servers as you need, local and remote, as long as the server has RDS enabled (and you have an RDS login).

The first thing you need to do in Eclipse is define the RDS settings for your ColdFusion server. These settings are used by the debugger, as well as the wizards, RDS panels, and more. To define your RDS connection do the following:

1. In Eclipse, select Window->Preferences to display the Preferences dialog.
2. Select ColdFusion in the tree, expand the selection, and select RDS Configuration.
3. Click New to add a new server, or just select any server to edit it.
4. Provide a description, host name, port, and login details, and then save. To use your local ColdFusion server specify 127.0.0.1 as the Host Name, 8500 as the Port (if using the integrated HTTP server), leave the Context Root blank, and provide the login information.
5. Click "Test Connection" to make sure the RDS connection is working, and the click OK.

Once the RDS connection is defined you'll be able to browse data sources in the RDS Dataview tab, view available CFCs in the Services Browser tab, use the wizards, and more. And you'll be able to debug applications, but first ...

Now that your RDS connection is defined, you need to define the ColdFusion servers you wish to debug against. Here is what you need to do:

1. Locate the Debug button in the toolbar, it's the one with the little green bug on it.
2. Don't click the button, instead, click the down arrow to the right of it and select "Debug ..." to display the Debug dialog which is used to manage debugging configurations.
3. The Eclipse debugger is used to debug all sorts of applications created in all sorts of languages, and along the left of the dialog you'll see a list of applications types that can be debugged. Select "ColdFusion Application".
4. You'll see any defined ColdFusion debugging servers under the "ColdFusion Application" branch. To add a ColdFusion server click the New button (the leftmost one above the list) while you have "ColdFusion Application" selected.
5. Name this server, and then select the RDS server to use from the drop down list.
6. If you are debugging against a local server (running on the same machine as Eclipse) you can ignore the mappings section. If ColdFusion is on a remote server then you'll need to define mappings here.
7. Click "Apply" to save your changes.

Again, servers need to be defined once, and they'll be saved for future use.

To debug your code you can do the following:

1. Open the ColdFusion file to be debugged in Eclipse.
2. Set breakpoints as needed by double clicking to the left of the desired line in the vertical bar to the left of the Eclipse editor window. You'll see a little circle appear indicating that a breakpoint has been set. You can also right click in the vertical bar and select "Toggle Breakpoint".
3. Now you need to switch to the Eclipse Debug view (called a "Perspective" in Eclipsese). If you see a Debug button listed with the Perspectives on the top right of Eclipse, click it. Or, just click the Open Perspective button (or select Windows->Open Perspective) and select "Debug".
4. Once you are in the Debug perspective start the debugging session. To do this, go back to the dialog where you defined the ColdFusion server (under the Debug button), select the ColdFusion server to debug against, and click the Debug button at the bottom of the dialog.
5. Eclipse will pause while it opens a debug session, connecting to the specified ColdFusion server. You'll see the connection show up in the Debug window.
6. Now just open any browser and run your application. When you request a page with a breakpoint, execution will pause, and the debugger will pop up. You'll be able to step through code, view variables and expressions (in the top right panel), see generated server output, and more.
7. When you are done debugging, you can terminate the debug session by clicking the red square Terminate button.

And that'll do it. I know this seems complex and a lot of work, but the bulk of it is initial setup. Once that setup is complete you'll be able to quickly and easily fire up the debugger on demand and when needed.

To install the Eclipse extensions, do the following:

1. Start up Eclipse (3.1 or 3.2).
2. Select Help->Software Updates->Find And Install.
3. Select "Search For New Features To Install".
4. Click the "New Archived Site" button.
5. Brows to select the extensions ZIP file that you downloaded.
6. Check the feature, and then Finish the installation.
7. You'll be prompted to restart Eclipse.

Once installed you'll have access to all of the extensions. The Wizards are available under File->New->Other. To display the ColdFusion tabs go to Window->Show View->Other, the tabs will be listed under "ColdFusion", select each tab to show it. You only need to do this once, the next time you start Eclipse the settings will be remembered and the tabs displayed.

Apache Derby is a Java based open source DBMS, and it is generally used in one of two ways:

• As a client server DBMS, Derby runs on a variety of Java servers, and multiple clients can connect to it (much like MySQL or SQL Server etc.).
• As a local engine embedded in another application, allowing that application access to a local data store (kind of like an Access MDB file, although it is actually a set of folders and files as opposed to a single file).

ColdFusion Scorpio comes with two Apache Derby drivers, one for each of the deployment types. The "Apache Derby Client" driver connects to a Derby server, and it needs a host name as well as login credentials. The "Apache Derby Embedded" driver uses a version of Derby that is embedded within ColdFusion itself to access local Derby data stores. Local data stores created and used by ColdFusion are located in a folder named "db" under the ColdFusion root. (The example applications that come with ColdFusion all use local Apache Derby data stores in Scorpio).

So far so good, but then things get tricky. As an embedded database engine, Derby has no client and no UI. Rather, it has APIs and is intended for use by developers within their Java applications. So, if you wanted to create a new Derby data store for use as an embedded Derby database, how would you create it? Creating tables is easy enough, once you have a database you can use CREATE TABLE and so on, but how do you create the database in the first place?

The Apache Derby Embedded driver accepts an optional connection string attribute named "create", which, if set to "true", creates the specified data store. So ...

To create a new Derby data store, use the "Apache Derby Embedded" driver, name your data source, specify a folder name in the Database Folder field (just provide the folder name, not the full path, and you'll probably want to keep this the same as the data source name), then click the "Show Advanced Settings" button and in the Connection String field enter "create=true" and then just submit the form. ColdFusion will attempt to connect to Derby, passing "create=true" which creates your new data store (in the ColdFusion "db" folder) which you can then use. You can leave that Connection String in there, if the data store already exists it is just ignored.

(When the final ColdFusion 8 ships we hope to include a Create checkbox, so you'll not need to mess with connection strings at all).

Now that you have a data store and datasource created you can use CREATE TABLE to create your tables, and get to work using your new database.

Oh, one last thing. If you want to distribute a database for use you'll want to create it, and then ZIP up the entire data store folder for distribution. Users will then only need to unzip the file in the DB folder and then add the data source in ColdFusion using the "Apache Derby Embedded" and specifying the name of the data store folder.

UPDATED 07/07/2007 with simplified creation instructions.

Do you think? ... nah, couldn't be! ;-)

So what does this have to do with ColdFusion? Well, Jason Delmore mentioned this in passing at cf:Objective (and few picked up on it), but we plan to include Apache Derby in ColdFusion Scorpio. The practical implication of this is that if you have to distribute an app that needs a database, you'll now have one that will work consistently on all platforms (no more having to tinker with different databases on different platforms).

ComputerWorld used to be a major force in IT journalism, so you can't really blame them for having to resort to sensationalism so as to try to attract traffic to their site. But, Mary Brandel's pathetic piece entitled "The top 10 dead (or dying) computer skills" sinks to new lows.

But before I go any further, who is Mary Brandel, and what background makes her the authority on the subject of technology trends? A quick search through ComputerWorld archives shows such hard-hitting technically in-depth stories as "How To Survive A Bad Boss", "Budgetary Black Holes", "Five Ways To Defeat blog trolls and cyberstalkers", "Seven Essential Ingredients for Leadership", as well as stories on outsourcing, CIO profiles, and management advice. In other words, nothing overly technical at all. In fact, despite multiple searches in all the obvious locations, I could find no evidence that Mary actually has real technology experience, other than talking about it of course. So, as you read her story, keep that context in mind, a story is only as legitimate as the person writing it.

Now on to her pearls of wisdom. Mary lists ten technologies that she considers dead or dying. Among them she includes Cobol, Non-relational DBMS, cc:Mail, CNEs, OS/2, and ... ColdFusion. Yep, she actually ranked ColdFusion right there with OS/2 and PowerBuilder and non IP networks. It makes you wonder what science and research drove this list. Comparing products and technologies that have not been updated in over a decade to one being updated as we speak?

Although, and this should be telling to you, she probably does not know that ColdFusion 8 is due out this year. Why? Because we are conducting press briefings now, and are talking to all sorts of publications and media. ComputerWorld, however, has refused our invitations! It seems that they'd rather spew sensationalism then actually invest time into researching stories.

But, for a real laugh, look at her reasoning: "[ColdFusion] has since been superseded by other development platforms, including Microsoft Corp.'s Active Server Pages and .Net, as well as Java, Ruby on Rails, Python, PHP and other open-source languages".

Specific languages aside, did she not do any homework at all? Does she actually know what these technologies are and are not? Java? Is she even aware of the ColdFusion Java relationship?

And as for her comments about ColdFusion developers not being paid as much, and implying they are a dying breed and not in demand, has she even bothered to talk to any? Or to drop by events like MAX and CFUnited and cf:Objective? Judging by the reaction from the ColdFusion community, many are insulted by her insinuation, ramblings not based on fact and reason, and they have every right to be so.

Mary, considering your lack of experience and inability to conduct research, I'll forgive you this demonstration of irresponsible journalism. But only on condition that you take the time to learn a bit more about the product and technology you so easily dismiss. The invitation to brief (or educate) you on ColdFusion and the upcoming ColdFusion 8 still stands. Which means you have to decide what's more important to you, journalistic integrity, or doing whatever it takes to be read. The ball is in your court.