Tutoriels

Installation du framework Premiers pas Mises à jour du framework Gérer les utilisateurs Gestion des textes et des langues Gestion des erreurs Créer ses classes & librairies

Classes & librairies

DSM.class.php DSMUser.class.php DSMMessage.class.php Libraire LJ Librairies internes

Gestion des erreurs

Introduction

L'un des principaux avantages du framework est qu'il vous permet de gérer facilement les erreurs qui apparaissent sur votre site. Chaque erreur qui apparaît est sauvegardé dans la base de donnée, une fois votre site en production, il devient facile pour vous de les traquer. La page d'administration du framework vous permet aussi de consulter certaines statistiques concernant les erreurs de votre site. En bref : le framework vous simplifie le développement en implémentant les erreurs.

Le notion de message

Avant même de commencer à parler d'erreurs, il est très important de parler de la notion de message, car ces deux choses sont intimement lié. Alors qu'est-ce qu'un message dans le framework ?

Un message est un objet qui est émis par le développeur ou le framework, qui peut-être affiché ou non par le développeur. Ce n'est rien d'autre qu'une string (qui a pour vocation d'être courte, une ou deux prhases), à laquel est attaché certaines informations :

  • Le fichier depuis lequel le message a été envoyé
  • La localisation du message dans ce même fichier
  • L'identifiant de ce message

Que faire de ce message ?

Tout est dans le titre.. D'accord, on créé un message, mais pourquoi ? Tout d'abord, à chaque création d'un message en passant par la classe DSM (on va voir ça plus loin), votre message sera automatiquement enregistré dans la table logs de votre projet. Chaque message qui a été émis est donc affiché sur le panneau de contrôle, onglet Logs.

Mais le message a un autre objectif principal : être affiché à l'écran de l'utilisateur. C'est sa vocation première : une erreur qui est apparu au cours de la connexion d'un utilisateur doit être affichée aux yeux de l'utilisateur, non ?

Oui et non.. A vrai dire : vous avez le choix !

Comment émettre un message ?

C'est plutôt simple, mais il y a une condition à remplir : qu'un objet DSM soit correctement instancié. Je vous rassure, il n'est pas instancié automatiquement que si vous travaillé... En dehors du framework.

Une fois l'execution de la page terminée, après les footers donc, le moteur execute un script afin d'ajouter les messages dans votre HTML. Mais où le fait-il ?

$dsm -> message(123456, "Ceci est un message !", "dev/index/header.php", "traitement");

Comment afficher les messages émis ?

Une fois l'execution de la page terminée, après les footers donc, le moteur execute un script afin d'ajouter les messages dans votre HTML. Mais où le fait-il ?

Le moteur ajoute vos messages dans un conteneur HTML ayant pour id HTML : DSMMESSAGES. Le script ajoute dans cet élément d'id DSMMESSAGES une division avec l'attribut class DSMMESSAGE. Le conteneur peut être une div, une section, peu importe en fait.

\"Mais ! Ca ne fonctionne pas !\"

Oui, j'ai oublié de vous précisé une chose, un dernier attribut de votre message : sa propriété print. Cette propriété de la classe DSMMessage est un booléen. Lorsque celui-ci est à false, votre message ne sera pas ajouté au conteneur HTML DSMMESSAGES, mais il sera bien ajouté dans la table de logs. Et par défaut, la propriété print d'un message vaut false. Il faut donc passer cette propriété à true pour que votre message soit affiché. Pour cela, émettez votre message de cette manière :

$dsm -> message(123456, "Ceci est un message !", "dev/index/header.php", "traitement", true);

Les erreurs

La première chose à savoir à propos d'une erreur, et c'est à vrai dire la seule chose à savoir, c'est que ce n'est rien d'autre qu'un message. En effet, au sein du framework, une erreur est représenté par la classe DSMError. La classe DSMError hérite directement de la classe DSMMessage.

Qu'est-ce qui change ?

La seule chose qui change dans cette classe DSMError, déjà c'est son nom, puis ensuite c'est sa propriété type. Dans la classe DSMMessage, la valeur de tpye vallait DSMMessage::MESSAGE. Dans la classe DSMError, la propriété type vaut DSMMessage::ERROR.

Voici comment on émet une erreur grâce au framework :

$dsm -> error(123456, "Ceci est une erreur !", "dev/index/header.php", "traitement", true);

Consulter la méthode error

Les warnings

Au delà des erreurs, il existe un autre type de message, les warnings. Ces derniers ont pour vocation de reporter une petite erreur, pour avertir l'utiisateur ou l'adminstrateur.

Qu'est-ce qui change ?

La propriété type prend pour valeur DSMMessage:WARNING et l'émission d'un warning se fait de cette manière :

$dsm -> warning(123456, "errors-warning-error", "dev/index/header.php", "traitement", true);

Consulter la méthode warning

Les succès

Il existe également un autre type de message, les success. Ces derniers ont pour vocation d'afficher un succès, qu'un code s'est bien déroulé, qu'une inscription a réussi, etc.

Qu'est-ce qui change ?

La propriété type prend pour valeur DSMMessage:SUCCESS et l'émission d'un succès se fait de cette manière :

$dsm -> success(123456, "errors-success-error", "dev/index/header.php", "traitement", true);

Consulter la méthode success

Les patterns de message

On a donc bien vu comment émettre un message, où ils étaient affichés dans votre code.. Mais pas la façon dont ils étaient écrit. C'est ici qu'interviennent les patterns.

Par défaut, un message est affiché sous la forme suivante :

  • Message #id : the message (in file ... at ...)

Ce qui correspond au pattern :

  • Message #!id : !message (in file !file at !location)

Mettre un point d'exclamation devant un mot dans le pattern veut dire que l'on souhaite affiché la propriété correspondante.

L'objet DSMMessagePattern

La représentation objet d'un tel pattern se fait via l'objet DSMMessagePattern. Son constructeur est le suivant :

$pattern = new DSMMessagePattern($type, $resource, $pattern);
  • type : il peut prendre 2 valeurs, DSMMessagePattern::HTML ou DSMMessagePattern::JAVASCRIPT
  • resource : dans le cas d'un affichage par défaut (HTML), c'est le nom du conteneur HTML qui contiendra les messages (par défaut DSMMESSAGES). Dans le cas d'un affichage javascript, c'est le nom de la fonction qui sera appelée.
  • pattern : c'est le pattern en lui même : le format d'affichage du message

Affecter un pattern à un type de message

Une fois votre pattern créé, il faut indiquer au framework à quel type de message il doit s'appliquer, pour cela, il faut remplir le tableau associatif DSM::patterns :

$messagePattern = new DSMMessagePattern(DSMMessagePattern::HTML, "DSMMESSAGES", "Info : !message");
$errorPattern = new DSMMessagePattern(DSMMessagePattern::HTML, "DSMMESSAGES", "Error : !message");
$warningPattern = new DSMMessagePattern(DSMMessagePattern::HTML, "DSMMESSAGES", "Warning : !message");
$successPattern = new DSMMessagePattern(DSMMessagePattern::HTML, "DSMMESSAGES", "Success : !message");
$dsm -> patterns[DSMMessage::MESSAGE] = $messagePattern;
$dsm -> patterns[DSMMessage::ERROR] = $errorPattern;
$dsm -> patterns[DSMMessage::WARNING] = $warningPattern;
$dsm -> patterns[DSMMessage::SUCCESS] = $successPattern;

Notions avancées

Identification d'un message

Comme vous avez pu le voir, un message possède un identifiant id, afin de le rendre unique. Pourquoi unique ? Parce qu'à chaque fois que vous faites appel aux méthodes mssage, error, warning et success, vous le faîtes à un endroit différent de votre code. Donner un identifiant unique à votre message permet ainsi de retrouver très facilement d'où ce message a été émis.

Lorsqu'un message apparaît sur votre site, si vous souhaitez chercher d'où il vient, il est intéressant de regarder les informations file et location. Ou alors de faire une recherche sur l'identifiant dans tous le projet.

Mais vous conviendrez que donner un identifiant unique à chaque message peut rapidement devenir, n'ayons pas peur des mots, bordelique. Il devient donc intéressant de respecter quelques règles pour donner un identifiant à votre message.

Conventions de nommages

Vous avez probablement remarqué que l'identifiant des erreurs internes au framework sont des nombres très grands. Pourquoi ? Car le framework utilise une convention de nommage. Chacun des chiffres de l'identifiant d'une erreur a une signification. Par exemple, prenons l'erreur : 1110701 (erreur apparaissant dans la méthode log)

  • 1------ : apparaît dans un fichier du dossier motor
  • 11----- : apparaît dans un fichier du dossier motor/core
  • 111---- : apparaît dans le fichier motor/core/DSM.class.php
  • 11107-- : apparaît dans la méthode log du fichier DSM.class.php
  • 1110701 : le 01, c'est l'identifiant du message au sein de la méthode log

Pour un identifiant avec des tirets - ou des x, on parle de plages de messges. En effet, pour les messages apparaîssant dans des fichiers du dossier motor peuvent avoir un identifiantsur la plage 1------, c'est à dire que les identifiants peuvent aller de 1000000 à 1999999.

Pour le dossier dev, la définition de la plage vous est libre, le premier chiffre 2 est toutefois conseillée. Voici quelques exemples de plages pour le dossier dev :

  • 2abcddeeff : a, b, c correspondent aux dossiers et sous dossiers, dd au fichier concerné, ee à la fonction ou à la partie du code concernée, ff est le numéro du message dans cette partie.
  • 2aabbccddeeff : aa, bb, cc correspondent aux dossiers et sous dossiers, dd au fichier concerné, ee à la fonction ou à la partie du code concernée, ff est le numéro du message dans cette partie.

Il existe une exception pour le dossier de développement dev : le dossier dev/admin. Ce dossier possède la plage 3------- :

  • 301----- : dev/admin/index
  • 303----- : dev/admin/control
  • 304----- : dev/admin/dev
  • 3051---- : dev/admin/users/users
  • 3052---- : dev/admin/users/groups
  • 3053---- : dev/admin/index/rights
  • 306----- : dev/admin/stats
  • 307----- : dev/admin/ftp
  • 308----- : dev/admin/authentification
  • 309----- : dev/admin/tools