[AJAX] innerHTML, compatibilité DOM et ajax..

Bonjour,
Je ne sais pas bien dans quel forum poster cette question, tant pis je me lance:

Dans des pages en PHP utilisant de l'ajax, je renvoie du serveur vers le client des "gros contenus" en HTML (genre boite de choix avec choix multiples, etc...).
Pour cela j'utilise "innerHTML" auquel j'affecte le code HTML reçu.

Mon problème est la compatibilité DOM: J'ai lu à plusieurs endroits que innerHTML n'était pas compatible DOM, qu'il fallait remplacer par les instructions comme createElement("p") ou appendChild(texte)...

L'objet de ma question est le suivant.
Pour rendre mon code compatible DOM, il faudrait que je parse dans mon script toute ma réponse HTML et que je fasse des createElement pour chaque objet, etc.... (j'ai des images, des inputs box, des paragraphes etc..)

N'existe-t-il pas une instruction remplaçant innerHTML ? ou alors des bibliothèques traitant tout le code HTML... ou alors je n'ai rien compris à la manière d'utiliser les instructions DOM (puis-je faire un:

Code:

---

appendChild(texte) = toutmonHTML_avec_pleins_de_balises

---

Merci d'avance pour vos réponses (j'apprends à programmer sur le tas),

Salut :yaisse2:
eh ben tu te trouves confronté a mon plus gros soucis : Faire une Appli qui utilise Ajax et qui respecte les normes W3C, DOM, ...
Utiliser innerHTML n'est pas recommandé (voir a exclure je pense sauf pour faire un truk a la va vite) car l'arborescence de ton site ne sera pas respecté et tu ne pourras donc pas effectuer de manipulations (sauf avec par bricolage...et j en suis meme pas sur) sur des elements (tel que des div , table, etc)que tu auras rajouté par le biais de innerHTML
Pour faire un truk dans les normes il faut que tu l as indiqué toi meme proceder en utilisant les proprietes du dom : createElement, appendChild ...

exemple pour la creation d'un tableau :

Code:

---

1 2 3 4 5 6 7 8

var table = document.createElement("table"); var tr = document.createElement('tr'); td = document.createElement('td'); txt = document.createTextNode("ce que tu ve"); td.appendChild(txt); tr.appendChild(td); table.appendChild(tr);

---

:king:Vive le DOM lol !

J'ai trouvé des infos là
Il est expliqué pourquoi on ne devrait plus utiliser innerHTML.
Par contre, c'est bien ce que je craignais: pour être compatible DOM, il faut écrire tout un script qui parse la réponse AJAX, quelque soit le format de cette réponse (voir discussion sur les formats possibles).

Sur ce coup là, je ne comprends pas la logique du W3C? Cela revient en gros à récrire son propre PARSER, forcémment incomplet et lent!?

Quoique dans Firefox, j'ai trouvé ce code: On a accès au parser (XML).

Code:

---

1 2	var parser = new DOMParser(); var doc = parser.parseFromString(aStr, "text/xml");

---

A bientôt,

Oui, mais le DOMParser() est, à ma connaissance, une extension non standard, tout comme innerHTML. Or, la critique majeure faite à innerHTML est que, étant non conforme aux standards,
1 - son implémentation est susceptible de varier d'un navigateur à l'autre (et elle le fait...)
2 - on n'a aucune garantie de cohérence et de continuité sur la durée.

Je ne pense pas que le recours au DOMParser() améliore les choses là-dessus, par conséquent.

Cela dit, on n'est pas obligé de choisir de coller aux standards : c'est un choix qui dépend de l'appli (taille, trafic, pro ou perso, etc...) A titre personnel, je colle aux standards pour pouvoir garantir à mes clients, autant que faire se peut, durée de vie et portabilité. Je passe donc par le DOM. Mais en ce cas, développer ou utiliser une bibliothèque de manipulation du DOM permet d'alléger considérablement le code tant il est vrai que le DOM est assez bavard. En outre, dans certains cas simples (éléments block ou inline ne contenant que du texte), j'utilise innerHTML malgré tout, sachant que tout est en place par ailleurs pour remplacer ces quelques lignes très facilement si, par improbable, une utilisation aussi minimaliste du innerHTML venait à poser problème.

Code:

---

Sur ce coup là, je ne comprends pas la logique du W3C? Cela revient en gros à ré-écrire son propre PARSER, forcémment incomplet et lent!?

---

Je ne sais pas quelles contraintes leur interdisent, jusqu'à présent, d'inclure le innerHTML dans le standard. Mais ré-écrire un parser pour analyser une responseText est certainement une mauvaise idée. Je vois plusieurs raisons à cela :

1 - si ton responseText contient des données structurées, alors c'est responseXML qu'il faut utiliser. Le contenu de responseXML étant un arbre XML/DOM, pas besoin de développer un parser, les fonctions de manipulation du DOM font l'affaire

2 - si ton responseText contient du code HTML + des données, alors tes traitements ne font sans doute pas la séparation Vue/Modèle (modèle de conception classique : MVC) qui est un classique à peu près incontournable du développement web. En ce cas, ton appli ou ton site web risquent de devenir très difficiles à maintenir. Je parle d'expérience, hélas : mon premier site web ignorait le modèle MVC et mélangeait récupération des données et mise en forme HTML. J'ai arrêté de le faire évoluer tellement les ajouts ou modifications devenaient longs et pénibles (et le code illisible...). Je ré-écris tout pour la v2. Si j'avais bien fait les choses, ma v2 aurait pu reprendre la majorité du code de la v1 et j'en aurais déjà fini. :?

Bonjour,
Merci,
Je ne connaissais pas le modèle MVC, j'ai un apprentissage pragmatique de la programmation et n'ai jamais eu de cours théorique.
Je suis à mi-chemin d'un modèle MVC: mes données sont stockées dans une base SQL, ensuite je les traite en fonction d'actions utilisateurs et je renvoie une réponse sous forme de code HTML. Ma mise en forme repose cependant sur du CSS. En fait, mon code HTML sert de contenant des données, c'est tout.
Voilà, merci encore pour ces éclaircissements.

le w3c a rajouté dans le DOM3: TextContent qui fait sensiblement la meme chose que le innerHTML

Bonjour,
Mon serveur PHP envoie suite à une requête POST AJAX du texte, des images et un script javascript.
Tout fonctionne sauf le script qui est ignoré.
Est-ce parce que j'utilise innerHTML ?
Si j'utilisais le DOM standard cela fonctionnerait davantage ?
Merci
JL