js, php et xhr : insertion xml
Une Bévue
le fichier "categories.php" :
<?php
header('Content-type: text/xml; charset=utf-8');
function add_li($doc, $ul, $idx, $name){
$li=$doc->createElement('li');
$li=$ul->appendChild($li);
$li->setAttribute('onclick', "load_items(this,
".$idx.");return false");
$li->nodeValue=$name;
return $li;
}
$doc=new DOMDocument('1.0', 'utf-8');
$doc->preserveWhiteSpace=true;
$ul=$doc->createElement('ul');
$ul=$doc->appendChild($ul);
$ul->setAttribute('class', 'categories');
$li=add_li($doc, $ul, "-1", "Toutes");
$db=new SQLite3('../../../landp.db');
$result=$db->query('SELECT * FROM categories;');
while ($row=$result->fetchArray()) {
$li=add_li($doc, $ul, $row['idx'], $row['name']);
}
echo $doc->saveXML();
?>
si, c�t� js, je l'inserre comme !a (avec responseXML) :
function load_categories() {
loadXMLDoc("php/categories.php",function() {
if (xmlhttp.readyState==4 && xmlhttp.status==200) {
document.getElementById("categories").innerHTML=xmlhttp.responseXML;
}
});
}
alors, au niveau de la fen�tre du butineur, j'obtiens :
[object Document]
est-ce que �a signifie que je dois l'inserrer comme un fragment :
document.getElementById('categories').appendChild(xmlhttp.responseXML);
???
bon par contre si dans le fichier "categories.php" je change juste le
header pour :
header('Content-type: text/html; charset=utf-8');
ie. "text/html" au lieu de "text/xml" et que l'insertion se fait par
responseText :
document.getElementById("categories").innerHTML=xmlhttp.responseText;
alors j'ai le "bon" r�sultat.
autrement dit, est-il possible d'inserrer une reponse xml venant de php
comme un fragment (x)html ou pas ?
--
� Si tous ceux qui n'ont rien n'en demandaient pas plus,
il serait bien facile de contenter tout le monde. �
(Coluche)
Une Bévue
> est-ce que ça signifie que je dois l'inserrer comme un fragment :
> document.getElementById('categories').appendChild(xmlhttp.responseXML);
> ???
je viens d'essayer, !a donne que dalle o[ !!!
j'apprends par ailleurs et par hasard que « the PHP DOM interface is
highly non-standard. » et que « The "user contributed notes" are the
most useful part of the manual! ». Ce dont j'ai fait l'expérience ne
serait-ce que pour obtenir un document xhtml avec des balises link pour
le css, il faut étendre la classe DOMDocument...
see <http://www.stylusstudio.com/xmldev/200203/post90230.html>.
donc, j'imagine que sauf info pertinente et contraire je dois en rester
avec "responseText" :
document.getElementById("categories").innerHTML=xmlhttp.responseText;
--
« France soir est un journal à grand tirage,
il est donc excellent pour allumer la cheminée. »
(Miguel de Cervantès)
Pascal Poncet
> est-ce que ça signifie que je dois l'inserrer comme un fragment :
> document.getElementById('categories').appendChild(xmlhttp.responseXML);
Non, justement, ce n'est pas un fragment, "responseXML" représente le
document entier, auquel il faut accéder par les méthodes et propriétés
du DOM.
Fais un console.log(xmlhttp.responseXML.nodeType) et tu obtiendras la
valeur 9 ... CQFD !
Donc, si tu veux récupérer tout le contenu du document, il faut aller
chercher son élément racine qui, lui-même, contient tous ses descendants.
La solution la plus courte et naturelle est d'aller chercher la
propriété "documentElement" de ta réponse.
(dis-donc, je croyais que c'était les doigts dans le nez... ;-) )
--
Cordialement,
Pascal
Une Bévue
> Non, justement, ce n'est pas un fragment, "responseXML" représente le
> document entier, auquel il faut accéder par les méthodes et propriétés
> du DOM.
> Fais un console.log(xmlhttp.responseXML.nodeType) et tu obtiendras la
> valeur 9 ... CQFD !
OK, merci pour le tuyau, je n'utilise pas assez ce "console.log"...
> Donc, si tu veux récupérer tout le contenu du document, il faut aller
> chercher son élément racine qui, lui-même, contient tous ses descendants.
>
> La solution la plus courte et naturelle est d'aller chercher la
> propriété "documentElement" de ta réponse.
OK
> (dis-donc, je croyais que c'était les doigts dans le nez... ;-) )
j'ai dit !a moi ?
j'étais assez présomptueux alors...
tiens, question : je dois inserrer dans une div d'id = item, un ensemble
d'éléments qui n'ont pas de "root", je veux dire, en html, ça se
présente comme ça :
<div ...
<span...
<span...
</div>
etc
<div ...
<span...
<span...
</div>
donc, pour que ce soit "xmlisable" j'ai wrappé tout ça dans une div d'id
item aussi, peut-être n'est-ce pas une bonne idée ?? (le même id)
aurais-tu une meilleure idée ?
--
« Il n'existe que deux choses infinies, l'univers et
la bêtise humaine... mais pour l'univers, je n'ai pas de
certitude absolue. »
(Albert Einstein)
Une Bévue
> donc, pour que ce soit "xmlisable" j'ai wrappé tout ça dans une div d'id
> item aussi, peut-être n'est-ce pas une bonne idée ?? (le même id)
bon, j'ai finale mis, pour cette div, id = tmp_item, de manière à avoir
des IDs uniques...
là, côté php, si j'envoie en text/xml,
console.log(xmlhttp.responseXML.nodeType);
me dis :
null
TypeError: Result of expression 'xmlhttp.responseXML' [null] is not an
object.
et :
console.log(xmlhttp.responseXML);
me dis :
null
TypeError: Result of expression 'xmlhttp.responseXML' [null] is not an
object.
ce que je ne comprends pas vu que, si j'envoie la réponse php en
text/html et que j'inserre la div d'id tmp_item, donc envoyée par le
php, dans la div existante d'id = item, j'obtiens le "bon" résultat.
Bien évidemment à la présentation près car le css n'est pas prévu pour
l'imbrication de div id = tmp_item dans div id = item...
je fais ça juste pour mettre au point.
donc, je ne pige pas ce qui se passe quand j'envoie par php en text/xml
et que je reçois en js par responseXML...
--
« Le temps est un grand maitre, dit-on. Le malheur est
qu'il tue ses élèves. »
(Berlioz)
Une Bévue
> donc, je ne pige pas ce qui se passe quand j'envoie par php en text/xml
> et que je reçois en js par responseXML...
bon, je viens de faire un nouvel essai, simplement en affichant à la
console :
console.log(xmlhttp.responseText);
au lieu de responseXML.
là, j'obtiens bien :
landp.js:50<?xml version="1.0" encoding="utf-8"?>
<div id="tmp_item"><div class="row_title">
...
</div></div>
ce qui était espéré, du coup, je comprends encore moins bien pourquoi
xmlhttp.responseXML est null.
à moins que ce soit ma dernière ligne de php qui soit fautive pour
envoyer du xml :
echo $doc->saveXML();
???
--
« Les femmes sont extrêmes ; elles sont meilleures ou pires que
les hommes. »
(Jean de La Bruyère)
SAM
>
> l�, j'obtiens bien :
> landp.js:50<?xml version="1.0" encoding="utf-8"?>
> <div id="tmp_item"><div class="row_title">
> ...
> </div></div>
donc tout est bien dans le meilleur des mondes, non ?
O� est le bl�me ? (finalement)
--
St�phane Moriaux avec/with iMac-intel
Pascal Poncet
> bon, je viens de faire un nouvel essai, simplement en affichant à la
> console :
> console.log(xmlhttp.responseText);
> au lieu de responseXML.
>
> là, j'obtiens bien :
> landp.js:50<?xml version="1.0" encoding="utf-8"?>
> <div id="tmp_item"><div class="row_title">
> ...
> </div></div>
Ok, mais je ne sais pas ce que tu emploies comme type de console.
Avec Firebug, tu vois facilement le source de ce qui est récupéré,
quelle que soit la façon, responseText ou responseXML.
En plus, il y a un onglet spécial "Réseau/XHR" pour ça.
Et puis, au-delà, je donne parfaitement raison à SAM.
Dans la mesure où, en réalité, tu pars d'un fragment HTML pour l'insérer
dans un document HTML, il n'y a aucune raison de passer par responseXML,
donc... pas de problème !
Même à la source, en PHP, je ne suis pas convaincu de la nécessité de
passer par des fonctions DOM pour pondre ton fragment.
Je rappelle que c'est un langage de template HTML natif.
Après, chacun y fait comme qu'y veut, mais faudra pas pleurer sur la
complexité.
--
Cordialement,
Pascal
SAM
>
> Et puis, au-del�, je donne parfaitement raison � SAM.
> Dans la mesure o�, en r�alit�, tu pars d'un fragment HTML pour l'ins�rer
> dans un document HTML, il n'y a aucune raison de passer par responseXML,
J'imagine qu'une fois le fragment ins�r� il est alors tout � fait
possible d'en exploiter sa repr�sentation DOM ?
Bon, peut-�tre pas avant qu'il ne soit effectivement et r�ellement ins�r� ?
(ex: on ne peut tenter d'obtenir les childNodes du responseText)
Une Bévue
> donc tout est bien dans le meilleur des mondes, non ?
>
> O� est le bl�me ? (finalement)
Euh; pour avoir ce r�sultat, il faut que je prenne :
xhr.responseText;
alors que, si j'ai bien compris, il faudrait prendre :
xhr.responseXML;non ???
--
� Les faiblesses des hommes font la force des femmes. �
(Voltaire)
Une Bévue
>
> Ok, mais je ne sais pas ce que tu emploies comme type de console.
> Avec Firebug, tu vois facilement le source de ce qui est récupéré,
> quelle que soit la façon, responseText ou responseXML.
> En plus, il y a un onglet spécial "Réseau/XHR" pour ça.
Ben, je n'ai pas Firebug, c'est à vérifier si je peux l'avoi ou pas sur
TenFourFoxG3 qui est un "Firefox" pour PPC, qui marche d'ailleurs pas
mal avec CSS3 et même certaines fonctions HTML5.
> Et puis, au-delà, je donne parfaitement raison à SAM.
> Dans la mesure où, en réalité, tu pars d'un fragment HTML pour l'insérer
> dans un document HTML, il n'y a aucune raison de passer par responseXML,
> donc... pas de problème !
Alors pourquoi je pense ça, c'est que je me suis entrainé avec des tutos
trouvés sur le web et, qu'avec un -- vrai -- fichier xml, ça marche
super. MAIS, comme je l'ai déjà mentionné, php est HORS standard...
Donc oui, je passerai par responseText...
> Même à la source, en PHP, je ne suis pas convaincu de la nécessité de
> passer par des fonctions DOM pour pondre ton fragment.
Là je suis d'accord de toutes façons le code php pour DOMDocument est
pourri en php, pour avoir une sortie xhtml; c'est galère.
> Je rappelle que c'est un langage de template HTML natif.
le php ? là je ne pige pas trop ton assertion "langage de template HTML
natif" ...
ce qui est absolument, sûr, je le dis même si je sais bien que je ne
suis pas informatien, c'est un langage mal conçu, très mal documenté, et
j'ai été content de le lire sous la plume de pro du xml, ce que je ne
suis pas.
pour résumer, le "xml" produit par php doit avoir qqc de spécial car
responseXML marche très bien avec un fichier xml "en dur", externe.
maintenant je ne tiens pas absolument à faire du DOM, je m'y suis mis
que -- pour essai -- et franchement là aussi il y a un truc pour
générer trois lignes de code html, il en faut au moins 10 en
DOMDocument...
où est l'efficacité ?
> Après, chacun y fait comme qu'y veut, mais faudra pas pleurer sur la
> complexité.
je ne pleure pas, j'essayais de savoir si qqc ne m'avait pas échappé...
Une Bévue
>
> J'imagine qu'une fois le fragment inséré il est alors tout à fait
> possible d'en exploiter sa représentation DOM ?
> Bon, peut-être pas avant qu'il ne soit effectivement et réellement inséré ?
> (ex: on ne peut tenter d'obtenir les childNodes du responseText)
Je n'ai pas eu le temps, de vérifier cela, je le ferai très bientôt.
--
« Il n'y a pas de hasards, il n'y a que des rendez-vous. »
(Paul Eluard)
Pascal Poncet
> J'imagine qu'une fois le fragment inséré il est alors tout à fait
> possible d'en exploiter sa représentation DOM ?
> (ex: on ne peut tenter d'obtenir les childNodes du responseText)
Exactement, et le véritable intérêt de responseXML est de disposer, non
pas d'une simple chaîne comme avec responseText, mais d'un arbre DOM que
l'on peut manipuler à loisir pour en extraire le contenu à insérer.
Typiquement, le contenu de responseText est utilisé avec innerHTML, qui
implémente un algorithme de linéarisation du fragment d'arbre DOM de
l'élément propriétaire.
Cette propriété est donc bien adaptée à ce type de traitement, beaucoup
plus simple mais avec moins de possibilités comme, effectivement, celle
qui permet de manipuler le contenu avant insertion.
--
Cordialement,
Pascal
Pascal Poncet
> Pascal Poncet<poncet.pas...@gmail.com.invalid> wrote:
>> Je rappelle que c'est un langage de template HTML natif.
>
> le php ? là je ne pige pas trop ton assertion "langage de template HTML
> natif" ...
>
Langage de template, parce qu'on peut passer des valeurs de variables et
écrire du code directement dans le source HTML, pour peu que le fichier
soit interprété avant d'être servi.
Natif, parce qu'il n'y a ni installation ni configuration particulière
pour disposer de cette fonctionnalité, et que c'était prévu pour ça et
comme ça dès l'origine.
> ce qui est absolument, sûr, je le dis même si je sais bien que je ne
> suis pas informatien, c'est un langage mal conçu, très mal documenté, et
> j'ai été content de le lire sous la plume de pro du xml, ce que je ne
> suis pas.
>
Limite troll, quand même !
L'immense communauté de développeurs et d'utilisateurs de ce langage
n'est pas une génération spontanée.
L'histoire a certainement commencée avec quelques bricolages, mais c'est
aujourd'hui un choix raisonné, foi de développeur, consultant et formateur.
> où est l'efficacité ?
>
Peut-être pas très forte, dans ton cas d'utilisation.
C'est pourquoi on te conseille de renoncer, et d'employer des méthodes
plus simples.
--
Cordialement,
Pascal
SAM
> SAM<stephanemor...@wanadoo.fr.invalid> wrote:
>
>> J'imagine qu'une fois le fragment inséré il est alors tout à fait
>> possible d'en exploiter sa représentation DOM ?
>> Bon, peut-être pas avant qu'il ne soit effectivement et réellement inséré ?
>> (ex: on ne peut tenter d'obtenir les childNodes du responseText)
>
> Je n'ai pas eu le temps, de vérifier cela, je le ferai très bientôt.
Tu ne te souviens pas de AdB2Html ?
--
Stéphane Moriaux avec/with iMac-intel
Une Bévue
> Tu ne te souviens pas de AdB2Html ?
je ne l'ai plus...
je crois bien avoir utilisé une transfo xslt ?
--
« L'amour est la sagesse du fou et la folie du sage. »
(Samuel Johnson)
Une Bévue
> Langage de template, parce qu'on peut passer des valeurs de variables et
> écrire du code directement dans le source HTML, pour peu que le fichier
> soit interprété avant d'être servi.
> Natif, parce qu'il n'y a ni installation ni configuration particulière
> pour disposer de cette fonctionnalité, et que c'était prévu pour ça et
> comme ça dès l'origine.
OK
> > ce qui est absolument, sûr, je le dis même si je sais bien que je ne
> > suis pas informatien, c'est un langage mal conçu, très mal documenté, et
> > j'ai été content de le lire sous la plume de pro du xml, ce que je ne
> > suis pas.
> >
>
> Limite troll, quand même !
> L'immense communauté de développeurs et d'utilisateurs de ce langage
> n'est pas une génération spontanée.
> L'histoire a certainement commencée avec quelques bricolages, mais c'est
> aujourd'hui un choix raisonné, foi de développeur, consultant et formateur.
Un choix raisonné, je suis d'accord.
> > où est l'efficacité ?
> >
>
> Peut-être pas très forte, dans ton cas d'utilisation.
> C'est pourquoi on te conseille de renoncer, et d'employer des méthodes
> plus simples.
ouais, c'est ce que je m'apprète à faire...