Re: Bel_env et debug
nicod_ <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <[email protected]> |
Le 12/08/2020 à 20:28, Bruno Bergot a écrit : >> Sinon j'ai un truc dans le genre, avec un affichage un peu plus >> détaillé, et d'autres balises, si tu veux tester : >> https://github.com/nd-/dd >> Faudrait que je le mette sur la zone... >> > > Oui ça serait bien, mais ça nous fera maintenant trois filtres pour un > usage presque similaire :\ Ma version affiche des infos dans une barre (comme le plugin dev, je m'en suis inspiré), notamment le nombre de requetes Mysql executées. Ça me permet de vérifier rapidement les mises en cache. Et l'affichage des infos de débug est limité par une autorisation, qui vérifie soit le statut (webmestre) soit l'IP (pour pouvoir débugger à distance, même non loggé). La prochaine modif sera de pouvoir afficher la liste de toutes les requêtes passées en un click, comme les barres de débug de Laravel ou Symfony, avec un affichage sympa. > Par contre, il faudra choisir un nom pour le filtre qui prendra le > relai, ou alors garder debug qui a l'avantage d'être connu car > documenté, et mettre à jour sa doc. Ben en fait j'ai découvert debug avec le mail de tonton, je ne connaissais pas :D Et bel_env je trouve les infos moins lisibles qu'un simple var_dump quand on a xdebug installé (mais ça fait un moment que j'ai pas utilisé). Perso je colle mon dd partout, et en fait je me rend compte à l'usage que c'est vraiment #ENVDD que j'utilise le plus, pour vérifier ce qu'un squelette reçoit. C'est juste une balise à écrire, plus courte que [(#ENV|bel_env)]. Quand on débugge, on l'ajoute par ci par là, on la retire, ça m'a saoulé de devoir taper tout ça à chaque fois, d'où mon bricolage maison. -- nicod_