Why Java Should Not Temper ColdFusionML Talents

A growing number of IT managers are being pressured to transition from using the open standard ColdFusion Markup Language (CFML) to Java Server Pages (JSP) and servlets. In this article, we’ll look at why (and for what purposes) CFML, originally created by Macromedia, still excels over JSP.

One reason to leverage your CFML programmers? CFML may offer more features and performance than you might think. To put CFML into context for your enterprise development, first, let’s get our definitions straight.

CFML: Open Standard Language and Framework


Sometimes, people have a misguided notion of what CFML is. CFML solves the same problems as JSP: It’s a server-side scripting language for dynamic generation of web content (typically HTML). Created originally for ColdFusion Server (by Allaire, later acquired by Macromedia), CFML is no longer a single-vendor, proprietary language. For instance, New Atlanta (under the BlueDragon product line) offers several implementations of CFML, which allow you to run CFML on both J2EE and .NET servers, adding the possibility of tight integration with native applications.

Designed from its inception to make dynamic, database-driven applications easy for HTML coders, CFML has always been easy to understand, with code that looks a lot like HTML. More importantly, CFML packs a lot of power into a few lines of code. Here’s an example of a typical query and output process:

 

SELECT * FROM Products 

 

Product List

 

 

#ProductName# $#Price# 

 


Of course, there are all the usual programming constructs (setting and using variables, controlling flow with ifs and looping, user-defined functions and more).

CFML is more than just a language, however. It’s also a framework with support for application and session variables, flexible database access and connection pooling, query caching and more. At the same time, it’s also a high-level language incorporating features that, utilized on other platforms, might require incorporating additional libraries or other products. It’s been said that CFML makes easy things easy and difficult things possible.

CFML’s ease of use benefits not only new programmers but also coders responsible for maintaining someone else’s application. Whether you’re a CFML programmer or not, you can often readily tell what a CFML template is doing — it’s almost self-documenting.

While its tag-based nature makes CFML easier for non-programmers to pick up, some purists may argue that it’s an ineffective mechanism for programming. Many developers don’t find that it hampers their abilities at all. Still, the language has evolved to include an available CFSCRIPT tag to allow coding in a scripting approach based on ECMAScript (which is itself derived from JavaScript, though, in the case of CFSCRIPT, it’s entirely server-side processing).

Inside CFML’s Ease of Use
CFML’s ease of use can be a two-edged sword, though, as applications become more complex. It’s easy– and almost traditional — for CFML developers to just lump everything they need to do onto a single page.

As the example above shows, a query and its embedded SQL usually appear on the top of a page processing the query results. If the query page is the result of a form submission (such as a search page), it’s typical to also throw the input validation onto the top of that same page. Some even go so far as to put the form and its processing on the same page, testing at runtime to know whether to show or process the form.

These methods are familiar to CFML developers, and they reflect the very growth of applications that start out simple and soon encompass more and more functionality. CFML makes it easy to prototype an approach, and there are times when its simplicity also makes it ideal for getting applications out the door quickly. Still, the mix of business logic and display on a single page can have its drawbacks in larger and more sophisticated applications. And many don’t even think about the problem, because it’s always been standard procedure in CFML.

Indeed, to carry this scenario further, it’s easy for any developer (especially a junior one) to create an application (especially a complex one) that doesn’t perform well or won’t scale. That’s less often an indictment of the language than of the developer’s skills. (All those who’ve seen a JSP page run amok doing too much and mixing presentation and logic, raise your hands. In a moment, we’ll discuss the JSP 2.0 attempts to solve that.)

Fortunately, CFML is evolving to better support such segregation of presentation and content. But even so, the bigger challenge for many developers is recognizing when that sort of segregation is needed. Some may believe there’s a relative lack of software engineering maturity among CFML developers. Many have never heard of the Model-View-Controller paradigm, for instance, or are very new to it. Both CFMX and BlueDragon offer server-side redirection (forward processing), a key to implementing that, but many developers don’t take advantage of it. (It also wasn’t working well in CFMX until Update 3.)

One final argument in favor of CFML: For a shop that already has a large base of CFML code, there’s a lot to be said for the knowledge gained and the investment made in those applications. Migrating away from such apps is often quite an expensive effort. And, as we note later, you may want, rather than convert the apps, to explore integrating CFML with JSP applications.

But if you or your organization is set to proceed with JSP development anyway, or if you need some justification for wanting to hold off on it, let’s take a look at some of JSP’s challenges, as well as some recent changes in JSP development that influence this debate.

Some Challenges with JSPs
The first thing to consider? It won’t be a snap to move CFML dev talent over to JSPs. Sure, JSP itself is a rather limited language, and you don’t really have to understand Java in order to edit/create JSP templates, but you certainly won’t be able to do too much on a JSP without knowing Java.

The JSP approach’s primary goal was to make it easy for HTML coders to edit presentation pages, with the back-end processing (query processing, data validation, etc.) handled by a Java developer in a servlet or bean. Unfortunately, JSP developers are as unfamiliar as CF developers with the notion of segregating page processing into layers. They too start to do more in the JSP page than just presentation. The downside? If they begin to embed Java code (the scripting language for JSP) onto the page, it will no longer be as easy to understand, edit and debug.

Not only will a non-Java HTML coder will have difficulty with the page, but even a newbie Java developer and possibly an experienced developer will find it challenging.

This raises another JSP constraint: error reporting and handling. Because a JSP template is first parsed, then compiled and then finally run, there are lots of moving parts that could complicate the process of tracking down a problem’s source. Adding more Java code to a template only exacerbates the problem.

Even if JSP developers start to follow the best-practices recommendations of segregating their application into layers, they must then decide how to encapsulate the model, or indeed whether to go to EJBs at all. Next, there’s the question of whether and how to use servlets in addition to JSPs, such as for controllers, filters, etc. Add in the wide range of J2EE APIs available, and a JSP application can quickly grow into a very complex beast.

Most CFML developers are used to developing an application all by themselves. So more than just having to learn Java, they must become familiar with the process of segregating the application into layers. Again, CFML is evolving to support that notion, so it won’t remain foreign for long. But in the near term, it means that it takes a lot more to understand all the implications and choices available.

Why JSP 2.0 Resembles CFML
The relatively new JSP 2.0 spec really changes the landscape of JSP programming quite a bit. The new Expression Language (EL) makes referring to variables in JSP a lot more like referring to variables in ColdFusion (though they’re surrounded by $ rather than # signs).

Another point, the Standard Taglib (JSTL), organized by the Apache Jakarta project, introduces a new set of tags for setting and using variables, controlling flow with ifs and looping and performing queries with embedded SQL. This also resembles ColdFusion. Indeed, an argument could be made that JSP 2.0 is an admission of failure of the original JSP spec — and even that it’s struggling to become more like CFML.

Again, we’ve been on the right track all along. And even with all these so-called improvements, there’s more to creating a typical JSP/servlet application than just getting into JSP 2.0.

Assimilate or Integrate CFML
Whether yours is a JSP 1.x or 2.0 shop, or you’re considering an alternative templating language, what if you could keep your current CFML applications and then consider whether to convert any aspects to JSP and/or the rest of the J2EE suite of APIs?

With both CFMX Enterprise and BlueDragon Server JX, you can run JSPs and servlets alongside your CFML templates and can even natively integrate the two. You can share session and application variables between CFML templates and JSP/servlets, transfer control among them and “include” information among them, and more.

If you need to deploy your CFML applications on a J2EE server (such as WebSphere, WebLogic, SunONE and others), there are J2EE editions of both CFMX and BlueDragon. Both offer a mature, tag-based language equally suited to layered development or to simpler designs that may embed the model and the view at once. In other words, you can continue to leverage CFML as a valid alternative to a native J2EE web scripting language.

You have other options, as well, such as sticking with your CFML running on ColdFusion or BlueDragon Server and ignoring JSP/servlets. With BlueDragon, for instance, you can run your CFML apps alongside JSP/servlets, deciding at your own pace when (or whether) to migrate, or simply integrate those application. Indeed, it may be the first web application development language in the entire industry that’s compatible across such a wide range of server platforms. That’s the way to protect your investment in CFML.

After hearing all this, are you sure that you really want to move to JSP after all? Is it really clear what it will buy you? And, if it’s becoming more like CFML, is it worth all the pain and expense of converting your applications to JSP?

Chris Preimesberger is Senior Contributing Editor at DevX.com and a writer based in Silicon Valley. Charlie Arehart is Chief Technology Officer at New Atlanta Communications in Atlanta, Ga. and technical editor for ColdFusion Developers’ Journal.