Logger.class.php File Reference
Go to the source code of this file.
Detailed Description
- Developer log entry:
- Necdet Can Atesman (2009-02-23): The official log levels have been defined. The starting point were the 8 log levels defined in CISCO or the unix syslog, debug, info, notice, warning, error, critical error, alert and emergency. After the adjustments for the framework, we came up with six log levels:
- vebose debug:
Anything the developer can think of: variable dumps, logs in loops. This level is very verbose, so it should only be activated for the function that is being developed. - debug: Informative information for the devlopers. This level can be enabled when working on something in the same package. It should provide useful information about what the application currently does.
- info: Informative information for the users of the application. Only the most important debug information should be here. This level can be enabled to keep track of how the whole application is currently performing. These messages can always be enabled without making the logs unreadable.
- warning: A recoverable error has occured or the application is making an assumption about something. A typical example would be a communication breakdown within the network.
- error: An unrecoverable error has occured, the current process terminates unsuccessfully, but the application in itself doesn't have to be affected. A remote peer sent an invalid packet, the connection to the database failed, etc.
- critical: The application fails entirely. A required file could not be read, the temporary directory is not readable/writable, etc.
- Developer log entry:
- Necdet Can Atesman (2009-02-26): Another description of the lower log levels:
- verbose debug: Information that would help debug a function. The inner workings of the function must be known to understand the logs.
- debug: Information that would help debug a class. The inner workings of the class must be known to understand the logs. Knowledge of the inner workings of each function is not necessary.
- info: Someone reading logs on this level must know what the class does, without the need to know how it is done.
- Developer log entry:
- Necdet Can Atesman (2009-07-31): This class needs to be partially rewritten. This task has been assigned to Joyce. This entry contains the specification for the new Logger. There are several sub-tasks to be accomplished for the rewrite to be complete:
- Refactor the file: The helper class LoggerRule needs to be extracted into its own file. First, because it is the last helper class that is left in the framework, second, because it will be passed outside the class in the future. This has already been implemented, but not committed to version control.
- Convert to singleton: The Logger class currently acts as a container for several global functions (it behaves somewhat like a module, not a class.) This behaviour is to be changed by applying the singleton pattern. This, too, has been implemented, but not committed.
- Rule juggling: The function addRule() needs to accept a spunQ_LoggerRule object. Another function called removeRule() needs to implement rule elimination from the logging facility. @Joyce: You will need to alter your addRule() implementation again for this task. It should take just 1 parameter of type spunQ_LoggerRule.
- Path types: The logger currently only browses source folders as defined in the configuration file to determine the path of a log event. This leads to confusion if a log event is triggered in a template file, for example (the file is not in any of the source folders, but in another folder, which does have an alias within the framework, like 'spunQ.backend'.) This alias->folder association cannot be hard-coded into the logger for other modules to keep the ability to add/remove modules. So the Logger must provide some means of registering classes providing this information to them. The function implementing this idea shall be called
registerEventSource(), which takes 3 parameters:
- $name: Name of the source, which will be prefixed to the actual path, separated by a colon. Example: 'spunQ.backend.main' will become 'css:spunQ.backend.main', if it belonged to a registered event source with the name 'css'.
- $aliasToFolder: An array mapping aliases to folder names. Example: array('spunQ.backend' => spunQ_Folder::get('/home/spunQ/backend'))
- $extensions: This array parameter is optional and contains all file extensions that come from this source. Any file that ends with any of the strings in the array is considered to be coming from this source. This is needed to distinguish event sources with different names pointing to the same directories (which is the case with css and js, for example.)
- Adjusting users of the logger: Since these modifications are incompatible to the current API, we'll need to adjust the rest of the world:
- spunQ::init() needs to register its own event source. Yes, that's right, the Logger doesn't recognize any file without being initialized. This should be done as early as possible in the spunQ initialization. The event source for the modules should be called 'src'.
- html::init() needs to register its event sources ('css', 'js', 'tpl'). (NOTE: Can will do this part.)
- Creating a fallback: If no event source rule matches, the logger currently uses the absolute path of the file that triggered the log event, where all path separators are replaced by periods. This just looks awful, so we'll need an optional configuration value that tells the logger what string can be removed from the beginning of uncaught log event files. If the configuration value holds '/home/spunQ/', all log events without an event source will be translated to hold a relative path in that folder, i.e. '/home/spunQ/src/core/logger/Logger.class.php' will become 'src/core/logger/Logger.class.php', which will further be translated to 'src.core.logger.Logger', as specified in the current version of the logger. Furthermore, any log events which do not match a predefined event source should be prefixed by '<undefined>:', which gives us the final path '<undefined>:src.core.logger.Logger'. @Joyce: Martin should be able to help you with configuration values.
- Developer log entry:
- Joyce Visne (2009-08-25): A problem arises in removing the ending in the last situation above. We have defined endings (similar to class.php in the above example) in the registered event sources. If we have a source which has not been registered, then we need to keep the ending (e.g., 'class.php') in some form, but we need to keep a string which conforms to the standard form we have otherwise defined. Our solution was to add this information to the <undefined> tag (e.g., '<undefined/class.php>:src.core.logger.Logger').
Definition in file Logger.class.php.
Function Documentation
Alias for vdebug().
- Parameters:
-
| $message | An arbitrary message - could be an object, too. |
- Returns:
- any $message
Definition at line 494 of file Logger.class.php.
