Version imprimable
Bien que le X de AJAX signifie XML, rien ne vous oblige à l'utiliser que XML. N'importe quel format de sérialisation texte permet de faire transiter des données via un appel JavaScript asynchrone.
Êtes-vous restés fidèles à XML ou bien avez-vous opté pour autre chose ? Et quoi ?
Au début j'utilisais exclusivement XML (quand je codais en java), mais je suis passé à JSON car c'est vrai que c'est plus rapide à écrire et que ca convient bien à l'usage que j'en fait (principalement de la sérialisation d'objets php).
Maintenant, XML reste toutefois bien utile lorsque la réponse à retourner au client est complexe et qu'on veut accéder seulement à certains éléments (via XPath par exemple).
Du JSON-Like :mrgreen:
(choix "Autre", donc)
Vu que j'ai commencé avant de connaitre l'existence de JSON, c'est de la sérialisation perso (généré via ASP) ...
Et donc tu ne bénéficies pas du support natif du JSON par JavaScript, tu es obligé d' "interprêter" ta chaine de caractères côté JavaScriptCitation:
Envoyé par E.Bzz
Voilà ...Citation:
Envoyé par khayyam90
Et si c'était à refaire, conserverais-tu ta sérialisation perso ?
"C'est refait" à chaque nouveau projet, et je ne suis toujours pas passé à JSON.Citation:
Envoyé par khayyam90
Ca viendra sûrement, mais pas de véritable besoin (ie : pas de cas ingérable autrement ou problème de perf) pour l'instant ...
Tout pareil que E.Bzz.
Même si je me rends bien compte de l'intérêt de JSON, je préfère formater moi-même mes réponses pour pouvoir construire mes objets (typiquement, mes fragments HTML) directement.
Une des raisons principales étant de m'abstenir d'utiliser des fonctions dérivant de eval.
Voilà qui est intéressant. Que reproches-tu aux fonctions dérivant de eval ?Citation:
Envoyé par Bovino
Elles sont réputées être peu performantes (du fait d'obliger de passer par une phase de compilation) et peu sures (ce n'est peut-être qu'une coïncidence, mais il se trouve que plusieurs discussions ont été ouvertes dernièrement concernant des sites hackés et il apparait qu'à chaque fois, le code malveillant utilise eval...)
Maintenant, j'avoue ne pas être suffisamment spécialiste du fonctionnement interne de JavaScript pour avoir un avis définitif sur la question.
La lenteur de eval vient du fait que c'est une interprétation qu'il faut faire à la volée. Mais bon, que tu utilises un flux JSON, XML ou perso, tu devras dans tous les cas interpréter ce flux pour en tirer les infos qui t'intéressent. Dans tous les cas quelqu'un doit s'y coller, toi ou l'interpréteur javascript.
L'histoire de la sécurité de ces fonctions c'est autre chose et si quelqu'un a des infos à ce sujet, ça serait très intéressant de les partager
J'utilise JSON, j'adore la facilité d'écriture et de lecture.
Je programme en asp.net dans lequel on peut sérialiser un objet typé en JSON. Un service web créé ainsi retourne un contenu du type "application/json; charset=utf-8" Je n'ai donc pas d'eval() à faire pour utiliser l'objet.
pas d'eval à faire ? tu peux préciser ? comment fais-tu côté client pour récupérer ton objet ?Citation:
Envoyé par franculo_caoulene
Et non c'était trop beau. D'après mes tests, .net doit faire un eval dans mon dos quelque part.
Mais bon c'est quand même assez bien fait.
Bonjour,
Pour ma part je suis passé d'une sérialisation perso à JSON depuis quelques
temps déjà. Voici mon avis sur les divers points discutés plus haut.
Fragment HTML et JSON:
Cela ne pause aucun problème, J'utilise souvent des réponse du type:
rep = { type: ..., data: ... }
type=0 signfie que data est un message d'alert à afficher avec alert(data);
type=1 signifie que data est un fragment HTML que je peux exploiter.
C'est assez pratique pour gérer les erreurs
Utilisation d'eval
Il est clair qu'on ne coupe pas à une forme d'évaluation coté client. Soit
par l'utilisation de la fonction eval, soit par l'insertion d'un script dans le
dom. (C'est cette deuxième approche qui est utilisée par JQuery).
Quant au risques, si l'on maitrise le coté client comme le coté serveur je
n'en vois pas. Sinon une regexp permet d'assurer que le contenu retourné
correspond à nos attentes avant l'évaluation.
Quant à la performance, je n'ai jamais rencontré de problème de ce coté
là, il me semble que le temps d'évaluation est totalement négligeable en
comparaison du temps de chargement, mais je suis à l'écoute si vous avez
des cas où cela poserait problème.
XML vs JSON
Comme la souligné DoubleU, XPATH est un avantage important pour opter
pour du XML, de même que le "clonage" de noeuds, vu la structure DOM.
Mais si c'est pour n'extraire qu'une partie de la réponse, je serai plus d'avis
de faire le filtrage coté serveur et ne renvoyer que le strict nécessaire.
(ok c'est pas forcement applicable dans tous les cas)
Un bon point pour JSON, c'est d'avoir la possibilité d'utiliser for(key in obj)
qui est vraiment pratique en comparaison avec ce que propose le DOM pour
traiter le XML.
En conclusion
Je crois pas qu'on puisse dire qu'une technique est
meilleure qu'une autre de manière absolue. Toutes ont leur raison d'être
( c'est beau je fais de la philosophie maintenant :mouarf: )
Avoir connaissance de toutes les techniques pour choisir la bonne au bon
moment me semble plus sage que de se limiter à utiliser celle qu'on
connait. (Faites ce que je dis, pas ce que je fais :mrgreen: )
la partie cliente de asp.net ajax utilise une méthode Sys.Serialization.JavaScriptSerializer.deserialize contenant un appel à eval.Citation:
Envoyé par franculo_caoulene
Comme quoi la sérialisation / désérialisation côté client est l'un des pilliers des appels AJAX. Car de la même manière, on peut poster une chaine JSON décrivant les paramètres GET / POST. On envoie un objet et on récupère aussi un objet.
JSON pour moi..
(je sais pas pourquoi,mais IE gérait très mal le XML.. (c'est peut-être du à l'émulation par wine vu que je suis sous nunux :aie:))