Une requête ajax, plusieurs <div> rafraichis

moijhd · 08-12-2012 10:57:25

Bonjour,

Généralement, on envoie une requète et on récupère du code HTML que l'on place par exemple dans le div que l'on veut. Comment fait-on si on veut récupérer plusieurs portions de code pour mettre dans différents div.

Mes solutions :
1. Retourner non pas du HTML mais un json avec plusieurs requètes à éxécuter pour rafraichir les différents div
2. Retourner un tableau javascript tab['id_div1'] = '<html>...'; tab['id_div2'] = '<html>...';

Aucune des deux solutions auxquelles j'ai pensées ne me plait.

Pouvez-vous me donner plus de méthodes ?

Merci !

PS : finalement la question porte sur la structure des données que l'on peut échanger.

J'ai eu d'autres idées tordues où je stocke dans une $_SESSION les paramètres des parties de page à afficher. Puis j'envoie une requète sur chaque div en créant un affichage suivant les paramètres de la session.

Dernière modification par moijhd (08-12-2012 11:01:23)

Maljuna Kris · 08-12-2012 11:13:32

Saluton,
A première vue la solution 2 me semble intéressante à explorer sauf que je verrais plutôt une structure XML, parce que retourner un tableau javascript via l'objet XHR, perso, je ne sais pas faire.
Mais, nul doute que nos grands spécialistes, Pierrot et Jc, auront des avis plus éclairés que le mien.

moijhd · 08-12-2012 11:22:52

Oui effectivement j'ai aussi envisagé une solution à base de XML. Appellons cette solution 3

J'avais d'ailleurs, il y a quelques temps, ouvert un sujet avec du XML et du XSLT : SQL => XML => XSLT & PHP => HTML. La conclusion était que le système était lourd en particulier parce qu'il fallait traduire le résultat d'une requète SQL en un document XML avant de pouvoir le transposer en HTML. Dans le cas présent, c'est toujours le cas. C'est l'une des raisons qui me poussait à vouloir renvoyer du HTML et non des données XML à transformer !

En résumé, le serveur retourne au client un code XML du style <root><data id='id_div1'>...</data ><data id='id_div2'>...</data ></root> puis du côté client on applique une transformation avec XSLT ?

Pour revenir à mon tableau javascript, la solution 2, disons que c'est un simple objet JSON dont les variables contiennent du HTML. Et la solution 1, c'est un objet JSON qui contient par exemple l'id d'un div et la référence d'une vue dans la session à récupérer (c'est pas très clair, je reviendrai dessus s'il y a des questions ).

Dernière modification par moijhd (08-12-2012 16:28:59)

moijhd · 08-12-2012 17:53:00

La solution 2 semble viable : http://stackoverflow.com/questions/2151 … -ajax-call et http://stackoverflow.com/questions/8988 … x-response (il suffisait de mettre les bons mots clés dans google )

Dernière modification par moijhd (08-12-2012 18:18:08)

Pierrot · 08-12-2012 21:41:35

>>parce que retourner un tableau javascript via l'objet XHR

echo json_encode ( $tabphp);

xml, c'est long et chiant

oui moijhd ces solutions son viables

a++

moijhd · 08-12-2012 22:10:08

En conclusion, je vais partir sur l'objet JSON comme dans les liens que j'ai donnés. En utilisant effectivement json_encode et ob_start() pour générer mon html depuis des include.

Dernière modification par moijhd (08-12-2012 23:15:56)

Pierrot · 09-12-2012 11:29:15

pk ob_start ????
a++

moijhd · 09-12-2012 11:35:01

J'avais un second problème : jusqu'à présent je générais la page compléte avec un système simple de template où j'incluais des fichiers. Dans la mesure où je veux pouvoir par exemple créer deux variables dans mon objet JSON, il fallait que je récupère le contenu de mon include dans une variable. C'est la solution que j'ai trouvé sur le net.

Plus précisément, à la place de

<?php

// ...

include('menu.phtml'); 

// ...

include('page.phtml');

//...

?>

j'ai

<?php

// ...

ob_start();

include('menu.phtml'); 

$tab['menu'] = ob_get_clean();

// ...

ob_start();

include('page.phtml');

$tab['page'] = ob_get_clean();

//...

echo json_encode($tab);

?>

Il me reste maintenant à générer par exemple le renouvellement ou non de la page ou du menu (ou de tout autre partie).

Dernière modification par moijhd (09-12-2012 11:40:25)

Pierrot · 09-12-2012 13:42:47

je vois que pas mal de monde commence à utiliser ajax
vé me sentir moins seul
a++

Jc · 09-12-2012 16:39:06

Bonjour,

@pierrot : Heureusement que je ne t'ai pas attendu pour développer des applis 100% ajax...

Sinon pour le reste
1) stocker ce qui relève de l'IHM en cache dans $_SESSION c'est n'importe quoi, donc la solution n'est pas à retenir en effet
2) Pierrot à raison que viens faire ob_start dans l'histoire??? aucun intérêt ici (dans le problème ennoncé)
3) L'objet JSON etant beaucoup plus léger que le XML, il est largement plus adapté dans tout traitement Ajax. De plus il reste natif donc pas de lib à installer inutilement pour parser du XML.

La façon la plus simple de gérer votre problème et en php de façon générale est de travailler à partir de tableaux associatifs. Il suffit d'associer à chaque dimension de votre tableau associatif les paramètres propres à chaque div à mettre à jour

exemple:

// code callback PHP

$params_div1=array();

$params_div2=array():

$output=array("div1"=>$params_div1,"div2"=>$params_div2);

print json_encode($output);

Petit rappel : on est en mode client-serveur : donc la priorité c'est d'optimiser la bande passante sur le réseau ainsi que les traitements serveur, donc on ne transmets pas de html pour la mise à jour avec un innerHTML à l'arrivée^^, mais on va chercher uniquement les valeurs à mettre à jour dans l'IHM sur le serveur (à condition que ces nouvelles valeurs soient inconnues au niveau du client).

Voilà ++

Dernière modification par Jc (09-12-2012 16:45:48)

moijhd · 09-12-2012 16:57:04

Donc ok pour la structure Solution 4 que nous prenons.

Je fais une requète SQL, j'obtiens un tableau PHP de résultats, j'applique la fonction json_encode à ce tableau, je récupère les données du côté client et...et comment je fais pour générer mon HTML et pour gérer un système de template en JSON !?

(
j'ai pas encore fait fini ma recherche google :
Solution 4.1 : côté client donc, transfomer le JSON en XML puis XSLT Je rigole déjà de cette solution
Solution 2 : c'est quand même assez facile les templates PHP...qu'est ce qui peut battre :

<html>

<table>

<?php

foreach($objets as $objet)

{

?>

<tr><td><?php echo $objet->tdValue;?></td></tr>

<?php

}

?>

</table>

</html>

ou alors à quel point est-ce mal ?

Et de la même façon, le template XSL est assez facile à gérer.

)

Dernière modification par moijhd (09-12-2012 19:28:31)

Jc · 10-12-2012 02:22:02

Bonjour,

Il ne faut pas confondre le chargement d'une page éventuellement complexe appelé par ton front controller et donc générée par PHP (attention cela peut aussi être fait par javascript dans certains cas), éventuellement par Template si ton appli tourne avec des templates PHP, et la mise à jour localisée de données en Ajax d'une page déjà chargée sur le poste client.

On ne travaille en JSON que lorsque javascript est l'initiateur de la requête serveur. Techniquement on peut le faire au chargement de la page, mais je ne suis pas convaincu des performances, faudra que je prenne d'ailleurs le temps de vérifier cela quand j'aurais un peu de temps libre.

C'est évident que cela nécessite des bases suffisantes en javascript pour manipuler le DOM correctement.

Sinon pour recharger un contenu à 90% de l'affichage par exemple en AJAX cela doit être fait avec précaution, car il faut s'assurer de ne pas dépasser quelques ko de requête serveur pour ne pas mettre un serveur à genou dans un contexte de forte charge.

++

EDIT: La question n'est pas de savoir qu'est ce qui peut battre quoi. Toutes les technos ont leur utilité, faut juste les utiliser quand elles sont les plus adaptées à une situation ou contrainte donnée et les utiliser pour ce dont elles ont été conçues dans la mesure du possible, c'est encore mieux. Après quand c'est le cas, c'est plus facile de faire l'impasse dessus quand on ne la maîtrise pas au risque de rendre le développement passable lourd et contre productif, que de se taper la techno pour faire les choses correctement.
Je t'invite aussi à consulter sur internet les différentes techniques de Template javascript et JQuery.
Je t'invite aussi à lire/relire un précédent post de ce forum qui peut te donner une approche orientée objet au niveau structure globale applicative en cliquant ici.

Dernière modification par Jc (10-12-2012 03:00:56)

moijhd · 10-12-2012 09:03:53

Si j'ai bien compris les premières lignes, si j'ai un nouvel affichage, je vais pouvoir utiliser la méthode 2 et si je veux mettre à jour l'affichage qui existe déjà je peux utiliser la méthode 4 et jouer avec DOM ?

Quant aux résultats sur les templates javascript j'en ressors un qui me plait plus que les autres : PURE qui permet de garder à la fois le HTML et l'objet JSON de data intact (en contre partie il y a un script d'adaption). C'est pour le cas où je voudrais générer une page en HTML entièrement du côté client.

Dernière modification par moijhd (10-12-2012 09:37:53)

Jc · 10-12-2012 13:57:35

Bonjour,

PURE est bien en effet, mais avis personnel pas pour tout. Pour te donner une idée, moi je construis toujours mes environnements en PHP et une fois dans l'environnement, je mets à jour le contenu en Js. Pourquoi? car jusqu'à maintenant dans mes réalisations une des contraintes constantes de mes clients a été que l'application réside côté serveur. La raison en est simple à mon avis. Travailler avec une application qui par exemple serait basée 100% sur PURE implique une "installation" sur le client des fichiers html applicatif, et si c'est pour faire ainsi les entreprises préfèrent encore travailler en mode compilé. Héritage du passé? bref peut être y viendra-t-on bientôt, en attendant cela nécessite une surcharge initiale car il faudrait vérifier dans un tel contexte que les fichiers html utilisés soient bien à jour au niveau version et que la mise à jour se fasse automatiquement lors de la connexion au serveur (login/mdp) du coup, la charge serveur est potentiellement plus importante et peu impacter l'expérience utilisateur selon si l'accès est de type intranet ou extranet/public.

++

EDIT
Note concernant la mise à jour, il faut relativiser car on peut intégrer cette gestion via un contrôle de cache avancé et l'utilisation d'un "manifest". On se rapproche donc étroitement des techniques utilisés sur des applis offline.

Dernière modification par Jc (10-12-2012 17:21:00)

tchvil · 10-12-2012 17:53:38

Salut Jc,

L'avantage du rendu client est en général:
HTML vide + JSON < HTML Rempli par le server

En Kb qui voyagent et en process serveur.

Le navigateur qui d'habitude n'a pas grand chose à faire qu'attendre la réponse, fait le rendu.
Libérant ton server de ce travail.

Ajoutes à cela la gestion normale de la cache des fichiers statiques: HTML/JS et CSS, comme tu le dis, mais pas avancée.
Ce que tu ne peux pas faire sur des HTML dynamiques venant du sever.

Et tu as une architecture très performante, aussi bien au niveau réseau, usage du server que vitesse de rendu.
Pour info, je suis l'auteur de pure.js, que nous avons écrit pour notre appli SaaS.
Tu peux l'essayer pour te faire une idée de la vitesse. Tout le rendu se fait au client.

Le gros point qui reste en faveur du rendu server, c'est le SEO.
Même si Google permet les hash tags, c'est plus fastidieux.

moijhd, n'hésite pas à me contacter si tu as des questions sur pure.js!

Dernière modification par tchvil (10-12-2012 17:56:56)

Jc · 10-12-2012 20:12:17

Bonjour et merci à tchvil pour son intervention,

Un autre aspect des choses qui me fait charger la page initiale en PHP, c'est que les techniques utilisées avec pure.js ainsi que la plupart des templates javascript, autorisent (théoriquement ou réellement) nativement l'accès à plusieurs SLD par injection de js dans la page (JSONP,..).

Le risque quand la page initiale et souvent de connection n'est pas générée par le serveur PHP, ce sont les problèmes de sécurité que cela peut poser avec la mise en place de fausses vraies pages sur le client etc... avec un cache désactivé pour le rechargement forcé de la page concernée.

Pour un intranet/extranet pure.js ne me pose pas vraiment de problèmes sur un plan architecture ni sécuritaire, mais sur un accès public authentifié dans un contexte où la page de connexion n'est pas générée par le serveur, je ne suis pas partisan de le préconiser, cela n'engage que moi on est bien d'accord.

Cordialement,

Jc

Dernière modification par Jc (10-12-2012 20:13:16)

tchvil · 10-12-2012 23:23:34

Jc,
Une page HTML statique ou PHP venant du serveur, offre le même degré de protection SOP(same origin policy).

Dans les deux cas, on peut ensuite appeler le même domaine par un appel AJAX.
Ou appeler un autre domaine par JSONP, et ce aux risques de l'utilisateur.

Le templating javascript n'intervient qu'après, quand le JSON est là.
Peu importe la manière utilisée.

Jc · 11-12-2012 03:24:10

Oui, vous avez raison,
si le html statique provient du serveur, ce qui est le cas pour pure.js, il n'y a aucun problème de sécurité, et je ne souhaitais pas semer la confusion concernant votre technologie sur ce point vis-à-vis des lecteurs de ce forum, veuillez m'en excuser.

Sinon promis, dès que j'ai un peu de temps je viens jeter un œil sur les performances de pure.js

Cordialement,

Jc

moijhd · 24-12-2012 15:36:44

Hey !

Un up pour que vous ne vous ennuyiez pas pendant les vacances : d'un point de vue formel, n'est-il pas génant d'avoir des directives du style "#{size.val} - #{size.name}" où d'une part le tiret devrait appartenir au template HTML et où d'autre part on est contraint d'utiliser des "variables" du style "#{xxx}" ?

Là où je veux en venir c'est que le tiret ne devrait pas faire parti des directives mais du template (et donc du code HTML) ? Le template HTML que l'on a est incomplet. De la même façon, j'ai l'impression que si l'on voulait par exemple ajouter un attribut du style name="element_id_XXXX" (où XXXX est un identifiant quelconque, une donnée), il faudrait dans les directives indiquer "element_id_XXXX" qui devrait, de mon point de vue, appartenir au fichier HTML.

Finalement, un template HTML qui fonctionnerait avec du Javascript et DOM serait contraint de ne pouvoir écrire que des attributs entièrement ou des données entre deux balises (setAttribute ou innerHTML).

Directives extraites de l'exemple 10 de PURE :

{

  "option": {

    "size <- sizes": {

      ".": "#{size.val} - #{size.name}",

      "@value": "size.val",

      "@selected": "size.sel"

    }

  }

}

Dernière modification par moijhd (24-12-2012 15:41:42)

tchvil · 24-12-2012 23:40:18

Salut moijhd,

Dans le cas d'un SELECT/OPTION c'est difficile de faire autrement, si tu veux vraiment un tiret entre val et name.
Par contre dans d'autre cas, tu pourrais effectivement être plus clean, et avoir le tiret dans le template, p.ex:
<span class="val"></span> - <span class="name"></span>

Pour un attribut tu peux utiliser la notation + pour faire une concaténation avec l'existant.
Le template:
<div id="element_id_"></div>

Et la directive:
'div@id+': 'element.id'

Qui donnerait, p.ex:
<div id="element_id_2345"></div>

moijhd · 24-12-2012 23:49:49

J'ai bien vu tout ça mais ça me plait pas ^^ (surement à tort)

tchvil · 24-12-2012 23:57:40

C'est finalement un choix. Tu peux garder une approche radicale qui respecte scrupuleusement le rôle des directives et du template.
Mais pour moi, un petit mix de temps en temps, c'est pas si grave, c'est simple et rapide.

moijhd · 13-01-2013 22:34:01

Bonsoir,

Je relance avec une question :

Il a été évoquée la récupération du HTML statique (et la cache). Comment est-ce que je récupère ce fichier HTML ?

Ma solution : mon serveur retourne un JSON avec data, directives, html statique et id de l'élément à modifier ?

Qu'en pensez-vous ?

PS1 : requète AJAX avec jQuery, PURE pour le rendu.
PS2 : plus précisément, je place le HTML statique dans un élément de la page, puis j'applique PURE sur cet élément avec data et directives.

Dernière modification par moijhd (13-01-2013 22:35:44)

tchvil · 14-01-2013 00:16:10

Pour notre appli, il y a une IFRAME qui charge dynamiquement les pages HTML+JS+CSS.

Ça peut paraître bizarre, mais ça laisse alors au browser le travail de charger les pages(avec cache), interpréter le JS et CSS.
Ensuite les noeud DOM du template, un objet javascript et les style CSS sont collectés, et insérés dans la page principale.

Il me semble que de cette manière on profite du parallèlisme qu'offre le browser a charger/interpréter plusieurs resources en même temps.
Alors que par ajax on est limité par javascript à un seul thread.

Il y a un post sur le forum avec un exemple similaire à ce que nous utilisons encore aujourd'hui:
https://groups.google.com/forum/#!msg/P … -5fclrVcoJ

Pierrot · 15-01-2013 10:54:25

pour info, je n'ai as bien compris le fonctionnement de PURE ????
existe il des tutos ?
Merci d'avance
a++

PHP|Débutant :: Forums

Advertisement

#1 08-12-2012 10:57:25

Une requête ajax, plusieurs <div> rafraichis

#2 08-12-2012 11:13:32

Re : Une requête ajax, plusieurs <div> rafraichis

#3 08-12-2012 11:22:52

Re : Une requête ajax, plusieurs <div> rafraichis

#4 08-12-2012 17:53:00

Re : Une requête ajax, plusieurs <div> rafraichis

#5 08-12-2012 21:41:35

Re : Une requête ajax, plusieurs <div> rafraichis

#6 08-12-2012 22:10:08

Re : Une requête ajax, plusieurs <div> rafraichis

#7 09-12-2012 11:29:15

Re : Une requête ajax, plusieurs <div> rafraichis

#8 09-12-2012 11:35:01

Re : Une requête ajax, plusieurs <div> rafraichis

#9 09-12-2012 13:42:47

Re : Une requête ajax, plusieurs <div> rafraichis

#10 09-12-2012 16:39:06

Re : Une requête ajax, plusieurs <div> rafraichis

#11 09-12-2012 16:57:04

Re : Une requête ajax, plusieurs <div> rafraichis

#12 10-12-2012 02:22:02

Re : Une requête ajax, plusieurs <div> rafraichis

#13 10-12-2012 09:03:53

Re : Une requête ajax, plusieurs <div> rafraichis

#14 10-12-2012 13:57:35

Re : Une requête ajax, plusieurs <div> rafraichis

#15 10-12-2012 17:53:38

Re : Une requête ajax, plusieurs <div> rafraichis

#16 10-12-2012 20:12:17

Re : Une requête ajax, plusieurs <div> rafraichis

#17 10-12-2012 23:23:34

Re : Une requête ajax, plusieurs <div> rafraichis

#18 11-12-2012 03:24:10

Re : Une requête ajax, plusieurs <div> rafraichis

#19 24-12-2012 15:36:44

Re : Une requête ajax, plusieurs <div> rafraichis

#20 24-12-2012 23:40:18

Re : Une requête ajax, plusieurs <div> rafraichis

#21 24-12-2012 23:49:49

Re : Une requête ajax, plusieurs <div> rafraichis

#22 24-12-2012 23:57:40

Re : Une requête ajax, plusieurs <div> rafraichis

#23 13-01-2013 22:34:01

Re : Une requête ajax, plusieurs <div> rafraichis

#24 14-01-2013 00:16:10

Re : Une requête ajax, plusieurs <div> rafraichis

#25 15-01-2013 10:54:25

Re : Une requête ajax, plusieurs <div> rafraichis

Pied de page des forums