11548 sujets

JavaScript, DOM et API Web HTML5

Bonjour !
Avec des bouts de codes rassemblés à partir de différentes sources, je tente de construire un parseur XML en Javascript avec XmlHttpRequest pour remplir une page HTML.
La partie qui permet d'importer le XML fonctionne, en revanche c'est au moment de le disséquer que je coince. La fonction qui devrait me permettre de le séparer suivant les balises ne veut pas même commencer à marcher.
Voici mon fichier .js :
function splitXml() /*C'est cette fonction qui ne marche pas :
 elle est appelée par la fonction suivante*/
{
	var actus = xhr.getElementsByTagName("actu");
	count = actus.length;
	alert(count);
	for (i=0; i<count; i++){
	}
}

function envoieRequete(url,id)
 {
     xhr = null;
     var position = id;
      if(window.XMLHttpRequest) xhr = new XMLHttpRequest();
      else if(window.ActiveXObject) {
		try {
			xhr = new ActiveXObject("Msxml2.XMLHTTP");
		} catch (e) {
			xhr = new ActiveXObject("Microsoft.XMLHTTP");
		}
	}
  
     // On ouvre la requete vers la page désirée
     xhr.open("GET", url, true);
     xhr.onreadystatechange = function(){
	 if ( xhr.readyState == 4){
	// j'affiche dans la DIV spécifiées le contenu retourné par le fichier > pour le test
        document.getElementById(id).innerHTML = xhr.responseText;
		splitXml();
     }
     }
     // dans le cas du get
     xhr.send(null);
  
 }


... et mon xml :
<?xml version="1.0" encoding="utf-8"?>
<actualites>
	<actu>
		<image>actu1.jpg</image>
		<texte>2006 | ARCHITECTURE-SYSTEM termine finaliste du concours international d&#8217;id&eacute;es pour la construction du Mus&eacute;e National d&#8217;Estonie.</texte>
	</actu>
	<actu>
		<image>actu2.jpg</image>
		<texte>2006 | ARCHITECTURE-SYSTEM est Laur&eacute;at des Nouveaux Albums des Jeunes Architectes 2005-2006.
		Cette nomination du Minist&egrave;re de la Culture et de la Communication r&eacute;compense, tous les 2 ans, une vingtaine d&#8217;agences d&#8217;architectes europ&eacute;ens de moins de 35 ans pour la qualit&eacute; de leur travail et leur potentiel d&#8217;avenir.</texte>
	</actu>
</actualites>


Le javascript est appelé onLoad dans le Html.
Pouvez-vous m'aider ?
Merci d'avance.
Modifié par SaluCseb (18 Aug 2006 - 21:36)
Pourquoi réinventer la roue ? XMLHttpRequest, comme son nom l'indique, permet normalement de récupérer des données formatées XML
Je me suis mal exprimé je crois ...
Ce que je veux faire, c'est utiliser mon contenu XML pour remplir une page HTML, donc extraire les données de mon arbre XML et les formater avec css dans mes balises HTML.
Je suis très débutant ... mon problème est-il cohérent ?
Modérateur
Bonsoir, Smiley cligne

a écrit :
Je suis très débutant ...
euh.. débutant comment ? Smiley rolleyes
... parce que ce que tu cherches à faire demande un minimum de connaissances... Si tu débutes réellement, ce n'est pas dit que tu vas comprendre... T'es quand même loin des notions de base là... Smiley sweatdrop

Bon, je te file deux liens qui seraient censé t'aider...

Tout d'abord, de quoi importer du XML dans du XHTML puis un petit cours de DOM pour définir ta structure... De là, tu pourras appliquer tes styles CSS sur le contenu généré...

Maintenant, il faut voir que ceci ne sera visible que pour ceux qui disposent du javascript. En fait, tu ne devrais pas te baser là-dessus... Cà sert plus de complément. Le mieux serait d'abord de créer un fichier XML auquel tu appliquerais une feuille de style XSLT via un processeur tel que Xalan ou Saxon pour générer ta page. ( cours de XML + Xalan )

... Je me trompe peut-être mais j'ai comme l'impression d'un grand flou là... Smiley confus
Modifié par koala64 (18 Aug 2006 - 22:26)
Merci koala,

Je crois qu'il faut que je potasse mon DOM. Je pense pas avoir trop de mal à comprendre ... en fait c'est en pratique que je suis très débutant, mais c'est pas la plus mince partie du programme. Je sais théoriquement ce qu'il faut que je fasse mais quand je code, ça se passe pas aussi bien.

Je pense que intégrer XML avec javascript est la meilleure solution à mon projet. Il s'agit d'implémenter seulement certaines parties d'un site html avec des données issues de XML, et ce site utilise déja pas mal de javascript. Et puis AJAX n'est plus si marginal donc xhtml + javascript me semble suffisament démocratique. Non ?

Conclusion, je crois que je reviendrai un peu plus tard quand j'aurais mieux digéré le DOM.
Modérateur
SaluCseb a écrit :
Je pense que intégrer XML avec javascript est la meilleure solution à mon projet. Il s'agit d'implémenter seulement certaines parties d'un site html avec des données issues de XML, et ce site utilise déja pas mal de javascript. Et puis AJAX n'est plus si marginal donc xhtml + javascript me semble suffisament démocratique. Non ?
ben non. Smiley ohwell Le problème n'est pas seulement d'apparaître correctement sur ton ordinateur mais aussi pour ceux qui se servent d'autres supports ou qui ont choisi de désactiver le Javascript. Ce qu'il faut comprendre, c'est que ton site doit, avant toute chose, être complètement fonctionnel sans le moindre code JS. Ce langage n'est qu'une surcouche mais ne doit pas être intrusif pour que tout le monde puisse accéder au contenu. Ajax est très à la mode en ce moment mais c'est là un exemple type de ce qu'il ne faut pas faire avec. Smiley cligne
De toute façon vu qu'il utilise XMLHttpRequest qui est déjà du javascript, il peut se lâcher sur une conversion de son XML en javascript.

Le mieux serait d'utiliser une feuille de styles xsl et de faire la transformation en javascript plutôt que de parser son résultat mais je sais plus comment on fait ;-(
Modifié par petit-ourson (19 Aug 2006 - 12:42)
Bonjour,

petit-ourson a écrit :
De toute façon vu qu'il utilise XMLHttpRequest qui est déjà du javascript, il peut se lâcher sur une conversion de son XML en javascript.


Certes. C'est déjà non accessible et inutile, donc autant continuer en se faisant plaisir Smiley cligne

ça se défend, remarquez... Smiley ravi
Administrateur
Bonjour,

pourquoi ce ne serait pas le serveur qui parserait ces fichiers XML via XSL(T) avant de les envoyer au navigateur? Ca évite d'envoyer des choses inutiles et fonctionnera dans bien plus de situations (configurations diverses et variées des navigateurs), non?
Modérateur
Salut,

oui, c'est ce qui me semble être le plus judicieux pour une plus grande compatibilité. L'emploi d'Ajax ne serait, à la rigueur, ajouté que pour accélérer le traitement et donc le confort d'utilisation. C'est optionnel mais pas la transformation côté serveur.
Vous avez sans doute raison, mais je ne suis pas programmeur de mon métier et les php et autres langages coté serveur sont bien plus complexes que le javascript et surtout me sont totalement étrangers.

Du coup j'en profite pour vous poser des petites questions à propos du débat pour ou contre généraliser l'emploi du javascript :
- qui désactive javascript sur son navigateur et pourquoi ?
- y a t'il un autre langage que javascript qui permette d'effectuer des requetes coté client ?
- quelles sont les faiblesses de javascript et comment pourrait on aller vers les possibilités qu'offre ajax sans javascript ?
- certaines personnes sur ce forum sont elles des inconditionnelles du javascript (comme je sais qu'il en existe ailleurs) et ont-elles des arguments pour en défendre une utilisation plus large ?

Mes questions sont surement un peu naïve mais je compte sur vous pour m'éclairer plus en profondeur.
Bonjour,

SaluCseb a écrit :

- qui désactive javascript sur son navigateur et pourquoi ?


En fait, la réponse à cette question n'est même pas nécessaire Smiley cligne

Javascript est en effet une couche technologique optionelle:
- que n'implémentent pas tous les agents utilisateurs. Ne pas oublier à ce propos que tous les agents utilisateurs ne sont pas des navigateurs Web, et que de nombreuses "machines" vont également avoir besoin d'accéder à ton contenu. Beaucoup n'implémentent pas js.
- que ne supportent pas de manière identique les navigateurs qui l'implémentent, en particulier pour des raisons de capacité de traitement.
- que l'utilisateur peut désactiver ou dont il peut limiter l'action, quelles qu'en soient les raisons.

Mais comme cette réponse serait un peu déroutante, disons rapidement que javascript n'est pas supporté, ou n'est que partiellement supporté, par exemple par:
- les robots d'indexation de moteurs de recherche
- les outils de traduction en ligne
- des applications d'aides à l'accessibilité (lecteurs d'écran en particulier)
- les navigateurs pour mobiles

Et que javascript peut être désactivé notamment:
- pour des raisons (justifiées ou non) liées à la sécurité
- pour des raisons liées à l'accessibilité (en réaction à des problèmes rencontrés par l'utilisateur sur des sites utilisant mal javascript, ce qui est fréquent)
- pour des raisons liées à une erreur de manipulation des paramètres du navigateurs (cas également fréquent)

Enfin, pour éviter un malentendu que traduit bien ta dernière question ("les arguments pour et contre javascripts"), il ne s'agit pas de trancher entre "utiliser js" et "ne pas utiliser js", et cette question de "pour ou contre" n'a guère de sens.

Tout comme les images par exemple, javascript ne pose aucun problème d'accessibilité ou autre dès lors:
- que le résultat peut être absent du document ou de l'interface finalement accédés par l'utilisateur, sans perte d'information, de navigabilité, etc. C'est l'équivalent des <img alt=""...>. Typiquement, un effet de rollover javascript sur un lien ne sera pas perceptible par différents utilisateurs, sans que cela ne pose aucun problème.
- ou qu'une alternative fonctionnelle sans javascript est présente. C'est l'équivalent des <img alt="retour à l'accueil" ...>.

Dans ton cas, fournir une alternative à js revient... à générer ton HTML côté serveur, ce qui rend le recours à js totalement inutile.

En revanche, js, comme toute technologie, pose toujours le problème de l'économie de moyen et de la solution la plus robuste :
- pour réaliser des effets de rollover, js est une solution beaucoup plus économique et fiable que CSS, et donc un bon choix dans de nombreux cas.
- pour réaliser une validation de données de formulaire, javascript est une solution très économique... mais insuffisamment robuste, et doit donc le plus souvent être doublé d'une validation côté serveur (des données non validées étant envoyées par les utilisateurs chez qui js n'est pas supporté ou activé).
- pour générer du contenu structuré comme tu souhaites le faire, javascript n'est pas une solution économique (ce sera beaucoup plus aisé à faire côté serveur) ni robuste (le résultat ne sera atteint que pour un nombre réduit d'utilisateurs)

SaluCseb a écrit :

- y a t'il un autre langage que javascript qui permette d'effectuer des requetes coté client ?


Il n'y en a pas (sauf des choses anecdotiques au support très limité).

SaluCseb a écrit :

- quelles sont les faiblesses de javascript et comment pourrait on aller vers les possibilités qu'offre ajax sans javascript ?


Pour les faiblesses, voir ci-dessus.
Mais surtout, cette notion (souvent évoquée ici) d'un "ajax sans javascript" repose sur un malentendu. Voir ce rappel de ce qu'est AJAX : par définition, AJAX repose sur un langage de script côté client pour la manipulation des données.

Pour conclure: le seul format unique et universel du Web est le HTML (le XHTML1.0 tel qu'il est utilisé aujourd'hui n'étant sur le fond que du HTML bien formé).
Bien-sûr, nous pourrons adresser un jour aux navigateurs (et autres UA) des documents reposant sur des formats XML moins limités (C'est le but de la standardisation). Mais nous n'en sommes pas encore là.
Modifié par Laurent Denis (20 Aug 2006 - 07:14)
a écrit :
Javascript est en effet une couche technologique optionelle:
- que n'implémentent pas tous les agents utilisateurs. Ne pas oublier à ce propos que tous les agents utilisateurs ne sont pas des navigateurs Web, et que de nombreuses "machines" vont également avoir besoin d'accéder à ton contenu. Beaucoup n'implémentent pas js.
- que ne supportent pas de manière identique les navigateurs qui l'implémentent, en particulier pour des raisons de capacité de traitement.
- que l'utilisateur peut désactiver ou dont il peut limiter l'action, quelles qu'en soient les raisons.

Déroutante ?! Pourquoi ?
Oui, le premier point peut être problématique, notament pour les moteurs de recherche. Quant aux deux autres ... je crois personnellement qu'ils se font rares (ça dépend aussi, probablement, du type de public que le site doit toucher).
a écrit :
Tout comme les images par exemple, javascript ne pose aucun problème d'accessibilité ou autre dès lors:
- que le résultat peut être absent du document ou de l'interface finalement accédés par l'utilisateur, sans perte d'information, de navigabilité, etc. C'est l'équivalent des <img alt=""...>. Typiquement, un effet de rollover javascript sur un lien ne sera pas perceptible par différents utilisateurs, sans que cela ne pose aucun problème.

Oui, mais bon ! On est plus à l'époque des navigateurs textuels. Moi quand je mets une image dans un site ce n'est généralement pas seulement pour décorer. Dans notre société, la communication par l'image a pris le pas sur celle par le texte et beaucoup de sites perdent leur sens sans les images.
Ensuite, une fois que tu as mis dans ton site des menus déroulants en javascript, pourquoi ne pas pousser le bouchon à fond (je ne parle pas, bien sur, des formulaires sécurisés ou autre données de ce types qui ont sans doute besoin de méthodes plus spécifiques). Encore une fois, le problème de l'accessibilité par les autres utilisateurs me parait obsolète.
a écrit :
Enfin, pour éviter un malentendu que traduit bien ta dernière question ("les arguments pour et contre javascripts"), il ne s'agit pas de trancher entre "utiliser js" et "ne pas utiliser js", et cette question de "pour ou contre" n'a guère de sens.

Il n'était pas question de malentendu dans ma dernière question. Je n'ai pas posé le problème en termes de "pour" ou "contre" javascript mais en terme de "pour, dans quelle mesure?". Je ne voulais pas aller droit au fait en demandant si le problème d'accessibilité était réellement ou non à prendre en compte.

Maintenant, où je suis complètement d'accord, c'est dans "l'économie de la solution" dont tu parles. Peut-être que j'aurais le temps de me mettre dans les mois à venir au coté serveur mais pour le moment ce n'est pas le cas. Donc, pour revenir à mon problème initial, je pense continuer dans la voie sur laquelle j'étais jusqu'à présent, non par mutisme mais par gain de temps.
PS : Je vais quand même regarder XSL qui m'a l'air accessible pour mes faibles connaissances, quite à l'intégrer ensuite avec javascript.
Modifié par SaluCseb (20 Aug 2006 - 15:32)
SaluCseb a écrit :
Encore une fois, le problème de l'accessibilité par les autres utilisateurs me parait obsolète.


Celle-là, on ne l'avait encore jamais faite Smiley ravi

Bonne continuation...
Modérateur
J'étais en train de rédiger un roman mais mieux vaut s'abstenir en effet... Smiley ohwell
Je n'arrive pas à rester correct tellement çà m'énnerve de lire des trucs pareils. Smiley decu
Tes propos sont graves SaluCseb; tu n'as rien compris de l'environnement dans lequel tu évolues (le web) et ce que tu viens de dire est un profond manque de respect envers les gens qui souffrent de handicaps... Visiblement, tu n'en as même pas conscience.
Plutôt que de te former correctement, tu veux aller vite... Tu cours au désastre, comme bon nombre avant toi.

++
Modifié par koala64 (20 Aug 2006 - 16:43)