More new tags and functions have been added to OpenBD and a brand-new CFML documentation site has been released! You can read more about the very cool new documentation site on the OpenBD blog and Alan Williamson's blog.

The cool thing about the docs site, other than the fact that it exists of course, is that the documentation is being pulled directly from the OpenBD engine, which means the documentation will always be up-to-date.

Because the documentation is being pulled directly from OpenBD, the docs are also specific to the version of OpenBD that you're running. So this isn't only an external site you can use for reference; the code for the documentation site is bundled with the OpenBD nightly builds already so you can run the documentation app on your own instance of OpenBD.

The documentation app also supports comments so you can add tips, etc. to the public site, but you can also leverage this on an instance you may be running internally at your company. This gives you the ability to have a CFML documentation site with notes that are specific to your team.

Here are the new functions and tags that were added in the last couple of days:

• ArrayIndexExists()
• ListIndexExists()
• REMatch()
• REMatchNoCase()
• CFHTMLHead
• CFHTMLHead()
• CFHTMLBody
• CFHTMLBody()

And for those of you who aren't aware, you can follow OpenBD on Twitter (@OpenBlueDragon) to get notifications of the latest goings-on with OpenBD.

In my continuing war against all things PDF in ColdFusion, today I believe I have achieved victory.

If you've been following my posts (OK, rants) over the past few weeks you'll know that I ran into some annoying bugs in CFPDFFORM that were wreaking all sorts of havoc with the one application I wrote that depends on CFPDFFORM for a key part of what it does. I sent my test case to Adobe Support and, well, there are probably a million ways to couch this nicely, but the bottom line is they told me they can't/won't fix the bug, and their suggested workaround was to use iText to populate my PDF forms instead of using CFPDFFORM. Given that I ran into another annoying bug with CFPDFFORM a couple of years ago and got another "can't/won't fix" answer, this was strike two for CFPDFFORM. And personally I don't like being backed into a corner by a third strike before making a change.

Now that my CFPDFFORM code had been changed over to use iText instead (which gave some nice speed benefits as well), the only remaining thing keeping me tied to ColdFusion 8 was the use of CFPDF to merge multiple PDFs into a single file. I looked into doing this with iText and although it's doable, even being the gearhead I am I have to admit that's a bit of a hassle. So before implementing that solution I decided to hunt around a bit more.

Enter Apache PDFBox.

PDFBox is already bundled with Open BlueDragon since we use it as the underlying libraries for some CFDOCUMENT functionality, but it's a version behind the absolute latest. Turns out that the newest version of PDFBox has a great, easy-to-use PDFMergeUtility built in. This made removing my dependence on CFPDF (which isn't in Open BlueDragon yet) pretty simple.

My application populates a varying number of individual PDF pages and then merges these pages into a single PDF file at the end of processing. So I use an "assembly" directory to build up the individual pages of the final result, and the final step is to merge the files. Previously I was using CFPDF for this:

<cfpdf action="merge" 
       source="#filesToMerge#"
       destination="#destDir##destFileName#.pdf"
       overwrite="true" />

And the PDFBox PDFMergeUtility solution looks like this:

<cfset pdfMerger = CreateObject("java", "org.apache.pdfbox.util.PDFMergerUtility").init() />

<cfloop list="#filesToMerge#" index="fileToMerge">
  <cfset pdfMerger.addSource(fileToMerge) />
</cfloop>

<cfset pdfMerger.setDestinationFilename("#destDir##destFileName#.pdf") />
<cfset pdfMerger.mergeDocuments() />

So it's a few more lines of code, but honestly not bad at all compared to the CFPDF version, and if you've been looking for ways to do some of what CFPDF and CFPDFFORM do in CF 8, between iText and PDFBox it looks like you're covered.

I was forced to make the switch from CFPDFFORM to iText in order to get around a bug in CFPDFFORM, and with that out of the way it was only one more step to make this application CFML engine agnostic. I need to do some additional testing but with the CF 8 dependencies removed the app is running great on Open BlueDragon. I'll do some comparison metrics but in initial testing, particularly since this is a CFC-heavy application, the speed and CPU load are both dramatically improved. Speed is about 30-50% faster (which makes a BIG difference when this app runs processing for hours at a time), CPU utilization is about half (CF completely pegs the CPU while this app is in full processing mode), and it's noticeably lighter on RAM as well. All told the minor hassle of reworking these portions of the app will have been well worth it.

I just got back from the wonderfully educational and inspiring BFlex/BFusion conference in Bloomington, IN, and I want to thank Bob Flynn for putting on another great conference and for his tremendous hospitality to Team Mach-II while we were in town. Save us a spot for next year!

BFlex is designed to be all hands-on sessions, some 90-minute and some full-day. This is a great idea and one which other conferences could stand to emulate, at least in a small dose. The hands-on sessions allow participants to bring their own laptops and get concrete experience in CFML and Flex as opposed to simply watching slides and hoping they remember how to do everything when they get back home.

This model is not without its dark side, however, and the hell of hands-on sessions can be summarized in one word: installation.

My hands-on session this year was entitled "Building and Deploying CFML on an Open Source Stack," and as I thought through all the bits and pieces attendees would have to install to get any value out of the session, I saw my 90 minutes being completely consumed by installation and configuration issues. Rather than chance it I decided that I would only expect attendees to install VirtualBox (because it's free and runs on Linux, Mac, and Windows), and I would give them a Linux VM with everything pre-configured. That way we could focus on playing with the open source stack instead of dealing with installation issues in the limited time we had in the session.

So I created my VM for the session, put it on a few thumb drives, and as I was doing some intro slides before the hands-on portion people installed the VM on VirtualBox and I hoped for the best. I expected at least a couple of people to have problems with the setup but to my amazement there were literally ZERO problems with the VirtualBox VM. By the time I was done flapping my gums everyone was ready to get their hands dirty.

The next morning I was a TA for one of the all-day Flex classes, and to call the configuration problems a bloodbath would be being kind. Trying to get a room packed full of people to get BlazeDS up and running when they all have different operating systems and hardware is a nightmare of epic proportions. Between the installation and configuration problems, not to mention some problems with the code files for the course, by the time lunch hit the class still couldn't proceed. Half of the full day class was gone, which put a serious dent in the amount of learning that otherwise would have happened.

My experience handing everyone a per-configured VM versus a room full of people trying to do a native install of a bunch of software was a major eye-opener for me. It's a simple idea, and it's the reason when you go to training centers that you use pre-configured workstations. Having people, even technical people, bring their own machines and install everything necessary for a course is a recipe for disaster.

So what does this have to do with Linux?

The VM idea is great and worked better than anyone had hoped. So why not do the same thing for the all-day courses?

Because that would be breaking the law.

Here's the problem. I could hand everyone in my session a VM because it was using Ubuntu and all open source software. Heck, I even made the VM downloadable for people who were attending a different session in my slot or who weren't at the conference.

Adobe software, at least the apps that would be used in training courses, only runs on Windows or Mac. Mac licensing prohibits VMs of OS X to even be created, and while you can create Windows VMs the proprietary license would prohibit a Windows VM from being distributed. Given the platforms on which Adobe software runs Windows would be the only choice for a courseware VM, but because of Windows licensing that isn't a possibility.

Which leads us straight back to installation and configuration hell.

At this point you might be thinking that pointing to training as a reason for Adobe to support Linux is a weak argument. Adobe has to worry about the overall market for sales of their products, after all, not just training scenarios.

I'll address that notion by asking a question: after struggling for several hours to get things up and running, and in some cases still failing, what does this do to course attendee's opinion of Flex? I doubt many people were hurriedly finishing their lunch to return to another installation torture session, and I'd be willing to bet it left a seriously bad taste in the mouths of beginners in the room (and this was a beginner class after all) who will see Flex as well beyond their reach after such a hugely negative experience.

Being able to run trial versions of Adobe software on a free operating system opens up a huge number of doors in my opinion. I truly hope that Bob and crew will find a way to do everything with VMs for BFlex next year; perhaps there are "lab" licenses available from Microsoft for just this purpose that expire after 30 days or something along those lines. Not ideal compared to a VM students could refer to long after the course is over, but at least it's something.

Using a free OS, however, would eliminate all the license issues that render trainers helpless and people can focus on learning instead of slamming their heads against installers and Java environment settings and all the rest of the nonsense that gets in the way of what they're trying to do.

I realize this is wishful thinking, but after having such a positive experience with free software and seeing the abysmal experience people had due solely to operating system licensing issues, all it did was convince me even more that free software is the way to go. Maybe Adobe will see the light someday as well.