Xdebug, symfony et NetBeans : comment débugguer votre projet avec file_link_format ? On avance !
J’ai vu passé quelques billets à propos de file_link_format et symfony, notamment pour pouvoir débugguer plus rapidement en ouvrant un fichier dans NetBeans 6.8 depuis son navigateur web.
Il y a notamment l’astuce de symfony-IT qui permet de faire cela pour NetBeans sous Linux (avec un script bash).
John Kary s’essaie à la même manip, mais lui sous Mac, la tâche ne semble pas plus aisée.
C’est que NetBeans ne nous simplifie pas la chose, on dirait.
Puisque je ne désespère pas, j’ai essayé de trouver une solution à mon problème et c’est Omar, dans les commentaires de mon précédent billet qui m’a fait avancer un peu plus.
Voici donc la structure de mon fichier .reg, qui me permet d’ajouter les clés nécessaires dans la base de registre (Démarrer -> Exécuter -> « regedit ») :
REGEDIT4 [HKEY_CLASSES_ROOT\editor] @="URL:editor Protocol" "URL Protocol"="" [HKEY_CLASSES_ROOT\editor\shell] [HKEY_CLASSES_ROOT\editor\shell\open] [HKEY_CLASSES_ROOT\editor\shell\open\command] @="C:\\netbeans.bat %1"
Mon fichier \config\settings.yml de mon projet symfony (faites attention à l’indentation, ça s’affiche mal sur le blog) :
dev: #yeah, we never know .settings: file_link_format: "editor://%f:%l"
Et enfin, mon fichier C:\netbeans.bat :
@echo on SET CHEMIN_O=%1 SET CHEMIN_R=%CHEMIN_O:editor://=% SET CHEMIN=%CHEMIN_R:~0,-1% "C:\Program Files\NetBeans 6.8\bin\netbeans.exe" --open "%CHEMIN%"
(vérifiez chez vous que le chemin d’install de votre NetBeans est correct, bien sur
).
Pour que ça soit drôle, bien entendu, ça ne marche pas.
Enfin, ne soyons pas difficiles : NetBeans s’ouvre quand je clique sur le lien editeur://C:\wamp\www\dev\sandbox\lib\vendor\symfony\lib\util\sfContext.class.php:13
Mais c’est tout. NetBeans s’ouvre et c’est tout : pas de fichier sfContext.class.php chargé et donc encore moins de curseur positionné à la ligne 13.
Rageant, surtout que sur le net, j’ai trouvé pas mal d’articles disant que « oui, il est possible d’ouvrir NetBeans avec un fichier en mettant –open dans la ligne et oui, on peut spécifier un numéro de ligne ».
Un exemple ? Ici.
Mais en fait, à chaque fois, on parle d’une version inférieure à la 6.8. J’ai donc installé la fameuse version 6.5 (RC2, trouvée rapidement sur le net) pour tester.
Ma seule modif était de changer le chemin de mon netbeans.exe dans le fichier .bat :
@echo on SET CHEMIN_O=%1 SET CHEMIN_R=%CHEMIN_O:editor://=% SET CHEMIN=%CHEMIN_R:~0,-1% "C:\Program Files\NetBeans 6.5\bin\netbeans.exe" --open "%CHEMIN%"
Pas trop complexe la modif, je le reconnais.
Et là, grande désillusion, ça marche. NetBeans 6.5 s’ouvre, mon fichier est chargé et le curseur est bien positionné à la ligne qu’il faut.
Rageant.
Le souci se trouve donc du côté de NetBeans 6.8 et pas dans ma config. Bref, le débugguage d’un projet symfony avec file_link_format et NetBeans 6.8 comme sous vim ou textmate, c’est pour bientôt.
J’ai en effet reporté le bug du côté de NetBeans, en espérant qu’ils soient réactifs.
Je suis un peu surpris que cette fonctionnalité ne soit plus présente, surtout que par endroit, j’ai lu que ça marchait encore.
Autre souci rencontré avec NetBeans 6.8 : à chaque fois que je clique sur un lien généré par mon appli symfony, j’ai une instance de NetBeans qui s’ouvre (on peut donc logiquement arriver à 3 ou 4 NetBeans ouverts).
Enfin, la fenêtre MS-DOS, ouverte à cause de mon .bat, reste ouverte tant que NetBeans tourne. Pas pratique.
Alors, vous pouvez toujours débugguer avec NetBeans 6.5, bien entendu. Mais c’est moins drôle quand on connait les avantages de la 6.8 qui supporte symfony.
Mais il faut y croire : ça va bientôt être possible !
Ah, au passage, certains essaient de faire la même chose pour Eclipse PDT.







décembre 21st, 2009 at 05:40
I’m lucky, my computer works well with Windows Vista, Netbeans 6.8 and symfony 1.4. I have no problem.
décembre 21st, 2009 at 22:27
and I’m on XP… the problem is maybe here…
février 12th, 2010 at 10:52
J’ai eu une stratégie analogue en combinant Firefox, XDebug, Platypus, GreaseMonkey, Launchy et Gedit (qui accepte aussi le n° de ligne à l’ouverture, même syntaxe)
J’ouvre la page web, XDebug affiche (rarement
un ou des messages d’erreur (débutant par « ( ! ) », codé en dur dans le source de XDebug), GreaseMonkey transforme le chemin (cité par XDebug) du script en lien file:// en ajoutant
x à la fin de l’url (avec « xx » = n° de ligne), j’ai déclaré Gedit (ou NetBeans ou …) comme browser dans Launchy. Un simple clic-droit/menu_contextuel/Lauchy/Gedit et hop le tour est joué, on peut partir à la chasse au bogue. :-]
Platypus m’a permis de construire alarache le squelette du script GM (pas superclean, je n’ai pas pris le temps de purger les fonctions inutilement créées). La doc DOM du W3C et de MDC (MozDevCenter) de modifier un appel sur un nœud unique en boucle sur un ensemble de nœuds. J’ai déclaré localhost et 127.0.0.1 dans GreaseMonkey.
Plus simple à mettre à jour que de recompiler XDebug à chaque chgt de v° (pour lui faire faire apparaître le lien), qui avait été ma première idée.
On doit pouvoir faire de même avec les messages d’erreurs de php (cf le code source, printf(« … %s … « ) ) si on n’utilise pas Xdebug (c’est possible ? ;-] ).
En plus Launchy permet de déclarer plusieurs browsers, donc plusieurs éditeurs, si on est tantôt Vim^W Gedit tantôt Emacs^W Netbeans/Eclipse ! ;-]
function do_platypus_script() {
var nodesSnapshot = document.evaluate(
‘//th[contains(.,\'( ! )\')]‘,
document,
null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE,
null
);
for ( var i=0 ; i < nodesSnapshot.snapshotLength; i++ )
{
do_modify_html_it(
window.document,
nodesSnapshot.snapshotItem(i),
/in (.*) on line (.*)/,
‘in $1:$2‘,
null
);
};}
// Ends do_platypus_script