Support de Firebug dans Jelix
Par Laurentj le mercredi, novembre 28 2007, 23:17 - Projets - Lien permanent
Il ne reste plus beaucoup de tickets à fermer pour la version finale 1.0 de Jelix. L'un de ceux que je viens de fermer, c'est le support de Firebug : j'ai ajouté la possibilité d'afficher dans Firebug les erreurs php, les erreurs jelix et les messages de debug envoyés via la classe jLog. Et ça donne ça :
Ici j'ai volontairement généré une notice PHP et trois messages de log avec jLog.
Bien sûr, il est toujours possible d'afficher les erreurs directement dans la page ou dans un fichier de log, mais passer par Firebug permet d'éviter de polluer la page tout en ayant un accès facile à ces messages.
Commentaires
Salut,
je ne suis pas expert en développement XUL, mais depuis que j'ai installé FireBug j'ai de nombreuses fuites de mémoire (FireFox grimpe jusqu'à 156Mo). Est-il possible que cette extension soit mal développée (ce qui m'étonnerait fortement)?
Depuis que Patrice (metal3d) nous l'a mis en place dans Copix (en RC1 de mémoire), j'avoue que je suis complètement fan de ce système de log !
Par curiosité, comment as tu géré les logs dans les pages qui effectuent une redirection ? De notre coté, en cas de redirection ou de retour "non html", on place les infos en session pour les afficher dans la page qui suit.
@gerald : Comme dans jelix il y a des vraie vues (les objets jResponse), chaque vue traite les erreurs "à sa manière", de la façon la plus adaptée qui soit. En particulier, les réponses de redirections ne redirigent pas si il y a des erreurs, mais affichent une page HTML avec les erreurs ;-) Pour les logs par contre c'est vrai qu'il n'y a rien de spécifique pour les redirections. Un point à améliorer donc.
Toutefois, je ne pense pas que l'affichage des erreurs/logs déporté vers la page suivante soit pertinent. Il peut y avoir des risques de confusions pour le développeur.
Très très intéressante fonctionnalité. Merci Laurent.
** Hâte de pouvoir l'utiliser, en attendant retourne à Eclipse et son projet de fac ultra pressé ***
@laurentj > C'est pertinent en cas de redirection, ne serait-ce par exemple que pour tracer les requêtes qui ont étés effectuées dans la page 'invisible' (celle qui fait la redirection).
ps: c'est quoi une fausse vue ? :-)
@gerald : ce que je voulais dire, c'est que tu affiches des requêtes dans une page qui ne sont pas en rapport avec cette page. Ça peut être trompeur pour debogger. À moins bien sûr que dans les messages tu indiques que ce ne sont pas les messages de la page courante...
Disons que l'implémentation des vues dans Jelix est plus proche du concept des vues du modèle MVC, utilise mieux les possibilités de la POO, que d'autres frameworks, en tout cas mieux qu'un autre fmk auquel je pense en particulier ;-)
(oui, mon message précédent contenait un troll :-) )
PS : oui, ce message aussi contient un troll :-) )
Dur..... je suis sensible aux trolls :-) (en même temps tu le sais bien ;-))
Donc je n'hésites pas à répondre !
Non, le fait que Jelix contienne un objet réponse qui prenne en charge le formattage de certains types d'informations (ici en l'occurrence des erreurs) ne le rapproche pas plus du concept MVC que d'autres frameworks, et surtout pas Copix.
Oui, dans ta couche vue, tu disposes d'une API permettant de formater les éléments, et notamment les erreurs, qui sont un cas particulier. Pourquoi pas à ce compte la avoir des méthodes pour formater les titres, puis les paragraphes, puis les boutons, puis..... etc. Je ne dit pas que ce n'est pas pratique, ni que ce n'est pas une bonne idée, bien au contraire. Toutefois, ça ne joue en rien dans le concept MVC et ne rends pas le V plus propre. C'est une façon de la prendre en charge, ni plus ni moins (en gros un constructeur de vue.... ou une façon particulière de transporter les données "typées").
La vue, c'est une couche dénuée de toute logique (autre que l'affichage) visant à présenter des informations d'une façon spécifique.
Dans les très vieilles versions du framework auquel tu penses, la seule entorse réelle au modèle MVC était l'utilisation systématique et en l'état des zones (concept qui a été conservé dans Jelix il me semble.....).
Ces zones étaient en effet "figées" HTML et étaient injectées en dur dans les réponses. Dans la version 3 de Copix, ce n'est plus du tout le cas et nous sommes bien en présence d'un MVC pur et dur, objet réponse ou non.
Je crois que ce virage a d'ailleurs été finalement fait dans Jelix, si j'en crois une de mes vieilles lecture sur un post du forum ou il était question d'abandonner la systématisation des zones.
Je m'en vais tester ça de ce pas ! Super idée !