Log class – events logger class

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
/**
 * Interface for log classes
 * @author Vokiel
 * @package log
 */
interface log_log{
	/**
	 * Adding a error message into logs
	 * @param	string	$msg	Message
	 */
	public static function error($msg);
	/**
	 * Adding a warning message into logs
	 * @param	string	$msg	Message
	 */
	public static function warn($msg);
	/**
	 * Adding a information message into logs
	 * @param	string	$msg	Message
	 */
	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('Everything ok');
log::error('All the blood in the sand!');
?>

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.

 

Przeczytaj także

Komentarze: 2

Dodaj komentarz »

 
 
 

[…] Log class – klasa loggera zdarzeń cz 2 Dodano w: Log Class, PHP | przez Vokiel | 0 Komentarzy » […]

 

Reply

 

[…] w jedno. Doda kilka funkcjonalności, wprowadzi wygodę w użytkowaniu, łatwość zmian. W pierwszej części ustaliliśmy wymagania klasy Log, ustaliliśmy strukturę, zasady funkcjonowania klasy oraz […]

 

Reply

 

Dodaj komentarz

 
(nie będzie publikowany)
 
 
Komentarz
 
 

Dozwolone tagi XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
© 2009 - 2016 Vokiel.com
WordPress Theme by Arcsin modified by Vokiel