Utiliser en JS un champ récupèré via Ajax

Bonjour,

Voici mon soucis,

Pour les besoin d'une application Web, j'ai créer un petit script très simple qui se contente d'afficher un div au milieu de l'écran et d'aller chercher son contenu via Ajax.

Le contenu est généré par un code PHP.
Dans le contenu, il y à un formulaire et des champs de saisi que j'aimerai par la suite "submiter".

Ma fonction ajax récupère le contenu via responseText et le place dans le innerHTML de la Div représentant ma popin.

Le soucis est que lorsque je tente de valider le formulaire de ma popin (récupérer via ajax donc), ce dernier n'existe tout simplement par au niveau Javascript.
En effet, j'ai l'impression que JS n'interprète pas les éventuelles balise contenu dans une reponse Ajax et donc ne les ajoute pas à l'arbre DOM (d'ailleurs, FireBug, ne "voit" pas ce que Ajax ajoute au innerHTML de ma Div)

Du coup je ne sais pas trop comment faire pour pouvoir valider mon formulaire...

Je sais que certain me dirons d'utiliser jQuery (qui je crois peut faire ca), mais perso ca m'embète d'avoir à implémenter tout un code externe pour une fonctionnalité qui à priori doit etre reproductible (jQuery étant codé en JS)

J'ai aussi la possibilité de non pas générer un code "finis" avec mon PHP mais éventuelement la liste des champs de mon formulaire avec les valeurs dans un fichier XML puis de le parser en JS sur le callBack de la fonction Ajax pour faire des appendChild....sauf que j'aurai bien aimer que tout ceci soit générique....

Je me disait que j'avais peut etre moyen de faire une sorte de parseur de la responseText pour attacher les balises trouvées dedans à l'arbdre DOM, sauf qe je ne vois pas comment faire (pour les attachés sans les dupliquer)

Voila, bah si quelqu'un pouvait me retirer les noeuds au cerveau ca serait super sympa !

Merci

Si, le contenu inséré avec innerHTML est bien pris en compte dans le DOM.
Si ce n'est pas le cas pour toi, c'est que le soucis vient d'ailleurs et sans montrer le code en question, ce sera difficile d'en dire plus ;)

Bonjour Bovino,

Tout d'abord merci de ta réponse,

A vrai dire, le temps que tu me répondes, je venais de trouver ma solution :/
Alors, oui, tu as raison, le contenu du innerHTML est bien prit en compte par le DOM.

Là ou ca ne fonctionnait pas, c'est simplement parce que pour valider mon formulaire, je faisais un "document.MyForm.submit()" ce qui fonctionne dans un cas "normal" mais pas dans ce cas là. Cependant, en faisant plutôt un "document.forms['MyForm'].submit()" ca fonctionne...

Désolé pour ce post inutile (quoi que si quelqu'un d'autre à le meme soucis...), je le passe en résolu.

PS: si je n'ai pas poster d'emblée mon code, c'est simplement parce que j'utilise en plus de tout ca un framework php proprio, et soit je postais le code tel quel mais j'aurai certainement passer du temps à vous expliquer les différentes méthodes utilisées, soit je codais un exemple simple pour appuyer mes dires... j'avais un peu la flemme de le faire, mais c'était prévu si quelqu'un m'avait indiquer ne pas comprendre ma question.

Dans l'idéal, le serveur renvoie les données spécifiques de la requête sous leur forme la plus pure, non seulement par souci de bande passante mais aussi car ça permet de rendre l'application serveur plus souple. Par exemple, une application qui est utilisée par plusieurs sites ayant des chartes graphiques différentes.

C'est au script client de reconstruire le HTML adapté aux circonstances… Telle est ma vision des choses, et ce serait malhonnête de ma part de te conseiller une solution qui ne me plaît pas.

Utilise les méthodes createElement(), appendChild(), etc. du DOM. L'avantage c'est que tu as le contrôle total de la structure générée, tu ne laisses pas le navigateur gérer les détails à ta place (jamais faire confiance à la machine cliente), et ça te vomit pas des nœuds #text à chaque fois que tu as égaré des espaces blancs dans ton code.

Et tu verras qu'à force de scripter du DOM, on finit par apprécier le confort des frameworks comme jQuery ;)

Watilin,

Merci aussi de ta réponse, bien que j'ai clos le sujet, tu as pris la peine de me répondre alors je vais en faire autant ^^

Concernant ta remarque sur le fait de ne retourner en Ajax que le contenu et non le contenant, je ne suis plus tout à fait d'accord (je dis "plus" cas il n'y à pas si longtemps je me battais encore avec un pote en défendant la meme idée que toi...il se reconnaitra). En effet, l'excuse de la bande passante n'est plus vraiment valable de nos jours, à plus forte raison car je n'utilise de l'Ajax que dans le cas d'intranet ou WebApp pro et jamais sur un site public (plus généralement j'évite le JS sur un site public). Pour le coté "portabilité", là par contre je suis entièrement d'accord, à ceci près que mon code inclu ce coté portabilité au niveau du serveur. C'est mon framework php qui est en mesure de sélectionner le bon template en fonction du média (web, iphone, etc.) ou du type de client...dès lors la réponse donné est déja formater en fonction du client. Par ailleurs, et bien qu'effectivement des codes tels que jQuery soient très optimisé, il n'en reste pas moins qu'il sera tjs moins performant de demander au client de reconstruire un morceau de page à base de appendChild plutôt que de lui fournir directement le code.

Concernant jQuery, je suis un peu à contre courant là dessus, car j'ai vraiment beaucoup de mal à utiliser ces bibliothèque. Non pas que j'ai la prétention de faire mieux (certainement pas !), mais surtout parce que je ne vois pas pourquoi je devais demander à mon client de télécharger et interpréter une biblio énorme alors que je n'en utilise que quelques fonctions... j'ai vu des gens implémenter jQuery juste pour pouvoir faire un appel Ajax en 1 ligne...ok, c cool...mais pour faire cette ligne, l'interpréteur JS du client aura du se taper plusieurs centaines de lignes du code jQuery (à plus forte raison dans sa version compilée)
En gros, dans la mesure du possible je veux que dans mes codes il n'y ai que le strict nécessaire.
Sans compter que combien parmis les gens utilisant massivement le jQuery (je ne parle pas forcément pour toi, je ne te connais pas), savent modifier/corriger cette biblio ? En cas de problème, il faut attendre la communauté...on utilise un code, on le déploie sur un serveur sans même être certain de ce qu'il contient....voila un principe avec lequel j'ai du mal...(évidement je ne suis pas complètement stupide, s'il y avait du code malicieux dans jQuery, depuis le temps ca se saurait...c'est vrai pour la version officielle en tous cas....)

Tu ne seras probablement pas d'accord avec l'ensemble de mes arguments, mais au moins je répond à tes idées ;)

Oh yes, un troll naissant \o/

Ok, +1 pour l'argument de la bande passante, même si perso je suis pessimiste et je pense que la France va finir par s'aligner sur le Québec et la Belgique, où les FAI limitent la quantité de données échangées par mois sur l'abonnement Internet de l'utilisateur (comme c'est déjà le cas pour les serveurs).

Mais c'est aussi pour la beauté de la chose. Une donnée pure, dans sa forme la plus abstraite, évidemment c'est impossible, il y a toujours un format, une syntaxe (XML, JSON, DSL…) à respecter. Mais si on peut s'approcher…

Ensuite, c'est amusant que tu t'inquiètes de la taille d'une biblio quand elle est mise en cache (d'autant plus si elle est populaire), alors que les données envoyées par ton serveur sont très probablement variables. jQuery, dans sa version compactée (« minifiée »), ne pèse que quelques 66 Ko, et aura des chances de se trouver déjà dans le cache du visiteur s'il visite d'autres sites utilisant la même version.

Cela souligne d'ailleurs l'intérêt, pour la communauté, de ne pas sortir de nouvelles version trop souvent.

Quant à utiliser du code sans savoir ce qu'il y a dedans… J'ai eu longtemps du mal avec aussi, mais tant que c'est bien documenté… Et puis c'est pas comme si la source était tenue secrète.


Ce n'était que ma modeste contribution ;)