Logging class / implementation

Launchpad Blueprint for 'logging-class-module', definitive version

- What should the logging class offer?
   * Similarity to "log4net"
   * Have different methods for different kinds of messages
   * Message types: info, debug, error, fatal
   * Fatal messages should kill the script, errors shouldn't
   * Using to be defined database tables
   * Possitiblity to save or not save the POST/GET data (privacy)

- What data should be stored within a dataset (1st Revision with updated release script)
   * Primary Key of course
   * ID of the mandant
   * Menu ID where it happened
   * User ID to resolve
   * Resolved menu name
   * Alias, Full Name and ID of the user who caused the error
      -> If no user, it will be right stored this way as "website visitor"
   * Date and time on which the error occured
   * Type of the error
   * Eventually stack trace, error or exception message (as possible)
   * Current browser url
   * Full POST data stack (security/privacy: passwords?)
   * Full GET data stack (security/privacy: passwords?)

- Menu and user resolving
   * To make the software (especially the admin view) faster we wont
      use and joins, because they're only reasonable for menu and usernames.
      Since they to not change, they will be provided as text. The viewer can
      resolve them by clicking (ajax call) on them if the name has changed

- Security with passwords
   * Better said "privacy". The login will surely get an "error" thrown if the
      login fails. But due to the POST/GET stack those passwords could be seen.
      Since the given in passwords are wrong (a clean login won't be logged
      with POST/GET stack, there's no need to shadow password fields. Although
      developers could modifiy this.
   * Let's just say: sddCMS will never log anything containing passwords. But it
      has to log the POST/GET data in order to solve errors or trace hacker attacks.

- Implementation of the class
   * Implemented in /classes/logging/logging.php
   * Can be derived to provide more/different functionality
   * Implementetd as simple as possible to the outer world
   * Might be required once in the system to always have a logging object?
   * Or: Instantiated at the base class for modlues (additional-, commonModule)?
   * If it's used otherwise (think this is seldomly used) it can be instantiated

- Usage
   * Logging will be used on every save function on every module
   * Wrong Logins performed
   * Deletion of objects within every module
   * Possible errors where catchable
   * Just a thought... sddCMS should use more exceptions!
   * Logging should not be used to make statistics (e.g. link click frequency)

- Admin module to view logs
   * Logs can be cut to a certain amout of records per page (maybe static.. 50?)
   * Order by date, menu name, user name, error type
   * Orderable in different kinds (desc, asc) over different fields
   * Delete functions -> (Simple delete by ID, by user, by menu)
   * POST/GET data should be shown in a tooltip
   * Also, a log entry can be seen on a seperate page (unshortened)
   * It should be possible to search for "similiar entries" (don't know the interface yet)
   * Possibility to resolve the current user name / current menu
   * Use the new ajax interface to manage the above features ;-)
   * A cron should delete old log records (if they consume as much space as I think)