You may have noticed that BlueDragon does not calling COM objects from CFML in the same manner supported by ColdFusion: <CFOBJECT Type="COM"...> or CreateObject("com",...). This doesn't mean that you can't call COM objects at all, but that if it is possible just that there are extra steps. There may also be alternatives to using COM objects entirely. This FAQ addresses this challenge.

The good news is that there may be several ways to get around this limitation. It may be that CFML now offers equivalent functionality to the old COM object. Or, it may be possible to leverage Java or .NET libraries right from CFML that perform the needed feature. Indeed, the maker of a COM object may now offer a Java or .NET equivalent. If you're using our .NET edition, there is more direct support of COM objects (by way of .NET's own support of them). Finally, there is always the possibility of implementing any of the avalailable COM bridge packages yourself in BlueDragon. Don't let the lack of CFOBJECT Type="com" be a show-stopper. Following are discussions of each of these points.

Perhaps CFML Now Does What You Need

We've often found that the things people used COM objects for have been added to CFML, sometimes as was defined by Macromedia, and sometimes as new features we have added to BlueDragon. So you may simply not need the COM objects anymore. (If your needs are not met by current CFML features, we'll discuss how to get around that as well.)

For instance, one client wanted to perform zip operations (zip/unzip files). Of course, CF has no CFZIP tag, so a COM object (or a CFX) seemed an obvious choice to generations of CFML developers. The good news is that we heard that cry and have added a CFZip tag to CFML in BlueDragon 6.2. This is similar to how in previous releases we added CFIMAGE to do image manipulation (another thing one might look for from a COM object) and CFIMAP to do IMAP-based mail processing. We try to solve the problems that CFML developers need but Macromedia doesn't address.

Another client used COM objects to do authentication against the Windows Active Directory. Again, CFML might seem to have no built-in feature for that (CFLOGIN certainly doesn?t do it). But we pointed out that CFLDAP does indeed offer all that he needed, and BlueDragon does indeed support CFLDAP.

Some have used COM objects to create Excel spreadsheets, but you can create spreadsheets in CFML very easily. See our FAQ 292 for more information.

So sometimes COM objects were a last resort that really may no longer be the only alternative.

Accessing the Functionality via Java or .NET

In other cases, where you had some other use for COM not yet mentioned, you may also be able to enable it by leveraging the underlying platform (Java or .NET, depending on the edition of BlueDragon you're using). Again, often problems have been solved in those frameworks, and it's possible to call Java or .NET objects from within CFML using CFOBJECT, as discussed in our BlueDragon User Guide. There are Java libraries for creating PDFs, creating Excel spreadsheets, creating reports, and much more.

Indeed, it's entirely possible that the maker of your COM object may now offer a Java or .NET equivalent. COM is an older technology, and many vendors have gotten demand for more native alternatives. Ask your vendor, and if they offer one, we can help show you how to call that from within CFML. Indeed, you may find that your CFML calling the COM object would not other than changing from TYPE="com" to TYPE="java" or ".net". At least as long as the object's interface hasn't changed, t's still a process of calling objects and their methods and properties.

Accessing the COM object using BlueDragon.NET

In BlueDragon.NET, you can more directly access COM objects because .NET provides for a mechanism called "runtime callable wrappers". With these, built easily using Visual Studio or the command line .NET utility, tblimp.exe, you end up with a DLL that you can then call from CFOBJECT, and the wrapper acts as a proxy to the COM object. See the section 4.1.3 of the manual, "Integrating CFML with ASP.NET Servers" for examples as well as more information on supporting COM objects from CFML on BlueDragon.NET.

Again, though, it's also possible that the vendor of the COM object you're using may offer a native .NET object and you could call that more directly, as described in the previous section of this FAQ.

Using a COM Bridge

Finally, if you absolutely need COM object support in one of our Java editions and the solutions above don't work, there are available Java-COM bridge products available (some open source, some commercial). Some of the alternatives include:

New Atlanta has not yet tested these with BlueDragon, but since BlueDragon does support CFML-Java integration (see the BlueDragon 6.2.1 User Guide), it should be possible to call the Java objects created by these tools which would point to the intended COM objects.

Summary

So if you currently need COM object support, let us know what you need and we may be able to help you determine if equivalent functionality could be reached via an alternative. We realize that there could be an impact to your code so that changing to use an alternative is less desirable. As we say about BlueDragon's other few differences from CF, if you need the benefits we offer (price, support, options for bundling, protection of source code, more standard deployment on J2EE, the only option for CFML on .NET, and lots more), then making modest changes to work in it may be well worth the effort.

Keep in mind, also, that we're talking about changes that would often be backward-compatible with CF. As discussed above, COM objects used to be the only way to do some things. Changing code to work on BD to get around the lack of COM may be just as valuable to code running on CFMX as on BlueDragon, especially if you have to buy and license those COM objects for multiple servers, and the workarounds allow you to stop relying on the no longer needed COM objects.