Hello,
Le soucis avec AJAX, c'est que c'est une "méta-technologie" qui repose sur pas mal d'autres. Avant de faire tourner asynchrone, il faut bien comprendre tout le circuit d'une requête synchrone, et avec Symfony, c'est pas forcément évident 
On va reprendre le circuit de ta requête, dans l'ordre, comme ça tu va voir les points qui ne vont pas :
1 - Tu as sur tes pages un lien comportant un appel javascript :
<a href="#" onclick="menu_ajax('<?php echo $entreprise->getId(); ?>','site') "><?php echo $entreprise->getNom() ; ?> </a>
Au clic, la fonction menu_ajax( ... ) va être appelée :
1
2
3
4
5
6
| function menu_ajax(id,table)
{
$.post("displayElements/MenuAjax", {myParam : id, myTable: table}, function(data) {
$('#fils').html(data);
} );
} |
Que fait cette fonction ? Elle envoie une requête POST vers l'url "displayElements/MenuAjax".
Premier problème, cette url n'est pas forcément valide : si tu changes d'environnement ou de serveur, tu risques d'avoir des surprises. Pour ma part, j'utilise la technique suivante : le passe l'url à atteindre en argument de ma fonction AJAX. Ce qui donne des choses comme
1
2
3
4
5
6
| function menu_ajax(url, id,table)
{
$.post(url, {myParam : id, myTable: table}, function(data) {
$('#fils').html(data);
} );
} |
et le lien :
<a href="#" onclick="menu_ajax('<?php echo url_for('@menuAjax') ?>', '<?php echo $entreprise->getId(); ?>','site') "><?php echo $entreprise->getNom() ; ?> </a>
Le reste de la fonction indique que le retour sera écrit dans le conteneur #fils, pour ça pas de problème, mais pour l'instant reprenons notre requête.
La requête POST est envoyée vers ton appli Symfony. A partir de là, il faut bien comprendre que ton appli, jusqu'à ce que tu lui indiques l'inverse, réagit comme pour une requête "normale", synchrone.
Tu dois donc, comme pour toute requête entrante, avoir une route prête à l'accueillir et à la renvoyer vers un couple action/module.
Par exemple, on peut imaginer quelque chose comme :
1
2
3
| menuAjax:
url: /menu/ajax-reload
params: { module: menu, action: menuAjax } |
A partir d'ici, il te faut une action (une route ne peut pas pointer vers un component)
Tu vas donc définir une action (ici dans mon exemple, l'action menuAjax dans le module menu) :
1
2
3
4
5
6
7
8
| class menuActions extends sfActions
{
public function executeMenuAjax()
{
...
}
} |
Arrivé là, Symfony va donc exécuter ton action, puis renvoyer vers le template menuAjaxSucces enrobé de ton layout, pour envoyer une réponse finale : une page entière ! Sauf que tu ne souhaites pas ce comportement. Il existe plusieurs manière de faire à ce niveau, pour ma part, je fais en général quelque chose comme :
1
2
3
4
5
6
7
8
9
| class menuActions extends sfActions
{
public function executeMenuAjax()
{
// ..... mon code d'action ....
// Et j'indique explicitement que je ne souhaite renvoyer qu'un partial, et non toute une page avec layout + template
return $this->renderPartial('menuAjax', array('param1', 'param2 ...));
}
} |
Tu n'as plus qu'à définir un partial, dans tonModule/templates/_menuAjax.php, qui contient ton code de vue (ton foreach donc).
Au final, Symfony te renvoie donc uniquement le code [html + params de ton action], qui est intercepté par ta fonction $.post de départ (ce retour se retrouve stocké dans "data") et placé dans un conteneur de ton choix .... ouf !
Ceci est bien sur une manière de faire de l'AJAX avec Symfony parmis tant d'autres, il y manque d'ailleurs beaucoup de choses (au niveau des contrôles principalement : quel est le type de requête ? Quel traitement si quelqu'un essaye de feinter ? Toutes ces choses sont importantes ). L'interêt est surtout de te montrer ceci : quand on fait de l'AJAX, le plus simple est de raisonner en terme de requête/réponse : retracer tout le circuit, bien définir ce que l'on souhaite obtenir et agir au bon endroit.
Bon, le café est coulé, maintenant j'vais me mettre à taffer un peu 
Bon courage à toi !
Requete Ajax sur onclick
Répondre avec citation
Envoyé par gototog
Partager