For many web developers, whenever JavaScript is mentioned it provokes a rye smile; JavaScript is one of those programming languages that is rather avoided than embraced. This is not the fault of the language itself, but rather the browsers. A few years ago, the landscape of client-side scripting was a bleak scene. Browser inconsistencies, particularly with the dominant Internet Explorer, implementation bugs and numerous target platforms made developing client-side JavaScript a tricky undertaking.

To the consternation of these same developers, the landscape changed and Web 2.0 hit the mainstream. Almost overnight, every website on the internet wanted to use or was using AJAX. Marketers joined the bandwaggon and every feature requested had to involve something dynamic and revolutionary. Thus JavaScript development quickly hit the forefront of peoples minds and became as important as any server-side technology available at the time.

Over the next few blog posts, I will be using the popular frameworks jQuery, Yahoo! User Interface Library (YUI), ExtJS and Adobe’s Spry with ColdFusion to demonstrate various techniques, such as autocomplete and form validation.

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

The onTap Framework can be downloaded at the following url:

http://www.fergusonhouse.com/?netaction=download

Application developers face a daunting task: they must translate the often fuzzily-defined requirements for a new application into the rigid language of computers. While the Fusebox Lifecycle Process (FLiP) offers help in managing the project management aspects of creating a new application, what help is there available to developers approaching the technical challenges of creating and maintaining applications?

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.

Mach-II is a web-application framework focused on easing software development and maintenance developed by Hal Helms and Ben Edwards.

http://www.mach-ii.com

Model-Glue is:

• An Implicit Invocation framework simplifying use of the Model View Controller design pattern in ColdFusion applications. It’s designed to be easy to use and play well with others, like Tartan.
• Released under the Lesser GPL, meaning that it’s free to download, use, and alter.
• A framework encouraging clear seperation of Model, View, and Controller
• Lightweight enough to play well with others: it comes with out-of-the-box connectors to Paul Kenney’s Tartan Framework.
• Akin to Mach-II, another II, MVC framework, but with slightly simpler functionality, and more clearly defined boundaries between Model and Controller.
• Written by Joe Rinehart, a quasi-popular ColdFusion blogger with an interest in developing better OO applications in ColdFusion, with constant feedback provided by Doug Hughes of Alagad, Inc.

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.

The concept is that each request passes a unique set of keys that relate one-to-one with a site or application directory and template within the named directory. In applications and websites that utilize TheHUB, the query string looks like “?dsp=the_hub…”. This indicates to the “framework hub” template… the “index.cfm” that it should include the “the_hub.cfm” template from the “dsp” directory.

Download the code at this url http://www.codesweeper.com/index.cfm?code=main

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 remotely 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.

Overview and Explanation

The driving need behind Tartan was a production application that needed to transfer data between 5 different databases and 3 different applications. There was a complex set of DAO classes and a faade class that provided access. Each fa ade class had a single public method called “execute” that would simply take arguments and return a result.

This concept worked well, but obviously had its limitations. So Tartan was created to be able to quickly and easily add new commands to services, and new services to the system.

Tartan is described as a “command-driven service framework.” What does that mean? In this context a “service” is a set of commands that have commonality, and a “command” is a method that executes any number of other methods and returns a result. It’s that simple. A service such as “televisionViewer” could include a command such as “getListings” which would, based on locality data provided either by a config file or a method argument, check local listings and return a collection of data regarding current television listings.

To further explain the concept of “commands,” we could offer that method a second argument such as “returnType” and return the listings as an array of structures, a CF query object, or an XML file. By adding commands from granular to broad, we can incorporate them into sequences. For instance, if we wanted to offer the findMyShow command, we could have it first execute getListings, then parse the resulting data and determine if our show is on soon or not.

By doing this carefully and with some planning, we develop a very simple interface between our application and any persistant storage mechanism and/or business objects, with the ability to filter, alter, or convert our results before they’re returned to the caller. If we start with granular and move to broad commands, we maintain the flexibility and encapsulation of an OO design, but gain the convenience and natural-thinking appeal of procedural programming.