In response to this suggestion from Alessandro Nadalin about using the "Strategy" design pattern to replace a switchChris Hartjes has this new post sharing his opinion of "the right way" do it it.

Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

On PHPMaster.com today there's a new tutorial from Lorna Mitchell introducing you to using Analog for error logging in a MongoDb connection. Because of the way the tool (Analog) is designed, it could be used anywhere - she just uses the MongoDB connection as an example because it integrates easily and efficiently.

MongoDB is an excellent fit for logging (and of course other things as well) for many reasons. For one, it is very VERY fast for writing data. It can perform writes asynchronously; your application wont hang because your logging routines are blocked. This allows you to centralize your logs which makes it easier to querying against them to find issues. Also, its query interface is easy to work with and is very flexible. You can query against any of the field names or perform aggregate functions either with map/reduce or MongoDB 2.2's upcoming aggregation framework.

This article will show how you can use existing code to add a logging library to your code and log errors to MongoDB. You'll also see how to query MongoDB from the command line and how to filter those queries to find the information you are interested in.

Analog makes it simple to log information in an easy to use, self-contained, extensible kind of way, offering writers for multiple output formats including: files, the FirePHP plugin output, email, POSTing to another machine and sending to a syslog daemon. She also mentions the different logging levels the tool makes available and how to filter down your logging results based on them (searched by "equal to", "greater than" and grouped by level).

Ryan Gantt has a new tutorial posted to his blog today looking at one of the features in the upcoming PHP 5.4.x releases - traits. Specifically he looks at the horizontal reusabillity they allow for in your applications.

The ability for a class to inherit from multiple parents is maligned by many, but can be a good thing in some situations. For those working in PHP, multiple inheritance has never been an option; classes are limited to one parent, though they can implement many other datatypes through the use of interfaces. Interfaces can lead to code duplication in improperly-factored inheritance hierarchies. Even in well-architected hierarchies, multiple classes that implement similar methods can contain a lot of overlap.

He starts with a definition of what traits are and where their real usefulness is (as well as what should be the difference between a class and a trait). He gives an example of a typical hierarchy where two classes extend a parent but then they both need the same functionality. Code duplication's not a possibility and inheritance make run into exposure issues. Traits come to the rescue by dropping in just the feature you need when you need it. His example code shows adding some logging to a simple class via a "Logging" trait and a "Singleton trait" example.

Dave Marshall is already looking ahead to the next major release of PHP, version 5.4, and one of the features it will include - traits. In this new post to his blog, he introduces a "logging trait" he's come up with to make logging simpler in your (Zend Framework) application.

One of the 'traits' I find myself constantly adding to library files is optional logging of it's behaviour. The library class has it's own log method, that checks to see if the instance has had a logger injected and if so, logs the message. I see this as a perfect candidate for becoming a reusable trait, as I tend to have the same code copy/pasted throughout my library classes. The problem is, according to the rfc, traits aren't supposed to have state/properties, which makes it difficult to have a DI setter method in a trait.

He includes the code for his trait example (noting that it may or may not end up working correctly in the 5.4 final release) that sets a logger on a sample class and logs a few values out to the console. It's a simple example, but it shows you one of the most useful things about traits - the "drop in resuability" nature they allow in your libraries and classes.

Henry Hayes has written up a handy post to his blog looking at using FirePHP and Zend_Log_Writer_Firebug to log messages directly to your Firefox's Firebug console.

Due to sloppy programming in the past many PHP error logs can become very clogged up and, unless you use some fancy grep technique, unusable. [...] A project has been around for some time now called FirePHP. This enables us to log messages of various levels of severity to the Firebug console! - Awesome. Just imagine if you are developing an ajax app, you could have all your debug messaging in one place.

He walks you through the steps needed to get the logging up and running - setting up FireBug (if you don't have it already) and FirePHP, editing your Zend Framework bootstrap file to add an _initLogging() method and using it for logging, both in the backend script and on the frontend in the console. He also includes a quick update to the logging method that only logs to the Firebug console if the environment is not production.

Slawek Lukasiewicz has a new post to his blog today showing you how to use the popular Firebug extension for Firefox with the FirePHP plugin to make error logging simpler and less obtrusive without ever having to leave the browser.

If you use Firefox, I bet you already know Firebug extension. This is irreplaceable tool for web development. But there is also FirePHP extension, which provides possibility to log into Firebug console from PHP scripts. This is very convenient way for debugging process, because logs are independent from application output.

He shows the integration you can do with the Zend Framework's Zend_Log component to write basic messages and the Zend_Wildfire component to write tabular data back to your browser's console with two snippets of code.

Sameer Borate has posted some of his thoughts about logging in PHP applications and how it can be one of the most important things you do.

Software development is an exercise in managing complexity, and the more tools and methods we have at our disposal the easier it gets. One of my favorites is logging - recording important code execution points that I think are important, especially during debugging. [...] But what information does one log and what does one keep out. This usually depends on what kind of application you are developing.

He gives an example of logging on database intensive applications - storing the query execution state - complete with a simple example of an "addUser" method that logs any issues caused by the query execution. If you're not using a framework that has it's own logger, he recommends a few: KLogger, Log4PHP and the Zend_Log component of the Zend Framework (can be used separately)

New on the ZendCasts.com site, there's a screencast about using Zend_Log to create a full logging framework for your Zend Framework-based application.

I was working on a project for a client the other day and noticed a couple of lines in the ErrorController for automatically logging errors with Zend_Log. In 10 minutes, you can have a fully integrated logging framework. I also implement a singleton pattern for reusing your Zend_Log configuration (defined in the application.ini) anywhere else in your application.

You can watch the screencast via the in-page player and follow along with the code if you'd like to download it from here.

The ZendCasts.com site has recently posted a quick video covering logging and Doctrine event listeners in a Zend Framework application.

This short video is going to be the last in my 2009-2010 series on Doctrine 1.2. I'm wrapping it up with a little example of adding timestamps, logging and using Doctrine's event listener architecture.

The tutorial shows you how to pull in the features of Doctrine to make it easier to create a more complex logging system. He shows how to set up the schema file, add in controller functionality and backend models to make things all work together happily. You can get a copy of the project he's building from his subversion repository.

On the Symfony blog today there's a new post by Fabian Lange about using the detailed logging ability of the newly released version of Propel (the database abstraction layer).

Today Propel 1.4 was released and it contains some debugging goodies. We can use the DebugPDO class to get the nifty logging into the Web Debug Panel. However some more interesting information is turned off by default by Propel.

Features include time logging, memory logging and slow query logging - all that are simple to enable in your configuration under the details for your propel connection. You can see an example of the output from the logging here.