Vokiel.com

When writing web applications it is an important part of the project to have the knowledge of effects of this product. There are errors arising not only from poor implementation, application code, but also those programmer unrelated errors. They may be various outages other services, problems with Internet connection, failures. In that kind of situation, a a very useful tool is the ability to log events. In this entry I will discuss the idea of own logger class.

Let’s start from the assumptions, the requirements for the class.

1. flexibility
2. ability to place logs in different formats and locations
3. ease of use
4. allows a rapid change in storage

It happens sometimes that you want to store log in files, sometimes in the database. Our class should be able to easily change the engine of keeping logs and should have a simple way to switch between them.

Alternatively, it could be possible to use several engines in one script. This option is not so important and certainly is not a necessity, but it may be useful in extreme situations. Suppose you have set your logging class to write into the database. But what if the database connection is interrupted? In such a situation it would be good to save the log in easily accessible place – into a file .log, .xml.

To be able to use an easily way of switching logger engine we should schedule the class structure very well. We can use abstract classes, interfaces or regular classes. To maintain compatibility for additional drivers I’ve decided to base logger class on interfaces.
According to wikipedia:

Interface generally refers to an abstraction that an entity provides of itself to the outside.

. Interface in PHP is as if only a helper for the developer. It shows what methods the implementing classes have to implement but it is not giving them (as opposed to abstract class). It would be a very good solution for our application. Each type of driver will add the event to the logs in different way. In addition, using interface we can be confident that the additional drivers will have the required method.

What methods will we need? For me the 3 basic are enough: error();, warn();,info();. Schema of interface will be as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<?php
/**
 * Interfejs dla klas logów
 * @author Vokiel
 * @package log
 */
interface log_log{
	/**
	 * Dodanie błędu do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function error($msg);
	/**
	 * Dodanie ostrzeżenia do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function warn($msg);
	/**
	 * Dodanie komunikatu informacyjnego do logów
	 * @param	string	$msg	Komunikat
	 */
	public static function info($msg);	
}// end of logInterface
?>

Our interface has 3 methods to which the message is forwarded. You will ask why not a single method with a flag indicating the type of message. Well, this is due to the third point of assumptions. We’ve created a static method, so we can refer to them by:

<?php
log::info('Wszystko ok');
log::error('Wszystko jak krew w piach!');
?>

What next? In the next posts we will be creating classes implementing an interface log_log  and the doing the class which would keep it all in a heap.