IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

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


Sujet :

JavaScript

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Février 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 6
    Par défaut [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 : Sélectionner tout - Visualiser dans une fenêtre à part
    appendChild(texte) = toutmonHTML_avec_pleins_de_balises
    Merci d'avance pour vos réponses (j'apprends à programmer sur le tas),

  2. #2
    Membre éclairé Avatar de snipes
    Inscrit en
    Septembre 2004
    Messages
    547
    Détails du profil
    Informations forums :
    Inscription : Septembre 2004
    Messages : 547
    Par défaut
    Salut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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);
    Vive le DOM lol !

  3. #3
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Février 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 6
    Par défaut
    J'ai trouvé des infos
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    var parser = new DOMParser();
    var doc = parser.parseFromString(aStr, "text/xml");
    A bientôt,

  4. #4
    Membre émérite Avatar de Herode
    Homme Profil pro
    Développeur Web
    Inscrit en
    Mars 2005
    Messages
    825
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mars 2005
    Messages : 825
    Par défaut
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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.

  5. #5
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Février 2008
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2008
    Messages : 6
    Par défaut
    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.

  6. #6
    Invité de passage
    Profil pro
    Inscrit en
    Septembre 2008
    Messages
    1
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2008
    Messages : 1
    Par défaut
    le w3c a rajouté dans le DOM3: TextContent qui fait sensiblement la meme chose que le innerHTML

  7. #7
    Membre éclairé
    Inscrit en
    Octobre 2007
    Messages
    209
    Détails du profil
    Informations forums :
    Inscription : Octobre 2007
    Messages : 209
    Par défaut
    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

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [AJAX] cherche équivalent DOM-AJAX à .innerHTML
    Par spidflinch dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 09/01/2009, 17h36
  2. [DOM] [form] [ajax]compatibilité entre formulaire et ajax
    Par globz dans le forum Général JavaScript
    Réponses: 6
    Dernier message: 11/09/2008, 15h30
  3. [AJAX] Ajax, innerHTML et fonction javascript - solution ?
    Par gouroulubrik dans le forum Général JavaScript
    Réponses: 8
    Dernier message: 25/03/2008, 21h35
  4. [AJAX] innerHTML et IE
    Par gmonta31 dans le forum Général JavaScript
    Réponses: 4
    Dernier message: 16/05/2006, 11h12
  5. AJAX + Innerhtml + img => Bug sous IE
    Par GregPeck dans le forum Langage
    Réponses: 12
    Dernier message: 07/02/2006, 17h43

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo