POO - DEBUGGER
neigedhiver
Messages postés
2480
Date d'inscription
jeudi 30 novembre 2006
Statut
Membre
Dernière intervention
14 janvier 2011
-
29 déc. 2009 à 17:58
cs_gomoz Messages postés 134 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 23 décembre 2009 - 4 janv. 2010 à 10:23
cs_gomoz Messages postés 134 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 23 décembre 2009 - 4 janv. 2010 à 10:23
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51029-poo-debugger
https://codes-sources.commentcamarche.net/source/51029-poo-debugger
4 janv. 2010 à 10:23
2 janv. 2010 à 03:28
Ton principe de multi-logging et de sources de données (bdd, fichier) seront intégrés dans les prochaines versions.
Concernant les MAJ il y aura une console de debug, un système de breakpoints et un benchmark.
Je tiens également à rappeler que cette source s'adresse aux débutants et/ou aux personnes n'ayant pas la possibilité d'installer des extensions comme xdebug sur leurs serveurs. Si vous avez des questions, n'hésitez surtout pas.
Merci pour tes suggestions.
29 déc. 2009 à 17:58
C'est très sympa comme petite source, propre et plutôt bien codée pour ce que j'en ai vu, et plutôt utile.
Pour la méthode _log() tu utilises file_put_contents(). J'aime bien cette fonction aussi parce qu'elle ouvre, écrit et ferme le fichier. Son défaut dans le cas présent, c'est justement de faire tout ça. La méthode log risque d'être appelée plusieurs fois pendant l'exécution d'un script, il est donc dommage de fermer le fichier à chaque fois pour le réouvrir. Il me paraîtrait plus judicieux d'ouvrir le fichier une seule fois (lors de setOutputStream() par exemple), d'écrire à chaque fois qu'on a besoin de le faire, et de fermer le fichier à la fin (dans __destruct() par exemple).
Il faudrait alors garder une trace du pointeur du fichier dans une propriété privée. Eventuellement, le fichier peut n'être ouvert que quand on a besoin d'écrire dedans la première fois (plutôt que dans setOutputStream(), désolé, je réfléchis pendant que je tape). Mais la fermeture a bien sa place dans le destructeur : on peut imaginer vouloir logguer une information dans un fichier puis une autre à l'écran, ou dans une base de données... ce qui m'amène à penser que faire un singleton peut ne pas être le plus pertinent : pourquoi pas un multiton, par exemple ? Une instance pour chaque type de sortie, par exemple.
Je ne sais pas quelles mises à jour tu as prévues, mais hormis ce que je te propose dans les lignes ci-dessus, je suggèrerais également un log en BDD, un log dans plusieurs fichiers (en parallèle, c'est à dire sans fermer les autres quand on écrit dans un nouveau), pour permettre de journaliser différentes choses (des erreurs, des accès, etc), et enfin la possibilité de spécifier un format pour le rendu du log (un simple sprintf() permettant d'injecter les données à logguer dedans).
Bon c'est un debuggueur, pas un gestionaire d'erreurs, mais pourquoi ne pas combiner les deux ? Il pourrait alors attraper les exceptions qui ne l'ont pas été par un catch, ou intercepter les erreurs (set_error_handler()).