Coldbox environments using machine name

ColdBox 3 has reached M6 and has some really nice improvements over ColdBox 2.6.

One of my favourite features is the environment interceptor. Being able to define different settings per environment is not new to Coldbox, but with the new cfc based config it's even easier.

Here's a snippet from a typical Coldbox.cfc config where I've turned the debug mode off:

Coldbox.cfc

<cfcomponent output="false" hint="My App Configuration">
  <cfscript>
  // Configure ColdBox Application
  function configure(){
    coldbox = {
      //Application Setup
      appName = "Aliaspooryorik",
      eventName = "event",
      //Development Settings
      debugMode = false,
      ... more settings here...
    };
  }
  </cfscript>
</cfcomponent> 

For development I want to have debugging turned on, so I could set the debugMode to true, but then I could accidentally upload the file to my production server and all my visitors will get debugging information!

This is where the environment interceptor comes in handy. I can tell Coldbox that for http://localhost/ I want to use a different settings.

<cfcomponent output="false" hint="My App Configuration">
  <cfscript>
  // Configure ColdBox Application
  function configure(){
    coldbox = {
      //Application Setup
      appName = "Aliaspooryorik",
      eventName = "event",
      //Development Settings
      debugMode = false,
      ... more settings here...
    };
    
    // environment settings, create a detectEnvironment() method to detect it yourself.
    // create a function with the name of the environment so it can be executed if that environment is detected
    // the value of the environment is a list of regex patterns to match the cgi.http_host.
    environments = {
      development = "^localhost$"
    };
    
  }
  
  // Executed whenever the development environment is detected
  function development(){
    coldbox.debugMode = true;
  }
  </cfscript>
</cfcomponent>

Now whenever I run the site from my localhost I will get debugging information and I can safely upload my config to the live site.

However, you may work with a designer who also runs the site as http://localhost/ on their development machine, but they don't want to see the debugging information (even though it's quite pretty!). Well, what you can do is tell Coldbox that you don't want to use the machine name instead of the cgi.http_host variable to determine the environment. Again it's really easy to do:

<cfcomponent output="false" hint="My App Configuration">
  <cfscript>
  // Configure ColdBox Application
  function configure(){
    coldbox = {
      //Application Setup
      appName = "Aliaspooryorik",
      eventName = "event",
      //Development Settings
      debugMode = false,
      ... more settings here...
    }
  }
  
  // custom code to detect environment by hostname instead of using cgi.http_host
  function detectEnvironment()
  {
    return createObject( 'java', 'java.net.InetAddress' ).getLocalHost().getHostName();
  }
  
  // My machine is called 'john'
  function john(){
    coldbox.debugMode = true;
  }
  </cfscript>
</cfcomponent>

Now when I run the site on my locahost I get debugging, but my colleague can also run from their localhost and not see any debugging. Simple but powerful.

• Posted in:
• Coldbox

4 comments

1. IMHO - I find having a seperate config file for each environment, and then have your deployment script put the right one in.
   
   As your live app shouldn't need do logic on config as it will only every have one.
   
   In addition if your config files are kept in sync it's easy to spot anything that isn't added to your config files.
   
   Comment by Big Mad kev – August 11, 2010
2. Nice to see the simplification of the code as well as adding the machine name + host!
   
   Got to love coldbox, it might throw in the kitchen sink but then all the dishes DO get done :)
   
   Comment by Mark Drew – August 11, 2010
3. Agree with Kev. Seperate files in the way to go. We hacked this file to include separate files as a compromise... Luis has already seen my implementation. One key thing is that with SVN/GIT, it would be easier to merge and make changes, that have one big file that bloats as you add more developers. Whats even better is a tiered approach... so if you have a group of servers for local development, and they all need to have debug on, then you can create a group of shared settings, and then if you need to go further and individualize, you can... but this way, new developers get to easily start off with standard defaults... What Luis has done so far is good, but it can be much better for larger more complex environments.
   
   Comment by Sami Hoda – August 12, 2010
4. @Kev, I love to use deployment scripts in-house but it just isn't designer friendly :)
   
   @Mark, we all love clean dishes!
   
   @Sami, I agree with you about multiple developers sharing settings. You can do that with detectEnvironment() method quite easily, such as:
   
   function detectEnvironment()
   {
   var hostname = createObject( 'java', 'java.net.InetAddress' ).getLocalHost().getHostName();
   if ( ListFindNoCase( "andy,darren", hostname ) )
   {
   return "designer";
   }
   else
   {
   return hostname;
   }
   return
   }
   
   Comment by John Whish – August 12, 2010