Halhelms
SIGN UP FOR MY NEWSLETTER

www.savorgold.com is top on wow gold and runescape gold and World of Warcraft gold provider list for trusted services. Their reputation seems to growing by the minute, which isn't surprising because they are one of the safest sellers of Gold. Delivery speed and customer service are very good. They aslo are giving some bonus items depending on the amount of gold you purchase.

 
 
Halhelms

Recent Comments

Recent Entries

RSS

Learning ColdBox: III

Before we get into writing the application, I want to ask about logging with LogBox. A while ago, I felt the need for something more than I could get with native logging. During development, I wanted to have the ability to log something. That something might be a simple value, an array, a struct, an object, etc.

While I didn't want logging to occur when code moved to production (for obvious reasons), I did want to leave the code in place (so that, for example, I could turn it on if some anomaly occurred or if I wished to time certain processes while running in production). And finally, I didn't want to wrap logging code in if statements. That's ugly and, with enough of them, could become expensive. What to do?

The solution I decided on was to have two logging classes: TrueLogger and FalseLogger. When the application began, the question was asked: are we in production or development? If in development, I would instantiate a TrueLogger -- something like this:

component{
   public void function log( value ) {
      // determine data type of value and log appropriately...
      
      // real code for logging goes here...
   }
}

In production, though, a FalseLogger was instantiated:

component{
   public void function log( value ) {
      // do nothing
      return;
   }
}

Now, I could have code like this:

logger.log( myObject );

Or this:

public function doPossiblyTimeConsumingProcess() {
   var start = GetTickCount();
   // possibly time-consuming code here
   var stop = GetTickCount();
   logger.log( stop - start & ' ms to run doPossiblyTimeConsumingProcess()';
}

To turn logging on during production, I could pass a URL variable (in the same way ColdBox accepts a fwreinit variable).

Prior to coming up with the two logger types, I wouldn't have left this solution in production. Logging an object required getting its properties, then looping over them and inserting their names and values into a log file -- much too expensive. But with FalseLogger, the cost was virtually nil.

Now that I'm learning ColdBox, I see this wonderful LogBox. I thought the log appenders were really nice -- they allow you to "log" to a normal log file, an SMS text message, twitter -- you name it.

My question for ColdBoxers out there: does LogBox have a solution to what I wanted to accomplish: leave logging code in place without the downsides of actual logging when it isn't required?

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Curt Gratz's Gravatar Sure thing, we do it all the time within the framework code itself.
Just log with a log level of say "debug" and then have your appenders
log down to the "debug" level for development and only to the "error"
level for production, or whatever minimum or maximum severity you want.
http://wiki.coldbox.org/wiki/LogBox.cfm#Severity_L...
# Posted By Curt Gratz | 4/6/11 9:11 AM
Aaron Greenlee's Gravatar I use Curt's recommendation in production. It will not be as efficient as your FalseLogger since an if check is performed using the minimum level allowed compared to the level being logged.

ColdBox transforms these levels into numeric values, 0,1,2,3,4 so the check is simple, clean and fast but, still not as fast as returning void.
# Posted By Aaron Greenlee | 4/6/11 1:35 PM
Hal Helms's Gravatar @Curt, @Aaron I'm really impressed by how well thought-out ColdBox is. I may just come up with something that uses my FalseLogger or LogBox, depending on what mode I'm in. Should be pretty simple -- and it would then give me access to all the cool stuff in LogBox.
# Posted By Hal Helms | 4/6/11 6:21 PM
Brad Wood's Gravatar Hi Hal, I'm so happy to see you blogging CF again, and ESPECIALLY happy to see you blogging ColdBox.
In reference to LogBox, I have two extra thoughts. The first is that LogBox is also a stand-alone framework that can be used outside of the ColdBox core (just like MockBox, CacheBox, and WireBox). Of course, I don't know why anyone would want to NOT use ColdBox. :)

The second thing is that not only can you specify custom log levels per environment, you can also switch out appenders as you want, AND you can control logging in defferent portions of your app by configuring logging categories.

For instance, all logging could be off on one environment, or warn level logs go to a text file for your entire app, but the E-mail appender kicks in for log event s coming from com.yourapp.security.* etc. WireBox is simply wrought with programmatic configuration potential.
# Posted By Brad Wood | 4/13/11 2:31 PM
Hal Helms's Gravatar Thank you, Brad. I hope to resume my series shortly. Right now, I'm up to my neck trying to write code and learn the framework simultaneously. Luckily for me, I have Ben Densmore to shore up my lack of ColdBox knowledge.
# Posted By Hal Helms | 4/14/11 1:04 AM
Brad Wood's Gravatar Hal, if you're not already on, I'd like to invite you to the ColdBox Google Group. Any question you might have about any of *Box apps can be asked there.
http://groups.google.com/group/coldbox

Also, if you're available, we have an online podcast every two weeks called ColdBox Connection where we talk about different parts of the framework and show code samples. Schedule and recordings are located here:
http://coldbox.org/media/connection
# Posted By Brad Wood | 4/15/11 2:33 AM
Richard Herbert's Gravatar To control per-environment settings take a look at...

http://wiki.coldbox.org/wiki/ConfigurationCFC.cfm#...

...rather than using a URL name/value switch. The framework can do that for you automagically!
# Posted By Richard Herbert | 4/15/11 12:40 PM
 
   
Clicky Web Analytics