Let’s not Dilly-Dally: ColdFusion has its Merits

Friday, 9th January 2009 in Development by Simon | 11 comments

ColdFusion is 13 years old. That make makes it the daddy of the web world! It does not make it any less hip or useful than the relatively new kids on the block.

Take this scenario. A company I once worked for had what can be described as a business directory built upon a licensed, yet bastardised, version of a popular ColdFusion-based CMS. It didn’t work that well! The decision was made to redevelop the application in Java. It took two years to reach the same level of functionality! What happened next? Ruby-on-Rails is what! The rest is history and beyond the topic of this post.

So, in effect, the application almost went full-circle in its development paradigm — both ColdFusion and Ruby-on-Rails can be considered Rapid Application Development environments, Java, certainly not. Why did the decision makers not stick with ColdFusion and put time aside to actually build it properly in the first place? To put it simply, they lost faith in ColdFusion; it was largely mis-understood.

The weakness of every programming language does not lie with the language itself per se — albeit it can have an important influencing factor — but rather with the ability, or indeed inability, of the developer to leverage the language in the most efficient and optimal way.

ColdFusion, like every other programming language has had and I’m sure still does have its fair share of poor developers; those people simply working with it as a means-to-an-end, rather than those passionate about the language, those people programming without understanding the fundamentals of programming or the implications of their poorly written code. This is apparent from .NET to Java, ColdFusion to Ruby, JavaScript to ActionScript.

Let’s not dilly-dally, bicker or insult one another about which is best, which one is dying and which one is not worth the computer it is compiled on. What is important is to understand the merits of each language and decide which one best suits the application, not only in technical terms, but also in terms of time-to-market, cost of development, availability of a skilled workforce etc.

ColdFusion, whether rightly or wrongly in some people’s opinion, can sit proudly amongst its peers and provide a truly compelling alternative.

Here’s how (in no particular order):

  1. Low Total Cost of Ownership – frequently, ColdFusion is described as expensive, it simply isn’t especially if you consider the natively supported functions. But to put it bluntly, if your company cannot afford the cost of ColdFusion standard, or indeed ColdFusion hosting, you have bigger things to worry about regarding the profitability of the company; you won’t be able to afford much of anything! The problem becomes not the product. ColdFusion applications are quicker to develop and developers are vastly cheaper to employ than their peers in Java or Ruby, just look at ITJobsWatch for examples.
  2. Rapid Application Development – ColdFusion vastly simplifies tasks. What would take other languages numerous lines of code to produce is efficiently encapsulated either in a tag or function or as a setting in the administrator. This is a simplistic yet indicative example: where else can you connected to a database simply with one line of code or indeed simply by name? ColdFusion changed the idea of specifying development time in terms of months and years to weeks and months or small features a matter of hours and days. Simplicity is not the mother or all evil. To be pragmatic, simplification reduces costs.
  3. Rich Internet Applications – ColdFusion may or may not have pioneered the RIA paradigm, but it has played a significant supporting role to Flash and now Flex. ColdFusion natively supports Flash remoting, providing the all important data access tier.
  4. Platform Maturity – ColdFusion 8 is built upon the latest version of Java (1.6). Along with internal improvements to the ColdFusion application, this has afforded ColdFusion unprecedented speed improvements and stability.
  5. Language Maturity – with each major release of ColdFusion comes many language enhancements added to the core. This means that previous addons, for example image manipulation, which came at a premium are now standard. Adobe and other companies that produce CFML engines are now participating in a CFML advisory committee, which aims to set standards for the core language. This is not only a sign of maturity but a letter of intent by the industry that will mean your application will work on any engine, assuming no proprietary functionality is used.
  6. The Ultimate Middleware – ColdFusion sits comfortably between any backend and front end system. Be it interfacing with a host of databases, Java, .NET, COM, Corba or connecting to classic HTML or rich Flash, Flex and AJAX frontends with little or no configuration.
  7. Feature Rich – what other web technology natively supports PDF generation, charting, enterprise-level search, AJAX, image manipulation, Atom and RSS creation, Zip and JAR file manipulation, a server monitor, Flex integration, encryption libraries, all important database connectors, webservice creation, XML manipulation, inbuilt reporting application (similar to Crystal Reports), email, FTP to name but a few? I hazard a guess at none, unless you’re happy to pay a premium.
  8. Platform Independent – since ColdFusion 6, when Macromedia redeveloped the entire application in Java, ColdFusion has been platform independent. You can install it on practically any machine.
  9. OpenSource Alternatives – BlueDragon and Railo are both significant alternatives to Adobe ColdFusion and both have opensource alternatives, the latter of the two having recently joined the JBoss community. Adobe are also considering providing a free edition to academic institutions.
  10. The Future – many commentators have mentioned Hibernate as a significant addition to the next release of ColdFusion, version 9. But having seen the prerelease notes, that is not all that will be added. Alas I’m under NDA, but rest assured, there is going to be a significant intake of breath when developers get hold of the next release. ColdFusion 8 was firmly geared towards middle management with fuzzy additions, ColdFusion 9 is set to re-address the balance with compelling language and functionality enhancements.

ColdFusion evangelism needs to step up a gear! Adobe certainly doesn’t afford much marketing budget to the product, prefering The Community do the hard work. It is not always easy convincing the decision makers that ColdFusion is a good product of choice, without Adobe’s unnerving support, but we have to work hard, break down those barriers, encroach on events outside the comfortable sphere of the ColdFusion world and demonstrate ColdFusion’s match-winning ability.

ColdFusion isn’t dying, it’s simply niche. Every niche has its place.

UPDATE: If you would like to view the ensuing debate regarding ColdFusion prompted by Aral Balkan, feel free to do so. This post should serve as a positive reminder of ColdFusion’s virtues, alongside the need for a balanced and polite debate.

Application-Based Paths in ColdFusion

Friday, 14th March 2008 in Development by Simon | 1 comment

The THIS scope in the Application.cfc contains several built-in variables that allow you to set the properties of the application; the name, session management etc. With the release ColdFusion 8 comes the introduction of application-based pathing in the form of the THIS.mappings and THIS.customTagPaths variables.

The THIS.mappings variable can specify a structure that contains ColdFusion mappings. These settings take precedence over the mappings defined by ColdFusion Administrator Server Settings > Mappings page for the current application. Each structure element consists of the logical path as the key and the absolute path as the value. To use this variable, you must set the Enable Per Application Settings option on the ColdFusion Administrator Server Settings > Settings page.

For example:

<cfset THIS.mappings['/com'] = "C:\Inetpub\com" />

This is syntactically equivalent to using the structInsert() function:

<cfset structInsert(THIS.mappings, '/com', 'C:\Inetpub\com') />

The THIS.customTagPaths variable can specify a list that contains ColdFusion custom tag paths. These settings take precedence over the custom tag paths defined by the ColdFusion Administrator Server Settings > Mappings page for the current application. To use this variable, you must set the Enable Per Application Settings option on the ColdFusion Administrator Server Settings > Settings page.

For example:

<cfset THIS.customTagPaths = "C:\Inetpub\wwwroot\myAppOne\customTags" />

Since we can specify a list, this is also valid:

<cfset THIS.customTagPaths = "C:\Inetpub\wwwroot\myAppOne\customTags,C:\Inetpub\wwwroot\myAppTwo\customTags" />

Alternatively, we could represent the list as:

<cfset THIS.customTagPaths = "C:\Inetpub\wwwroot\myAppOne\customTags" />
<cfset THIS.customTagPaths = listAppend(THIS.customTagPaths, "C:\Inetpub\wwwroot\myAppTwo\customTags" />

For a long time, ColdFusion developers have needed the ability to define application-level settings actually in the application itself. These two new application-based pathing variables bring the ColdFusion developer a step closer to being able to produce out-of-the-box applications that can install in shared environments with little fuss and, more importantly, without the need to access the ColdFusion Adminsitrator to create the necessary mappings and custom tag paths.

PHP.ini Permission Problems on Windows Vista

Sunday, 17th February 2008 in Development by Simon | 4 comments

Installing PHP is a relatively simple task one would think. Indeed it is simple, but configuring the php.ini isn’t; at least not so on Windows Vista! It is infuriating when such a relatively simple task is made inordinately complicated because of the nuances of Vista permissions. What started out as a 5 minute task took a significant number of hours searching for a suitable answer on Google, and not only by myself.

The task I was trying to achieve was the installation of development versions of WordPress, Drupal, MediaWiki and Moodle, all of which would require a MySQL database. Trying to load the MySQL extension should have been a simple case of uncommenting the line in the php.ini and restarting the Apache service. With Vista, this was certainly not the case.

I set up a very simple page detailing the php configuration in an index.php file:

< ?php phpinfo(); ?>

This showed me the default configuration path of my php.ini and extensions directory, amongst a whole host of other information.

In both cases the paths were incorrect. First and foremost the configuration file path stated C:\Windows when in fact I had installed it in the root (C:\PHP5). So, although I was amending the php.ini file with the correct detail, Vista was using the default values. If there is no php.ini file in Windows, then you’ll continue banging your head against a brick wall.

The problems didn’t stop there. Moving the php.ini file to the Windows directory under Vista isn’t a simple copy and paste task. You need to be administrator. But Vista’s administrator priviledges are more pseudo than actual! In order to amend and save the php.ini file in the Windows directory, you must run Notepad as administrator and save the file as such. Voila! Everything then works. The phpinfo() function returned the correct installation detail and I could continue with the job I was meant to be doing.

PS. Thanks to Rob Douglas for his help.

Configuring PHP with Apache on Windows Vista

Friday, 15th February 2008 in Development by Simon | 46 comments

Pre-requisites:

  1. Follow my instructions on installing Apache on Windows Vista
  2. And then follow my instructions on installing PHP on Windows Vista

Installing PHP with Apache on Windows Vista is a relatively simple task until you try an configure the settings in php.ini. Problems can occur and stem from the fact that when you install PHP and edit the php.ini file, you need to not only be logged in as Administrator, but run the installer and Notepad text editor as Administrator. The php.ini file also needs to be located in the Windows directory.

Below is an outline of the steps to get your PHP installation running and configured correctly.

  1. Run Notepad as Administrator. Go to All Programs > Accessories Right-click “Notepad” and select “Run as Administrator”. Open the php.ini file, in my case: 
    C:\PHP5\php.ini
  2. Edit the php.ini file as necessary, e.g.: 
    extension_dir = "C:\PHP5\ext"
upload_max_filesize = 16M
upload_tmp_dir = "C:\PHP5\upload"
session.save_path = "C:\PHP5\session"
  3. Enable the extensions you need by deleting the semi-colon at the beginning of the line. For example, you will commonly need the following MySQL extensions: 
    extension = php_mysql.dll
extension = php_mysqli.dll
  4. Save the edited php.ini file into your Windows directory. This is very important as Vista will not read the changes but will refer to the default settings.
  5. Check that the PHP directory has been added to your computers “Environment Variables”. Click Start, right-click on Computer, select Properties > Advanced > Environment Variables. Click on PATH and select Edit. If the PHP path is there, in my case “C:\PHP5\”, all is well, otherwise add the PHP path.
    • System Properties:

      Vista System Properties

    • Environmental Variables

      Vista Environment Variables

    • Edit Environmental Variable – PATH

      Vista Edit Environmental Variable PATH

  6. Open your Apache configuration file (httpd.conf). Ensure the following lines are present (at the bottom of the file): 
    LoadModule php5_module "C:\PHP5\php5apache2_2.dll"
AddType application/x-httpd-php .php
AcceptPathInfo on
PHPIniDir "C:\Windows"

    If there are additional LoadModule lines, remove them, leaving only the one that relates to your version of Apache.

  7. Find the DirectoryIndex in the Apache config and append index.php, e.g.: 
    <ifmodule dir_module>
	DirectoryIndex index.html index.php
</ifmodule>
  8. Restart the Apache service.
  9. Create a index.php file in your webroot and add the following lines: 
    < ?php phpinfo(); ?>
  10. Navigate to the file (e.g. http://localhost/index.php) and you will be presented with all the PHP and server settings. You’re now good to go.

Configuring ColdFusion 8 with Apache

Friday, 16th November 2007 in Development by Simon | 4 comments

After installing ColdFusion 8 and Apache successfully you may still see an “HTTP 500 Internal Server Error” when navigating to a ColdFusion page. All is not lost, you simply need to configure, or check the configuration of Apache.

Apache requires very little post installation modification, but it is always good practice to check the httpd.conf file to ensure that the ColdFusion “install” scripts did what they were supposed to do.

If you haven’t confirmed that Apache is running, open your browser and point it to http://localhost/ (unless you specified a real URL during installation). You should see the Apache test page. If you see an error, review the Apache installation steps to make sure you followed all the steps correctly, and/or check your log files for more detailed errors.

Now we know Apache is running, but how about ColdFusion? Point your browser to the ColdFusion Administrator found commonly at http://localhost/CFIDE/administrator/index.cfm and see what happens. One of three possible failures could occur:

  1. Your browser prompts you to save the .cfm file to your computer. There a couple of possible resolutions to this. Firstly restart the Apache service. If this does not resolve the issue you will need to check the httpd.conf file to ensure that the ColdFusion module is being loaded. The file can typically be found in the C:\Program Files\Apache Software Foundation\Apache2.2\conf\ directory.
    Make sure that the DirectoryIndex has a reference to the index.cfm file (i.e. the default file):Apache dir_module DeclarationEnsure that the LoadModule jrun_module "C:/ColdFusion8/runtime/lib/wsconfig/1/mod_jrun22.so" is also present:

    Apache JRun Settings

    If you need to edit this file, restart the Apache service after you have saved the changes.

  2. You get a message that the CFIDE folder cannot be found. This is more likely to be a problem with where you placed the ColdFusion application during install. The default location is in the Apache directory (C:\Program Files\Apache Software Foundation\Apache2.2\htdocs), so check in the http.conf file to ensure the DocumentRoot is pointing correctly. Alternatively, copy this folder to your localhost webroot (e.g. C:\WebRoot) ensuring that the DocumentRoot points to your webroot (see the yellow box in the second screen-shot).
  3. You get another message which probably means that you need to reinstall ColdFusion, and/or Apache!

And that is it, you can start using ColdFusion and developing applications.