September 30, 2012

Modifying FW/1 variables.framework properties

FW/1 gives you a nice, clean way to manage framework configuration properties. They’re all wrapped up inside Application.cfc in a structure called variables.framework, you can read more about them here under Configuring FW/1 Applications.

Our applications often have a need to use different values for these properties, depending on which environment the application is running in (development, testing, staging, production etc). An example of this might be reloadApplicationOnEveryRequest, which we want as true in development, but false elsewhere else.

So our defaults (at the top of Application.cfc) might be to set the reload property as false:

variables.framework = {
  reloadApplicationOnEveryRequest = false,
  disableReloadApplication = true;
  ...
}

These are good values for production, but we want to override them if we’re in development. Here’s how:

/**
* @hint We need to override variables.framework values, only way to do this is pre-fw/1 onRequestStart() as setupRequest() is called later in the call stack
**/
public any function onRequestStart(string targetPath)
{
  if (isDefined("application.config.mode"))
  {
    if (application.config.mode == "dev")
    {
      variables.framework.reloadApplicationOnEveryRequest = true;
      variables.framework.disableReloadApplication = false;
    }
  }
  super.onRequestStart(targetPath);
}

You can see in the example above that we override the default values we set initially, so that if we’re in development mode we not only have the ability to reload the application (using a custom property called disableReloadApplication), but we also reload the application on every request.

2 things to note here, are that we can’t use setupRequest() for this, as it’s called too late by framework.cfc and won’t enable us to override any variables.framework properties. So instead we use onRequestStart(), which gives us the 2nd thing to watch out for, and that is that you must be careful to call super.onRequestStart(targetPath); at the conclusion of this method. Or you might get strange results.

© Michael Sharman 2017