Ca pourrait être interessant d'avoir un mot clé 'BKTRACE' pour les logs qui ferait un backtrace (voir fonction php debug_backtrace) et qui se 'rajoute' à l'entrée du mot clé suivant (ECHO, SYSLOG, MAIL, ...)

et qui se 'rajoute' à l'entrée du mot clé suivant (ECHO, SYSLOG, MAIL, ...)

Excuse moi mais je n'ai pas bien compris où tu voulais en venir. Tu pourrais expliquer ça un peu plus clairement stp ?

Lorsqu'un utilisateur developpe une appli, il aimerait pt etre avoir un backtrace lorsqu'un erreur est généré.

Il pourrait donc mettre par exemple dans son fichier de conf, section error_handling :

 default = BKTRACE ECHO EXIT

Ainsi, ca affichera donc son erreur (ECHO) et afficherai un backtrace pour mieux déterminer ou viendrai son erreur de code (BKTRACE) et puis fais un exit (EXIT)

Oui, je vois un peu mieux ce que tu veux dire. Cette solution est à étudier.

Une autre solution est envisageable, tout du moins, nous l'avons évoqué avec laurent. Elle serait de fournir une version de Jelix spécifique au développement dans laquelle nous aurions ajouté des jLog::log() un peu de partout (enfin surtout là où c'est intéressant). Ainsi, il suffirait de suivre les logs des actions pour remonter plus facilement à la sources d'éventuels problèmes. Et comme nous avons le préprocesseur, il serait facile de fournir une version de production sans tous ces logs et surtout sans code mort ou plein de tests ala if($mode=='dev') { jLog::log(); }

c'est une possibilité d'utiliser le préproc comme ca. Mais meme si ca disparait apres le passage du preproc, ca encombre quand beaucoup le code pour ceux qui mettent le nez dedans avant de passer le preproc.

Interressant comme idée ce BKTRACE.

Norky : tu peux inscrire ton idée sur https://developer.berlios.de/feature/?group_id=5643 ?

(ou si tu as un patch : https://developer.berlios.de/patch/?group_id=5643 ;-) )

merci :-)

Finalement, j'ai ajouté deux mots clé : TRACE et ECHOQUIET.

TRACE ordonne d'afficher donc la pile d'appel, mais uniquement dans les fichiers de log (donc avec LOGFILE, SYSLOG ou MAIL). L'affichage direct imposant des modifs que je n'ai pas encore eu le temps de faire, et surtout est assez compliqué du fait du formatage à faire (qui doit donc être pris en charge par chaque objet response...)

Je pense qu'inscrire dans les fichiers de log, suffit non ? (sous linux, un tail -f sur le error.log permet de monitorer le flux des erreurs sans perturber l'affichage).

J'ai aussi ajouté ECHOQUIET. ça affiche un message d'erreur "discret", sans détail : "error(123)" suivi d'un message situé dans une nouvelle option, quietMessage, à indiqué dans la section error_handling. Utile donc pour un site en production (à utiliser conjointement avec un LOGFILE bien entendu, pour avoir un historique détaillé des erreurs).

oui, c'est bien, un format brut suffit, voir, tu fais un system de format que tu as déjà fait (%f pour nom de fichier, %l pour ligne, etc..)