Discussion :

[jejeman]

Bonjour,

Je me mets de plus en plus à Symfony, mais je n'arrive pas encore à maitriser le debug... Je n'arrive pas toujours à suivre ce que fait mon appli, j'explique.
Je fais un template avec un form, quand on le submit, ça execute une action qui fait plein de chose et qui se redirige sur elle-même avec un redirect.
Pour vérifier si ca marche bien (et surtout parce que ca marche pas ) je voudrais afficher le contenu de certaines variables de mon action, mais je n'arrive pas à faire ça...
J'ai regarder la contenu du fichier log, ou je clique sur la barre de debug, mais je n'arrive pas à voir ce que je veux....
Pouvez-vous m'aider ?
Merci.

[Michel Rotta]

Le problème, dans tes tentatives de debug viennent de ton redirect. En effet, avec symfony, le redirect revient à redémarrer une nouvelle session de travail. Et réinitialise tous les objets, y compris le sfWebDebug qui enregistre ce que tu trouve sous la barre de débug.

Cette solution n'est donc pas envisageable, sauf si, dans ta logique applicative, tu peux remplacer ton redirect par un forward, qui, lui, reste dans la continuité de l'action.

Si tu restes sur ta structures, tu as plusieurs solutions, suivant le cas.

• A l'arrache, tu codes en dure un ou plusieurs echo, print_r() et, éventuellement, tu finis par un die(). Pas très propre ? non, mais terriblement efficace et simple à mettre en œuvre. De plus, pour explorer des tableaux ou des objets, le print_r est souvent la meilleur solution.
• A la mode symfony, a l'aide de l'objet sfLogger. L'avantage c'est que tu peux laisser ton code dans l'application, au pris d'une très légère pénalité en utilisation normal. Pour le faire, là où tu veux mettre quelque chose, tu vas faire un :
  $this->getLogger()->debug('MonMessage');
  A noter qu'il y a aussi possibilité de faire alert, crit, notice,... qui correspondent aux différents niveau d'importance du message.
  Ces messages, tu les retrouves dans la bare de debug, sous "other" ainsi que dans le fichier de log, ce qui permet de retrouver les messages qui aurait été passé avant un redirect.
• Dernière méthode, la rolls, le xdebug correctement configuré (je ne suis pas sur que cela soit possible, je n'y suis jamais arrivé), qui te permet d'avoir du debug "in direct live" dans ton éditeur. Accessoirement, un xdebug même mal configuré permet d'enrichir les messages d'erreur notablement et de mieux les comprendre. (Si quelqu'un à une vraiment bonne doc sur l'utilisation de xdebug, j'achète.).

[Vivian Pennel]

Le mieux est d'utiliser Xdebug effectivement.
Pas spécialement eu de problèmes pour l'utiliser avec EclipsePDT, voir documentation

[Michel Rotta]

J'ai peu de bêtes noires, XDebug en fait partie.

N'a jamais marché ni sous Eclipse, ni sous Netbeans que j'utilise maintenant.

Pourtant, il est bien installé et enrichi largement les messages d'erreur.

Quant aux tutoriel pour l'installer, j'ai bien dû en essayer 15, ils sont tous déférents et les paramètres sont tous différents suivant les tutoriels, j'ai décidé de ne plus y toucher avant quelques mois...

Maintenant, si quelqu'un connait bien, j'ouvre un sujet dédié et serais enchanté d'être guidé.

[jejeman]

Merci pour vos réponses...
Le Logmessage n'est pas mal...
Mais le print suivi du die reste quand même plus efficace....
Sinon je vais essayer de regarder de plus près le debug en direct avec eclipse. Mon souci est que je bosse sous windows avec eclipse et que mon serveur web est sous linux a cote... donc je sais pas trop comment faire... sinon faire tourner un wamp...

[Michel Rotta]

oui, le print et le die. j'avoue, j'aime aussi.

Il est possible (en théorie) d'avoir le xdebug qui tourne sur une autre machine, faut juste trouver les bons paramètres, et vu mon affinité avec le xdebug...

[yohann007]

Bonjour,

Je commence symfony et je n'arrive pas à installer la toolbar qui pourrai mettre utile je pense vu que j'ai commencer à developper sans et c'est horrible je n'ai aucun message quand je vais sur le fichier frontend_dev.php il me met :

Fatal error: Cannot instantiate abstract class sfWebDebugPanel in /Users/yohann/Sites/sfproject/apps/frontend/config/frontendConfiguration.class.php on line 15

apres dans le fichier frontendConfiguration j'ai ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
<?php
 
class frontendConfiguration extends sfApplicationConfiguration
{
 
  public function configure()
  {
   $this->dispatcher->connect('debug.web.load_panels', array($this, 'configureWebDebugToolbar'));
  }
 
  public function configureWebDebugToolbar(sfEvent $event)
  {
    $webDebugToolbar = $event->getSubject();
 
    $webDebugToolbar->setPanel('panel', new sfWebDebugPanel($webDebugToolbar));
  }
}
?>

[bilbonec]

Pour répondre à Yohann :
je n'ai jamais cherché à paramétrer moi-même dans le code la toolbar, du coup, je n'ai pas de solution alternative à te proposer pour ton problème.

Cependant, concernant l'erreur, il s'agit d'une pure question de programmation objet :
- un objet abstrait ne peut pas être instancié.

Puisque sfWebDebugPanel est une classe abstraite, tu ne peux pas l'instancier.

EDIT

Peut-être une piste néanmoins :
(nb : oui, j'aime les ctrl+f brutaux sur tout le code d'un framework )

En faisant une recherche dans le code Symfony sur "extends sfWebDebugPanel", tu peux voir une liste des classes (non abstraites cette fois-ci) qui étendent sfWebDebugPanel et que tu peux instancier :
- sfWebDebugPanelCache ;
- sfWebDebugPanelConfig ;
- sfWebDebugPanelLogs ;
- sfWebDebugPanelMailer ;
- etc.

Du coup, tu dois pouvoir achever le même boulot sur l'une des classes enfants.

[Michel Rotta]

@yohann007

Et partir simplement sur une URL de la forme :
www.monAppli.com/frontend_dev.php/chemin

Avec ceci, la barre de debug, seul, devrait arriver.