For example, the following is WordPress’ default URL configuration for a post:

http://www.domain.com/?p=1635

However, buy using a URL-rewriting available in the Apache webserver, we can achieve a far better result, such as the following:

http://www.domain.com/search-engine-safe-urls

NB. It is also possible to achieve a similar result with an ISAPI rewrite for Microsoft’s IIS webserver, but this topic will not be included in this post.

To get your website working with SES URLs you need to enable both the mod_rewite module and AllowOverride directive in the Apache configuration file.

Uncomment (remove #) from the following to enable the re-write rule:

LoadModule rewrite_module modules/mod_rewrite.so

Change the AllowOverride directive from none to all

<directory />
    Options FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
</directory>
 
<directory "C:/WebRoot">
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.2/mod/core.html#options
    # for more information.
    #
    Options Indexes FollowSymLinks
 
    #
    # AllowOverride controls what directives may be placed in .htaccess files.
    # It can be "All", "None", or any combination of the keywords:
    #   Options FileInfo AuthConfig Limit
    #
    AllowOverride All
 
    #
    # Controls who can get stuff from this server.
    #
    Order allow,deny
    Allow from all
</directory>

On Apache webservers, .htaccess (hypertext access) is the default name of directory-level configuration files. An .htaccess file is placed in a particular directory, and the directives in the .htaccess file apply to that directory, and all its subdirectories. It provides the ability to customize configuration for requests to the particular directory. In our case, enabling search engine safe (SES) URLs.

By setting the AllowOverride directive to All in effect defers configuration settings to the .htaccess file.

An example .htaccess file could include the following code to rewrite the URLs:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,QSA]

Search engine friendly URLs are implemented with Rewrite engines. The rewrite engine modifies the URL based upon a number of rewrite conditions and rules.

The RewriteBase directive explicitly sets the base URL for per-directory rewrites. The RewriteCond directive defines a rule condition, so in this case handling missing files or directories. Finally, the RewriteRule directive is the real rewriting workhorse. In this example, we’re getting everything in the URI — i.e. not including the protocol (HTTP/S) and domain name — based upon a regular expression. This is then appended to the default file reference — index.php — as a back reference. The [L,QSA] refers to the rule being the last rule and append any query string parameters to the default file. It is important to note that this is all done on the server side, the user will never see the website address changing in the browser’s address bar. Furthermore, simply transposing the index.php filename with your default file name — e.g. index.cfm, default.aspx — will have the same result. Indeed, the above rewrite rules are becoming a de-facto standard for web applications.

To fully understand mod_rewrite rules above, look at the Apache mod_rewrite documentation.

Once you have your SES functionality in place on the webserver, it is then the responsibility of your application framework to understand the URL construction and handle it accordingly. Fortunately, frameworks such as ColdBox and Fusebox for ColdFusion, Zend and Symfony for PHP, all contain functionality to do this, but that is the subject of an entirely different post.

Users of web applications prefer short, neat URLs to raw query string parameters. A concise URL is easy to remember, and less time-consuming to type in. If the URL can be made to relate clearly to the content of the page, then errors are not only less likely to happen, but our good friends the search engine robots are able to draw a stronger assumption of the pages’ relevance and content.

But the landscape is changing and the UK is challenging for its share of the scene. 2008 is seeing a renaissance in the ColdFusion world following on from the buzz created around the release of ColdFusion 8 in 2007 and the eagerly anticipated future release of ColdFusion, codenamed Centaur. This buzz has resulted in not one but three conferences for 2008: CFUnited Europe was held in London in March, Scotch-on-the-Rocks was held in Edinburgh in June and soon we will see the return of CFDevCon.

The inaugural CFDevCon one-day-conference was held back in 2006, in Croydon, but in September 2008 it is heading down to what is arguably one of the creative capitals in the south of England, Brighton. The conference has not only become a two-day conference, but its scope has moved beyond simply Adobe-based products, with the introduction of Microsoft-based technologies, specifically IIS7.0, Silverlight and SQL Server 2008 and technology-agnostic topics such as Regular Expressions, Search Engine Optimisation (SEO) and Accessibility.

As with all great conferences, CFDevCon has a great line-up of speakers with the likes of Sean Corfield, Hal Helms, Peter Elst, Peter Bell, Aral Balkan and Simon Bailey, to name a few, all presenting sessions.

So, lets get excited people, support the conferences and user groups and evangelise ColdFusion.

Fortunately for me, a colleague, Iain Turbitt, decided to spend an evening after work developing two custom verbs to implement these two ColdFusion tags within the Fusebox framework. You can grab the two files by clicking on the following link:

Download Fusebox 5 Custom Dump and Abort Verbs

The Dump verb behaviour is similar to the <cfdump> tag: <dump var =”"/> but includes an optional abort attribute e.g.:

<dump var=”" abort =”true|false”/>.

The Abort verb behaves as per the <cfabort> tag, i.e. <abort/>.

Frameworks can help promote good development practices, standards, and a sound foundation for creating an application.

In this article I list a number of these frameworks, but I will leave you to compare them, and decide which you may want to adopt.

Fusebox

An Historically Strong Framework

Fusebox is a popular framework for building ColdFusion and PHP web applications. “Fuseboxers” find that the framework releases them from much of the drudgery of writing applications and enables them to focus their efforts on creating great, customer-focused software.

Fusebox provides a small set of ‘core’ files and large amount of structure which is helpful to developers. It emphasizes separation of presentation from logic and uses a readily understandable vocabulary for modeling websites, namely circuits, fuses and switches.

http://www.fusebox.org

Mach-II

Mach II is a web-application framework developed by Hal Helms and Ben Edwards that evolved out of a desire to create a framework that specifically addressed maintenance issues using an OO style. Mach II is based on an Implicit Invocation Architecture and directly supports the MVC design pattern.

http://www.mach-ii.com

Model-Glue

Model-Glue helps you build Object-Oriented ColdFusion applications based on the Model View Controller pattern. It’s designed to be easy to use and play well with others, like Tartan.

http://www.model-glue.com

onTap

The onTap framework is an Open Source Framework for quickly developing powerful web applications using Adobe’s ColdFusion application server. The framework itself bears a marked resemblance to the recently buzzy Ruby on Rails.

http://www.fusiontap.com

TheHUB

TheHUB, like other application development frameworks, utilizes the notion of a central hub template that all requests for the application pass through. That cental hub is the point or place within the application that the processing of all code hinges upon. The code simply checks for a query string and then reads the parameters passed to handle template loading and screen rendering.

http://www.codesweeper.com

Tartan

Tartan is a command-driven service framework for ColdFusion. It was built to help produce the service layer within a larger application architecture which relies on strict separation or layering of functionality.

All access to the underlying business logic is controlled by public services which are available locally as CFCs and remotly via Flash Remoting and SOAP web services. A service can be composed of any number of commands, each of which implements a discreet operation within the application. These contain the core logic for the application. Commands can communicate with databases via DAOs, manipulate values received from the client, execute other commands and even communicate with services available on other remote servers.

At the center of Tartan are 6 Core classes : LocalServiceProxy, LocalService, Command, DAO, ValueObject and ExceptionHandler. They provide most of the functionality of the framework, and must be extended by the application developer.

http://www.tartanframework.org

ColdSpring

ColdSpring is a framework for CFCs (ColdFusion Components).

ColdSpring’s core focus is to make the configuration and dependencies of your CFCs easier to manage. ColdSpring uses the “inversion-of-control” pattern to “wire” your CFCs together. Inversion-of-control provides many advantages over traditional approaches to assembling your application’s model. Also part of ColdSpring is the first Aspect-Oriented-Programming (AOP) framework for CFCs.

http://www.coldspringframework.org

UPDATE: Since creating this blog post many years ago, two more frameworks have been released that require an honourable mention.

ColdBox

My New Framework of Choice

ColdBox is an event-driven conventions based ColdFusion Framework. It provides you with a set of reusable code and tools that you can use to increase your productivity, and it provides you with a development standard when working in a team environment. It makes use of an MVC (Model View Controller) design pattern and an extensive array of patterns for its operations such as Factories, Helpers, Workers, etc. And since it is based on CFCs it does not rely on an XML dialect.

NB. ColdBox also takes advantage of ColdSpring or Lightwire.

http://www.coldboxframework.com

Lightwire

Lightwire is a very lightweight Direct Injection (DI)/Inversion of Control (IoC) engine for directly injecting dependencies into singletons and transient business object. The framework is optimised to create transient objects as well as singletons and allows for programmatic as well as XML configuration. It is the lightweight framework for people who’d like to put more logic in their beans and less in their service layer.

http://lightwire.riaforge.org

This Fusedocs file contains the Fusedoc DTD, an example ColdFusion page and documentation on the Fusedoc methodology.

Check out her website at http://www.shayna.com

http://www.halhelms.com/code/resources/Fusedoc.zip

Application frameworks answer this question, offering pre-built (and pre-tested) code — a collection of services that can provide the architectural underpinnings for a particular type of application. Web-based applications are increasingly the choice for new application development in which the browser becomes the “universal client”. As web development matures, web-based application frameworks allow the developer to concentrate more on meeting the business needs of the application and less on the “plumbing” needed to make that application work.

Fusebox is, by far, the most popular and mature web framework available for ColdFusion and PHP developers. The architecture of a Fusebox application is divided into various sections (“circuits” in Fusebox parlance), each of which has a particular focus. For example, the responsiblity for ensuring that only authorized users have access to all or part of the application might fall under a Security circuit.

The Fusebox application architect defines these circuits, as well as the individual actions (“fuseactions”) that may be requested of it. When a fuseaction request is made of the application, the Fusebox machinery (the “Fusebox”) routes the request to the appropriate circuit, where the fuseaction is processed. This idea of encapsulation of responsibilities makes it easy for different functional circuits to be “plugged” into an application, making it possible to reuse code.

Within the individual circuit responsible for carrying out the requested fuseaction, the Fusebox architect specifies the individual files (“fuses”) needed to fulfill the fuseaction request. Thus, the Fusebox acts like a good manager, delegating tasks to appropriate departments where it is decomposed into individual tasks, each of which can be assigned to individuals to carry out.