[resolu]EcmaScript et javascript

bonjour,

j'ai pas bine compris la différence entre ecmaScript et javascript...
ecmaScript possède jsute plus de possibilité que js?
Donc quand je fais du javascript je fais ecmaScript mais pas inversément?
J'ai également lu que ecmascript était du javascript standarisé, un peu comme ce qu'est le xhtml au html?

Mais alors quelles sont les choses interdites par ecmascript?
Tout cela est un peu confus pour moi, merci de m'éclairer!!!
Modifié par nath-0-0 (28 Nov 2005 - 15:18)

Bonjour,

Au départ était liveScript, un langage inventé en 1995 par netscape pour son navigateur.
Assez vite LiveScript fut rebaptisé "javascript" par Netscape pour "surfer", avec l'assentiment de SUN, sur la vague naissante de Java avec lequel il n'à d'ailleurs aucun rapport.

Quand Microsoft déclara la guerre totale à Netscape et accessoirement au web (mais c'est un autre sujet), il implémenta le Javascript de netscape auquel il rajouta une foultitude de fonctionnalité propriétaires, langage qu'il baptisa JScript.

A la guerre des navigateurs se rajouta la guerre des langages de scripts et à cette époque il fallait une sacré dose d'optimisme pour développer des scripts qui fonctionnent sur les deux plateformes.

EcmaScript est une tentative de normalisation de ces deux langages mené par l'organisation ECMA de standardisation.

EcmaScript reprends les noyaux des deux langages, fusionné en un tronc commun et débarassé de toutes les fonctions propriétaires, notamment celles qui s'appuie sur des particularités applicatives des navigateurs.

Donc chaque navigateur implémente ad-minima le support EcmaScript auquel ils rajoutent des fonctions et des méthodes particulières.

Javascript est le plus proche dans l'esprit et la règle de EcmaSacript, quand à JScript il dispose de fonctionnalités très poussées, certaines adorées des Hackers et auteur de virus, et d'autres comme XMLHttpRequest ou InnerHtml sont devenus des "standards de fait".

Donc quand tu fais du Javascript ou du JScript tu fais de l'EcmaScript.

En revanche quand tu utilises des fonctionnalités propriétaires, comme par exemple les possibilités d'accès au disque et fichier du client développés par JScript tu ne fais plus de l'EcmaScript...

Mais c'est vrai que c'est particulièrement confus, d'où une règle essentielle du développement de script : Tester la disponibilité des foontions et méthodes avant de les utiliser.

Jean-pierre

Alors là, jpv, tu m'en bouche un coin : je déduis de ton post que innerHTML et xhr ne sont pas standard ?

Bonjour,

Non, XMLHttpRequest est une "vieille" création du JScript de microsoft et n'à pas été reprise par EcmaScript, la mode AJAX l'à remise au goût du jour avec raison car c'est un objet vraiment pratique quand on n'en fait pas un usage immodéré.

Quand à innerHtml c'est la même chose, à ceci près que son utilisation est beaucoup plus discutable car cela permets de maintenir des sections de code HTML dans le code javascript ce qui est "interdis" par EcmaScript qui préconise le recours au DOM et à l'objet Node.

En revanche insérer un lien dynamique par exemple avec innerHtml se fait en une ligne là où il en faut 7 ou 8 avec l'objet node plus une petite gymnastique mentale, habituelle dés lors qu'on fait le singe dans l'arbre du document...

Jean-pierre
Modifié par jpv (24 Nov 2005 - 22:56)

ECMAScript normalise en fait le cœur de JavaScript, c’est à dire la structure même du langage (les structures de contrôles, mode de déclaration des variables, types de variables, les objets et méthodes standards comme Math ou encore Date, etc).

jpv a écrit :
... car cela permets de maintenir des sections de code HTML dans le code javascript ce qui est "interdis" par EcmaScript qui préconise le recours au DOM et à l'objet Node.

Ce n’est pas que c’est interdit, c’est plutôt qu’il n’y avait pas d’équivalent standard, tout simplement. Comme le DOM Core n’est pas bien difficile à manier, l’utilisation de innerHTML est la plupart du temps déconseillée pour des raisons de compatibilité.

Il y a d’ailleurs depuis l’année dernière (donc peu/pas encore implémenté) une alternative standard via le DOM Load & Save :

var parser = document.implementation.createLSParser(DOMImplementationLS.MODE_SYNCHRONOUS, null);
var input = document.implementation.createLSInput();
input.stringData = '<a href="http://domain.example/path/to/doc">blah</a>';
var linkNode = parser.parse(input);
// linkNode est maintenant un nœud valide et peut être utilisé dans une méthode d’insertion de nœud

Modifié par Bobe (24 Nov 2005 - 23:46)

Bonjour,

Merci Bobe de ces précisions.

Et il est vrai que j'avais oublié de mentionner le module DOM Load and Save, et merci pour ce petit exemple qui donne envie d'y rejeter un oeil, parce que la première fois, je t'avoue avoir choisis d'attendre qu'on m'explique...


Jean-pierre

Disons que innerHTML (et innerText) sont extrêmement pratiques quand il s'agit de récupérer du texte formaté en HTML. AVec le DOM, on est obligé de faire de la récursivité pour tout récupérer, ce qui finit par être vachement lourd.
innerHTML est aussi vachement pratique quand certains navigateurs (IE pour le pas donner son nom) lancent une "erreur d'exécution inconnue" à la suite de certaines manipulations du DOM.

Le W3C vient de mettre en place un groupe de travail concernant les API pour créer des applications à interfaces riches.

On devrait arriver à une standardisation officielle du XMLHttpRequest().
Pour InnerHtml et InnerText, ça n'est pas gagné, à mon avis.
Modifié par Lanza (25 Nov 2005 - 10:22)

QuentinC a écrit :
Disons que innerHTML (et innerText) sont extrêmement pratiques quand il s'agit de récupérer du texte formaté en HTML.

Pas de problème, le DOM LS ne se limite pas à parser des chaînes xml. On peut aussi sérialiser des documents ou fragments de documents:

var serializer = document.implementation.createLSSerializer();
var xmlstr     = serializer.writeToString(node);

QuentinC a écrit :
innerHTML est aussi vachement pratique quand certains navigateurs (IE pour le pas donner son nom) lancent une "erreur d'exécution inconnue" à la suite de certaines manipulations du DOM.

Tu peux donner des détails ?

"Lanza" a écrit :
Pour InnerHtml et InnerText, ça n'est pas gagné, à mon avis.

Comme déjà dit, le DOM LS est une alternative (ou le deviendra quand il sera suffisamment implémenté) à innerHTML, plus verbeuse, mais aussi plus puissante.

Pour innerText, il y a déjà un équivalent dans le DOM3 Core avec textContent:

var str = document.getElementById('example').textContent;
window.alert(str);
// Avec <div id="example">Petit texte d’<strong>exemple</strong> pour l’attribut textContent</div>

Modifié par Bobe (25 Nov 2005 - 17:40)

merci jpv pour ta première réponse, c'est bon là j'ai compris.

a écrit :
Mais c'est vrai que c'est particulièrement confus, d'où une règle essentielle du développement de script : Tester la disponibilité des foontions et méthodes avant de les utiliser.

tester la disponibilité des fonctions? Comment?? En essayant avec différents navigateur??
Donc c'est cela qui permet de savoir si on code bien ecmascript...

par contre pour le reste de la discussion, bein là je suis plus du tout du tout

pour quentin

a écrit :
Disons que innerHTML (et innerText) sont extrêmement pratiques quand il s'agit de récupérer du texte formaté en HTML

innerHtml cest quoi ce truc?pourquoi récupérer du texte formaté en HTML?

j'ai déjà acheté le livre de zeldman, j'ai pas fini de le lire mais il me semble pas qu'il parle de ces choses là....

Quel bouquin acheté pour être au courant de toutes ces choses?

DOM Core,DOM LS, XMLHttpRequest() c'est quoi cela?


Faut pas croire que je surfe pas sur le net pour trouver réponse à mes questions, mais bon c'est pas pour autant que je comprends.

Je suis pourtant pas totalement novice, j'ai fais du delphi,du c++ et autres langages pédagogique pour faire des algorithmes...
Mais là avec tous ces termes j'ai l'impression que c'est la jungle.
ET j'aimerais vraiment développer de manière le plus conforme possible ...

Merci aussi à tous les autres pour les commentaires...

nat > fais des recherches avec Google sur innerHTML, le nombre de résultats va se chiffrer en dizaines ou centaines de milliers je pense.

Sinon, textContent, ben je ne connaissais pas. Je n'ai pas encore testé mais je parie que ça ne marche pas sur (pourr)IE.

Concernnant mes "erreur d'exécution inconnue", l'erreur est malheureusement aussi inconnue que le code qui l'a provoquée. Si je refais du DOM et que je retombe sur cette erreur, je vous avertirai.