Classes and Interfaces with ColdFusion

information NOTIFICATION: These examples are provided for educational purposes. The use of this code and/or information is under your own responsibility and risk. The information and/or code is given ‘as is’. I do not take responsibilities of how they are used.

I noticed that there is very little talk about patterns and ColdFusion so I decided to talk a little.

First allow me to clarify that patterns are not solid rules, they are just suggestions on how to deal with common problems. You can combine different patterns as well to modify a pattern to fit your needs.

For the purpose of this lesson, lets assume that you are working for a company that develop pet simulators; also, lets assume that you work in a team together with many developers.

You company  wish to create a dog simulator which allows us show different type of dogs and dog species.
Originally, we could have use standard Object Oriented techniques and created on Dog super-class from which each dog species inherit the basic functions:


In ColdFusion, your code would similar to the following (I am only writing the super-class and sub-classes):

File Dog.cfc:

<!--- Dog.cfc --->
<cfcomponent name="Dog">

   <cffunction name="bark">
      <!--- Your code --->

   <cffunction name="run">
      <!--- Your code --->



<!--- ChihuahuaDog.cfc --->
<cfcomponent name="ChihuahuaDog" extends="Dog">

   <cffunction name="display">
      <!--- Your code --->


Now this is a super-class and subclasses as an example that the rest of programmers are going to be adding different species of dogs.

Out of the blue, one of the managers come with the idea to add a new functionality: jump();
So you say to yourself that you only need to add a jump method to the Dog class then all the different dogs will inherit this function.


memRinI0R28fdg0PgIhAnSgEverything goes well until until one of the managers approach you in a very aggressive matter. This manager is angry at you because when presenting the demo of the software he finish doing a fool of himself. The reason was that someone requested to add a ceramic dog. When the manager was presenting the software, ceramic dogs where jumping everywhere when they are not supposed to be able to jump in the first place! In order work, when you added the extra function, you were adding a behavior that should be applied to some sub-classes.


So you think that you could just override the jump() method in in the ToyDog subclass that way you don’t have to worry about it.

UMLClassDogDiagram3(1) toydogHowever, the ceramic dog cannot bark nor run either. So you do the same as you did with the jump() function. Later on, someone decided that they need to add a toy dog which cannot run, but it can bark, jump, and grow its eyes! You are starting to realize that in any moment someone may decided to add some type of dog that you were not thinking that could exist. Perhaps using inheritance was not great idea after all!


So following the previous idea would result in a maintenance nightmare. The more type and species your company keeps adding, the more maintenance is required; therefore, a new idea shows up in your head: “How about using interfaces?”

Think about interfaces as an standard that when establish everyone must follow.
A construction, for example, follow different standards and many constructions are different one from the other with different requirements. For some things, they may share similarities, but for others, they can be different. While many constructions may share the fact that they use cement for their base, the wall could be build from a different material which must follow an establish standard.
If this example doesn’t help you, please leave a comment and I will try to come up with something else.


By using interfaces, you could take out those functions such as bark(), run() and jump() that may not we usable and leave those functions that will be use the more sure. In that way when a dog is supposed to jump, then you can implement the interface and have have the jump method.


Think that interface allow you do define behaviors for your classes.

In ColdFusion, we can use interfaces, for example:

The following is the InterfaceBarking.cfc file:

<cfinterface name="InterfaceBarking"   hint="Defines the a barking interface for a dog.">

         hint="Allows the dog to bark.">   


Now the ChihuahuaDog.cfc may look like the follow:

<!--- ChihuahuaDog.cfc --->
<cfcomponent name="ChihuahuaDog" extends="Dog" Implements="InterfaceBarking">

   <cffunction name="display">
      <!--- Your code --->

   <cffunction name="bark">
       <!--- Your code --->

Extends points to the parent class (super-class) and Implements points to the interface


At this point is good to introduce a design principle so we can remember in the future:

lightbulbFirst identify which aspect of the program may vary and separate them from the rest that will stay the same.

In other words, in order to not affect the rest of your code, take those components that variate and encapsulate them. In this way, you don’t produce unpredicted behaviors. Also, this introduce us to another design principle:

lightbulb Do not program the implementation but the interface instead.

 information NOTIFICATION: This is a draft and I will be keep working on it.







Leave a comment

ColdFusion : Error Handling – Part 1

NOTIFICATION: These examples are provided for educational purposes. Using this code is under your own responsibility and risk. The code is given ‘as is’. I do not take responsibilities of how they are used.

Errors are unforseen. They are a result produced by coding and they are unplanned and/or unanticipated by the developer.
However, we can manage these errors and used them to our advantage.

Errors are handle by the server is the following fashion:

  1. The first level are the system errors.
    System error are generated when some components are not working properly.
    For example, if your application requires access to a database and this database is at a server which is down, then this could generate your application to fail.
  2. The second level are the code level errors. These errors (or exceptions) include logic, syntax and other type of errors that we will see later
  3. The third level of errors are at the application level
  4. The last level of errors are at the server level.

Error Flow Diagram:

Figure 1
Figure 1

As you may notice from the figure 1, we have a classification for all the errors that can be generated:

  1. Logic: These kind of errors are generated from some fault in the design of the code.
    For example, you could have an infinite loop:

    <CFSET counter = 0>
    <CFLOOP CONDITION='counter GTE 10'>
            Counter: #counter# <BR/>

    This loop will work while the counter is not greater or equal (GTE) to 10.
    The problem is that there is no part of this code that increases the counter.
    Since the variable counter is always 0, the loop is considerate infinite and can affect the server

  2. Syntax: These errors are related with misspelling, invalid data types, invalid parameters, and everything related with the language syntax. This kind of errors are caught on the application server and server level.
    For example:

    <CFOUTPUT QUERY='yourQuery'>
        <CFOUTPUT>Count of Records: #yourQuery.recordCount# <BR/></CFOUTPUT>
        <CFOUTPUT>#yourQuery.nonExistentField# <BR/></CFOUTPUT>

    The second like is going to work; however, the third line is asking for a field that doesn’t exist in myQuery structure.
    Another Example:

    <CFOUTPUT QUERY='yourQuery'>
        <CFOUTPUT>Count of Records: #yourQuery.recordCount# <BR/><CFOUTPUT>

    Here you are forgetting to close both CFOUTPUTs.

  3. Runtime: These are unforseen conditions such as data type mismatches, out of scope issues, server-side form validation errors, etc.
    For example:

    <CFPARAM NAME='user_age' default='My name is Alejandro'>
    <CFPARAM NAME='legal_driving_age' default=21>
    <CFIF Int(user_age) GT legal_driving_age>
        <CFOUTPUT>This user can apply for a regular driving licence</CFOUTPUT>
        <CFOUTPUT>This user cannot apply for a regular driving licence.</CFOUTPUT>

    This example fail on: <CFIF Int(user_age) GT legal_driving_age>
    Because user_age is a string without numbers while the function Int() is expecting a string with number.
    Since Int() cannot convert the string, a runtime error will be generated.

    There are three way to caught these exceptions which we would see later:

    1. Via code-level
    2. Via application-level
    3. Via server-level
  4. Validation: We can see validation errors as of the runtime errors that we are going to have to deal with.
    This kind of erros happens when Coldfusion server-side form catches a problem with the submitted data.

    <FORM ACTION='process.cfm' METHOD='POST'>
        <INPUT TYPE='text' NAME='age_integer' value='only text, no integers here'>
        <INPUT TYPE='submit' value='Submit' />

    You may ask: where is the error here?
    Well, in coldfusion we can do integer validation of the input by adding “_integer” to the name of the input field.
    In this case, “age_integer” means that we have a input name “age” which should be validated for integers.
    Since the value is “only text, no integers here” which is pure string, this will fail the validation. 
    For more information you can go to the following link:

    Lets clarify that these kind of errors can only be caught via error handlers at the aplication-level.

  5. System: Errors related with the system are always about inaccessible databases, unavailable resources, incorrect or invalidly configured servers, and file system errors such as lack of permissions.
    For example:

    <CFINCLUDE TEMPLATE='non_existent_file.cfm'>

    These errors can be caught:

    1. Via code-level handlers
    2. Via applicatoin-level handlers
    3. Via server-level handlers
  6.  Request: These errors occurs when the client request for invalid resources not available from the server side.
    Example:Such errors can be caught via server-wide error handlers.
Leave a comment

ColdFusion Tutorial – Part 1

(ColdFusion Tutorial – Part 2) Next >

NOTIFICATION: These notes are published for educational purposes. Using these notes is under your own responsibility and risk. These notes are given ‘as is’. I do not take responsibilities for how you use them.

ColdFusion is a programming environment which allow for the creation of server-side web applications, very similar to technologies such as ASP and PHP. ColdFusion allows the integration of many technologies such as web services, Java, XML, and more.

ColdFusion works on top of many web servers such as Apache and Microsoft Internet Information Services (IIS). Here is the link which display the different requirements for the installation of ColdFusion in your computer:

ColdFusion use ColdFusion Markup Language scripting language which made appearance in 1995. The designed was Jeremy Allaire and was developed by Adobe System, Railo, and New Atlanta. ColdFusion Markup Language works also for BlueDragon and Railo. This scripting language follows the guidance of the CFML Advisory Committee formed by Adobe in June 18 of 2009.

A ColdFusion application written by the programmer must follow a set of rules called syntax. This syntax is then interpreted by ColdFusion Server. In this case, this syntax is called ColdFusion Markup Language (CFML). ColdFusion Markup Language (CFML) allows the production of web applications by providing a scripting language similar to HTML and XML allowing for conditional operators, queries to databases, read and write files operations, loops, bulk emails, high-level formatting functions, database administration throw commands and other elements. By using CFML tags (tags which are only recognized by ColdFusion server), we can obtain a web application that runs in any browser like any regular website would do.

The way this syntax works is by using several tags. These tags normally go in pair, an opening tag and a closing tag; however, there are cases in which is one tag without a closing tag. CFML tags can also contain attributes. Here is an example:

<tagname attribute = “value”>

<anothertagname attribute='value'>

Code/text that is affected by the surrounding tags.


Let’s see example using actual CFML syntax:

<cfset firstVariable = 123>

<cfset secondVariable = 321>

<cfset sumVariables = firstVariable + secondVariables>

First variable: <cfoutput>#firstVariable#</cfoutput> <br/>

Second Variable: <cfoutput>#secondVariable#</cfoutput> <br/>

Sum of both varaibles: <cfoutput>#sumVariables#</cfoutput> <br/>


Let’s analyze the previous scripting code:

<cfset firstVariable = 123>

<cfset secondVariable = 321>

The tag cfset allows the creation of a variable and also the assignment of a value to this variable. In this case we are creating two variables, firstVariable and secondVariable), and we are assigning values to both of them (firstVariable with 123 and secondVariable with 321).

The third tag is also a cfset as previous tags; however, in this tag we are creating a new variable, sumVariables, and assigning a value which is a mathematical operation:

<cfset sumVariables = firstVariable + secondVariables>

The cfoutput tag allows us to display an output which contains the results of processing ColdFusion variables and functions:

First variable: <cfoutput>#firstVariable#</cfoutput> <br/>

Second Variable: <cfoutput>#secondVariable#</cfoutput> <br/>

Sum of both variables: <cfoutput>#sumVariables#</cfoutput> <br/>

Here the output would be:

First variable: 123

Second variable: 321

Sum of both variables: 444

Notice that we have another tag: <br/>
This tag is a regular HTML tag. As you can see we can mix HTML and CFML tags without any issues since later on the output will be anything except CFML tags and code related with them.

(ColdFusion Tutorial – Part 2) Next >