Discussion:Ajax (informatique)

tres bon article, juste un mauvais point: l'exemple du tri. sans ajax, javascript peut trier (puisqu'il trie aussi avec, soyons logique) un exemple plus clair serait une page qui affiche que dix enregistrement d'une base de données, et qui demande les autres enregistrement (quand on appuie sur suivant) par ajax.

Homonymes

Étant donné les différents homonymes d'AJAX, je propose que cet article soit renommé en AJAX_(informatique) ou quelque chose de ce genre.

Ajax côté serveur / Programmation et Ajax

"Côté serveur, le principe même d'Ajax implique que le choix de la technologie soit libre."

WTF? La technologie employée côté serveur ne change rien, on peut faire de l'ajax avec un serveur .net, java ou autre, l'essentiel c'est que l'on s'adresse à lui par HTTP et que celui-ci nous crache du (X)HTML, du XML, du JSON, ou n'importe quel autre format, d'ailleurs. Ce qu'il se passe derrière, côté serveur, n'a aucune éspèce d'importance.

A propos de la page AJAX

Je viens de modifier la page AJAX et je vois que mes changements ont été révoqués. Je les crois cependant justifiés.

- J'ai viré quelques blogs en anglais parceque je rappelle qu'on est dans la version française du Wikipédia. Ceux qui veulent (et savent) lire l'anglais vont dans la partie anglaise. D'ailleurs l'intérêt de ces blogs n'est pas évident dans une encyclopédie.

- J'ai viré un site commercial qui venait faire sa promo.

- J'ai viré des "exemples en Ajax". Je suis désolé, mais si on laisse afficher les "exemples" d'applications, non conçus dans un but didacticiel, il y aura 10000 liens de plus sur AJAX. Et les exemples de programmes en C, C++, Python, etc sur les pages de ces langages... Les exemples de n'importe quoi en fait.

Le page AJAX concerne le format, et tout ce qui instruit sur le format. Les applications et exemples d'applications (non didactiques, je précise) ne sont pas pertinents. Ce que je veux dire, c'est que dans la rubrique "Exemples d'application", il y a une quantité de sites qui parlent de n'importe quoi et qui mettent un lien sur leur page d'accueil sous prétexte qu'elle utilise la technologie AJAX. L'abus me semble manifeste.

Donc, même si mes coupures semblent brutales, elles sont justifiées. D'ailleurs j'étais venu sur cette page il y a quelques jours, et tout cela n'y figurait pas... Cela prolifère très vite.

Cordialement.

Donc, je les supprime bien...

Après lecture des messages sur la page perso de "Le Gorille", je pense qu'il est acquis que ces suppressions étaient nécessaires pour la bonne tenue de Wikipedia. Je supprime donc "Exemples de sites AJAX".

Notez que si on faisait dans la page HTML une rubrique "Exemples de sites HTML", il y en aurait un paquet!!!

Je supprime aussi les blogs en anglais qui ne sont pas d'une grande utilité pour les lecteurs français (ils ne figurent même pas dans la partie anglaise).

Je supprime le lien "Ajax sans XMLHTTPRequest" parcequ'il se trouve que justement, AJAX, c'est XMLHTTPRequest + JavaScript. Si on supprime XMLetc... ce n'est plus que JavaScript!!!

A propos du lien AHAH

Peut-être intéressant en soi cette alternative à AJAX. Seulement d'une part, cette page est consacrée à AJAX, d'autre part c'est en anglais. Sauf avis contraire je propose de supprimer ce lien.

Descartes 5 mars 2006 à 09:30 (CET)

D'autant plus d'accord que j'ai testé le script et qu'il ne fonctionne pas! Alcalazar 25 avril 2006 à 13:27 (CEST)

AjaxPatterns

http://ajaxpatterns.org/

Je suis d'accord sur le fait d'avoir enlevé des liens d'exemples un peu trop nombreux je l'accord. Ceci dit, vous avez aussi enlever ajaxpatterns qui est un wiki ( en anglais :/ ), mais très complet d'ajax. C'est d'ailleur la bas que j'ai trouver de très bonnes pages de serveurs, de clients, d'explications et d'exemples :p Si il y a un lien à ne pas enlever, je crois que c'est celui la, malgré le fait qu'il soit en anglais.

Je rajoute aussi ceci, Pour les liens client et serveurs. Le probleme avec Ajax c'est qu'il ne se dégage pas vraiment deux ou trois frameworks meilleurs que d'autres. Il est donc très difficile de faire une selection parmis les multiples clients et les multiples serveurs qui ont en plus chaqu'un leur spécificité. Le seul site que j'ai trouvé qui recence la pluspart d'entre eux est ajaxpatterns. ( quand j'ai imprimé sur papier la page de server, je crois que ca a tenu sur 5 ou 6 pages .. )

Maintenant, à vous de voir si vous voulez montrer quelques exemples de clients et quelques exemples de serveur, parceque finalement c'est bien ca qui se passe, ou si vous voulez les recenser toutes, ou bien si vous voulez laisser le travail à un autre wiki spécialisé ... ( je ne connais pas la réponse à cette question )

Elendrim - 14 mars 2006

Ajaxpatterns à la défaut de n'être pas sérieusement modéré: il y a des quantités de pages sur n'importe quel sujet et surtout un nombre invraissemblable de liens sur des sites commerciaux pour la plupart. Wikipédia se doit de donner au lecteur des références sérieuses. Descartes 17 avril 2006 à 07:51 (CEST)

Librairies JavaScript

Je pense que l'on peut mettre un lien sur les librairies JavaScript conçue pour créer des pages Ajax.
Tandis que les scripts qui "pourraient" faciliter la création de page Ajax, et qui ne sont pas conçues dans ce but, doivent être liées à la page JavaScript uniquement, si elles ont un intérêt général. Descartes 2 mai 2006 à 14:39 (CEST) Maintenant que l'article Cadre d'Application AJAX est créé, ceci n'est plus d'actualité. Descartes 1 août 2006 à 13:17 (CEST)

AJAX but no javascript

Je ne voudrais pas critiquer mais http://www.potix.com/zkdemo/userguide/ utilise pas mal de javascript... donc la short description ne ma parait pas claire, à expliquer. Ripounet 30 mai 2006 à 13:03 (CEST)

Petite erreur dans l'article

L'article précise "S'il utilise Internet Explorer 5 ou 6 pour Windows, il doit aussi autoriser les ActiveX" En fait IE 6 integre nativement xmlHttpRequest, il est donc inutile d'autoriser les activex pour IE6

Renommer l'article?

L'article devrait s'appeller Asynchronous JavaScript And XML, non? (Wikipédia:Conventions sur les titres) L'ideal serait peut etre que l'article AJAX soit la page d'homonymie, mais il faudrait modifier toutes les pages qui parlent d'AJAX? Piglop 6 août 2006 à 22:54 (CEST)

Entièrement d'accord. Faisons la chasse aux acronymes et autres abréviations dans les titres d'articles. :)

Je pense qu'on peut dans un premier temps renommer la page, puis demander à un robot de changer toutes les occurrences d'« [[AJAX]] » en « [[Asynchronous JavaScript And XML]] ». Après, AJAX (en capitales) peut rester une redirection vers Asynchronous JavaScript And XML, comme la page d'homonymie Ajax existe déjà (et que l'AJAX du domaine de la programmation est le seul acronyme qui y figure). JB ✉ 12 août 2006 à 21:27 (CEST)

Juste un bot qui passait par là par accident. Zyxwvut-Bot 13 août 2006 à 09:20 (CEST)

liens externes utiles

Bonjour,

Il est très regrettable que les actuels conflits d'édition et querelles de personnes autour de cet article fasse disparaître des liens externes pertinents et justifiés. Notamment la traduction française du document de travail W3C http://www.xul.fr/XMLHttpRequest.html . --Laurent Denis 12 août 2006 à 14:27 (CEST)

Erreur dans l'article !

Développeur web de profession, j'ai constaté une erreur dans l'article. Il y est dit "à l'instar de DHTML ou de LAMP, AJAX n'est pas une technologie".

Je tiens à souligner le fait que le DHTML (pour "Dynamic HTML") n'est pas une technologie non plus. Le DHTML n'est que l'utilisation de Javascript, CSS, et HTML (qui sont des technologies). Ce n'est donc pas une technologie mais juste un groupement de 3 technologies.

C'est bien ce qui est dit dans l'article : "À l'image de DHTML ou de LAMP, AJAX n'est pas une technologie". Aucun de ces terme ne désigne une technologie. Peut etre que c'est mal dit et qu'on peut reformuler? Piglop 24 août 2006 à 11:55 (CEST)

Hmmm ... Reformuler ? Pas forcément. Sauf si l'auteur de ce commentaire à mal compris le sens de "à l'instar de" ( = "comme"), ou n'a pas fait attention. Toutefois, étant donné que le sens de "à l'instar de" est souvent mal interprété, peut-être pourrait-on remplacer "à l'instar de" par "tout comme" ? Aeolian 24 août 2006 à 13:42 (CEST)

l'ESSENTIEL est oublié

mon avis est :

- Cette technologie s'appuie sur des standards ouverts ! (inutile d'argumenter sur l'importance ni la force des standards ouverts) - Il est inutile de parler de navigateurs ie5 vu la politique de telechargement tres facile et largement favorisée ! - Les technologies concurentes (Flash et java) sont bien moins sécurisées que javascript et considérablement plus dangereuses. - Les moteurs de recherche récents sont a même d'intégrer javascript et de suivre ainsi les sites dynamiques, de toutes façons un site peut choisir ce qui lui parait utile d'être référencé.

conclusion : article faible, très subjectif, orienté.

Lancez-vous... Vanished2012 20 décembre 2006 à 15:13 (CET)

L'article explique les inconvénients d'ajax sans les comparer aux inconvénients des technologies alternatives. Les trous de sécurité dans flash ou java sont autrement potentiellement dangereux que dans javascript. De plus ce sont des technologies propriétaires et j'aimerais enfoncer la vis à ce propos : qui peut imaginer que les pas de vis dépendent d'un brevet? Qui peux croire que dans le futur une société puisse être capable de détenir les clefs de la communication par ordinateur, il me semble évident que c'est un bien aussi commun que les chiffres.

"Cette technologie s'appuie sur des standards ouverts !"
Hum, hum. L'objet XMLHttprequest a été développé par Microsoft, et ne fait pas à l'heure actuelle partie des recommandations du w3c.

Joli mais faux (biais d'appariement?), comparons ce qui est comparable, AJAX avec flash, silverlight, java ou n'importe quel plugin propriétaire. L'objet XMLtruc existe depuis si longtemps qu'il a été copié et installé sur tous les navigateurs devenant un standard de fait. De plus ce n'est pas l'unique outil pour faire du AJAX, il existe d'autres techniques n'utilisant pas cet objet. L'article général montre un point de vu subjectif notoire, AJAX n'est pas comparé à du comparable, et ses défauts n'en sont pas car les objets équivalents ont les mêmes et souvent pires (la sécurité par exemple). Concernant le référencement, mais il va de soi que celui qui sait construire un site AJAX est capable de nourrir les robots de ce dont ils ont besoin.

Tutos Ajax

Faut-il des tutos Ajax ou non? Je constate qu'il y a en dix sur la page JavaScript. J'aimerais avoir l'avis des contributeurs. Lanatur 2 mars 2007 à 23:08 (CET)

AMHA, la page JavaScript contient bien trop de liens externes, si bien que la section, surchargée, est devenue difficile à consulter et une vrai porte ouverte au spam. L'article AJAX est régulièrement sujet à ce genre d'ajouts publicitaires. Toujours AMHA, le but d'une encyclopédie est d'expliquer « ce que c'est » et pas « comment faire », ce qui exclue les tutoriels. Un bon lien externe est un lien vers un site de référence, un article publié par un spécialiste reconnu, etc. Par exemple, l'article allemand contient deux liens externes : une documentation issue de developer.mozilla.org et un portail sur Ajax + un livre sur le sujet (publié aux éditions O'Reilly) ; on peut difficilement faire mieux. Les tutoriels sont le plus souvent des documents de « seconde main », de qualité variable, et sont loin d'être indispensable pour compléter l'article → leur place est sur un annuaire Web (ce que n'est pas Wikipédia), le lien dmoz étant là pour aider les lecteurs égarés ainsi que ceux qui veulent aller au delà de la simple connaissance du sujet (à leurs risques et périls ). Jérémie • JB✉ 4 mars 2007 à 19:00 (CET).

Konqueror ????

Les applications AJAX peuvent être utilisées au sein des navigateurs Web qui supportent les technologies décrites précédemment. Parmi eux, on trouve Mozilla, Firefox, Internet Explorer, Konqueror, Safari ou encore Opera.

Euh... "Bonjour" tout d'abord, et "En êtes vous sûr ?" ensuite .

Perso, la dernière fois que j'ai voulu charger une page pleine d'AJAX sur Konqueror, je me suis fait redirigé sur un clône HTML de ma page sous le motif que "il semble que votre navigateur ne supporte pas les formats dans lesquels nous avons réalisé notre page web..."

Après c'est peut être moi qui ne sait pas le configurer correctement, mais je me permet de poser la question tout de même.

Bonne journée à tous, et pour le reste, merci de cet article somme toute très informatif.

Loiseau2nuit aka 213.56.127.109 6 avril 2007 à 09:36 (CEST)

Oui, il semblerait, les quelques démos de ce site fonctionnent avec konqueror(3.4.2) et même epiphany(1.8.0) sans configuration spéciale. --ς:-ζ)ξ--blabla-- 6 avril 2007 à 18:05 (CEST)

Lien design pattern

J'ai ajouté un lien vers l'article Design pattern, notion non évidente pour le néophyte. Chloé Desoutter 30 avril 2007 à 17:06 (CEST)

Liens externes "how to"

Je déplace ici des liens externes de type "tutoriels" qui n'apportent, à mon sens, rien au contenu de fond de l'article, sachant qu'un lien dmoz est déjà présent, que ces liens mènent à des "comment faire..." qui ne rentrent pas dans le rôle de Wikipédia, et que cette section liens externes n'a pas vocation à être une amorce d'annuaire (dont on sait par expérience qu'elle va grandir, grandir...). --Lgd 25 septembre 2007 à 18:28 (CEST)

• (fr) Cours et Tutoriel Ajax.
• (fr) Apprendre Ajax : Tutoriel avec exemples d'utilisation get, post, text, XML.

Lgd revient à la charge chaque année, pour supprimer ces deux liens, ce qui prouve qu'ils sont là depuis plus d'un an. Il me semble que sur un article aussi fréquenté, c'est un gage de pertinence. Je rappelle que Wikipedia recommande dans ses règles d'ajouter, sans excès (deux liens sont-ils un excès?) des liens externes sur un contenu qui ne peut être intégré à l'article, tels que tutoriaux par exemple. Lgd suit une politique personelle de non liens il me semble, et ce n'est pas nouveau! Précisons que contrairement aux craintes de Lgd, la section n'a jamais grandi depuis un an! Lanatur 25 septembre 2007 à 18:39 (CEST)

Rappel des recommandations: «  il est conseillé de limiter le plus possible le nombre de liens externes par article en ne conservant que les sites de référence apportant un complément significatif, pertinent et encyclopédique à l'article. » Aucun de ces deux liens (un site généraliste d'aide pour les développeurs et un site personnel) n'est un site de référence concernant AJAX. --Lgd 25 septembre 2007 à 18:57 (CEST)

Bien d'accord avec la recommandation, mais si on supprime les deux seuls liens de l'article c'est une politique de refus total de liens externe sauf Dmoz. Quand à leur pertinence, ils sont là depuis plus d'un an, sur un article aussi visité! Je propose que l'on cesse de polémiquer tous deux et que l'on attende d'autres avis tout en notant qu'il est cavalier de supprimer les liens d'abord et d'en discuter ensuite. Lanatur 25 septembre 2007 à 19:13 (CEST)

Personne n'a jamais parlé de refus total des liens externes, qui serait absurde quand il s'agit de développer et de sourcer un article sur les technologies Web (je vous renvois à l'exemple de l'article Feuille de style en cascade). Il ne s'agit ici que de liens d'un genre particulier (tutoriels et sites personnels), sans rapport par exemple avec des références telles que The XMLHttpRequest Object ou aria. Nous parlons de liens fortement connotés "spam", et uniquement de cela. --Lgd 25 septembre 2007 à 19:26 (CEST)

Bien, on va d'abord supprimer les liens connotés spam de openweb et alsacreation et on attend l'avis d'autres utilisateurs pour ceux-ci. Lgd décrète que seuls Dmoz et W3C doivent être lié sur WP. Lanatur 25 septembre 2007 à 22:54 (CEST)

Je ne vois pas d'objections a priori à la suppression de certains de ces liens dans d'autres articles, en effet.

Mais ne mélangez pas tout, s'il vous plaît, et ne désorganisez pas les références. Je vous ai cité justement l'exemple des articles HTML (sur votre page de discussion) et CSS pour vous donner deux cas d'utilisations pertinentes des liens externes répartis entre les notes (quand il s'agit de références notables à des informations spécifiques) et la section « liens externes » (où ne sont rappellées que les références majeures, c'est à dire ici normatives).

Si cela peut vous aider à comprendre ce qu'il s'agit de faire:

• le lien vers le site xul.fr présent dans l'article Asynchronous JavaScript and XML n'est pas pertinent (tutoriel de seconde main, notoriété minime de la référence, pas d'apport sur le fond à l'article, pourquoi celui-ci et pas un, deux... ou dix autres tutoriels ?)
• en revanche, le lien vers le même site xul.fr, mais cette fois vers la traduction française du document de travail du W3C dans XMLHttpRequest est tout à fait justifié.

Sinon, je vous rappelle qu'il ne s'agit pas de quelque-chose que j'aurais "décrêté" personnellement. Vos suppressions de liens ont d'ailleurs été annulées spontanément ici et là par les contributeurs qui suivent ces articles. L'historique des articles montre, comme ici, que l'utilisation du lien dmoz en remplacement des tutoriels n'est pas de mon seul fait. Enfin, je dois tout de même rappeler que le spam pour le site xul.fr avait déjà été relevé comme tel lors de cet arbitrage : s'il a en effet été toléré, ce lien est loin d'avoir été approuvé par un quelconque consensus. --Lgd 26 septembre 2007 à 04:02 (CEST)

Tout ceci mérite réponse. Après avoir lu cet arbitrage, il apparait qu'il n'a pas conclu au spam, c'est donc votre opinion personnelle, alors pourquoi le citer, si ne n'est par esprit polémique? L'article que j'ai lié (les deux en fait) est notable, voir le trackback à la fin, encore une fois votre opinion négative est purement personnelle. Je suis d'accord pour mettre un lien sur Dmoz si cela évite une longue liste de liens sur WP, mais s'il y a peu de sites dans Dmoz et si cela oblige l'utilisateur a aller y faire une recherche pour trouver deux ou trois liens utiles, pourquoi ne pas mettre directement les liens sur WP? Ce n'est pas le principe Dmoz qui est faux, c'est son application qui doit être adaptée. Tu l'a noté toi-même, les liens sur des pages personnelles que j'ai retiré, pour voir en fait (quoique certains semblent bien être des spams) ont été rétablis par des contributeurs, cela ne va pas dans ton sens, apparemment, non?

Le tutoriel sur developpez obtient 16 votes sur Del.icio.us, quand au tutoriel Ajax sur xul.fr il obtient 107 bookmarks sur Del.icio.us ce qui infirme le manque de notoriété ou d'intérêt que lui accorde Lgd. Je propose donc de réintégrer ce dernier lien. Lanatur 26 septembre 2007 à 12:09 (CEST)

Del.icio.us en guise de nouvel avatar de google test ? Ma foi... Pour rester dans AJAX, Script.aculo.us atteint 25 301 bookmarks, et le Google Web Toolkit - Build AJAX apps in the Java language est à 8799. Sans commentaires...

Sinon, pour simplifier, j'ai demandé des avis via le bistro.--Lgd 26 septembre 2007 à 15:12 (CEST)

Il serais préférable de renvoyer les lecteurs vers des cours sous licence GFDL ou un peu plus libre... exemple http://developer.mozilla.org/en/docs/AJAX:Getting_Started (sous Creative Commons). PS j'ai viré le lien vers xul.fr sur la page en anglais... motif spam. --GdGourou - °o° - Talk to me 26 septembre 2007 à 15:13 (CEST)

J'ajoute qu'un lien externe n'est pas du contenu. Et qu'en matière de technologie web les sites pullulent. DocteurCosmos - ✉ 26 septembre 2007 à 15:20 (CEST)

Le lien sur developer.mozilla.org est en anglais et ce texte est techniquement dépassé (notamment la question des types mime) contrairement au lien que j'avais ajouté il y a un an, et dont la source est mise à jour. Quand à la licence, elle est d'usage libre et LGPL pour le code. Pour répondre à DocteurCosmos, les liens externes font partie du contenu selon les règles de Wikipédia et les sites pullulent dans absolument tous les domaines. Pour répondre à Lgd qui soi-disant ne voulait plus polémiquer mais qui est encore là ;), je ne mets pas en doute la notoriété de Google ou Script.aculo.us, comparer plutôt avec la notoriété des liens externes sur d'autres pages de WP. Lanatur 27 septembre 2007 à 10:24 (CEST)

<soupir /> pour la question de la langue: Mozilla developper Center, AJAX:Premiers pas... La source est en effet notable et crédible. Mais je suis pas convaincu sur le fond par cette idée de privilégier certains tutoriels parce que "libres" ou assimilés. Outre le problème d'actualisation justement soulevé par Lanatur (mais il s'applique aussi bien à xul.fr), évaluer la qualité d'un tutoriel technique nécessite à la fois une solide connaissance de fond des sources de première main sur lesquels il s'appuie (enfin, sur lesquelles il s'appuie parfois, dans le meilleur des cas, la plupart ne faisant recopier les sottises d'autres tutoriels), plus des compétences en formation dans ce domaine. Cela pose un redoutable problème de compétence, et c'est clairement hors du champ de wikipédia qui a déjà assez à faire comme cela en tentant de fournir des informations sur le fond. C'est l'une des raisons (en dehors, détail, de certains principes fondamentaux) pour lesquelles Wikipédia n'est pas un annuaire. A chacun son métier, celui des contributeurs Wikipédia n'est pas de constituer et de maintenir des listes de liens pour "prolonger" la lecture d'un article.

D'où le repli vers dmoz, aussi imparfait soit-il (Pour tout dire, personnellement, virer le lien dmoz en plus des autres liens externes ne me gênerait pas du tout, en fait).

Enfin, comme l'illustrent les contributions de Lanatur, qui a manifestement des compétences dans ce domaine, mais qui n'intervient ici que pour veiller à maintenir quelques liens externes (cf sa toute première contribution)), cela n'encourage en rien l'amélioration du contenu propre de wikipédia. C'est pourquoi, AMHA, il est justifié de supprimer (carrément « à vue ») tous les liens du type « tutotiel applicatif » dans les sections « voir aussi » et autres « liens externes ».

cet acharnement à défendre un lien externe au lieu d'apporter du contenu est lassant... --Lgd 27 septembre 2007 à 10:43 (CEST)

Je te remercie de me reconnaître au moins une compétence dans ce domaine. J'ai créé un framework Ajax (qui n'est pas lié sur WP) et je crois en effet que c'est un domaine que je connais bien. L'article Ajax me semble assez complet mais si j'y vois des erreurs ou des vandalismes, je ne manquerais pas de le corriger, même si j'ai peu de temps pour cela. Je défend ce que j'ai fais, cela semble normal non?

Même traduit en français, l'article sur mozilla (qui a quelques années) est dépassé au niveau du code qui est le même dans les deux langues.

Pourquoi supprimer le matériel pédagogique? De toutes façon c'est une décision d'ordre général et que l'on ne peut pas prendre sur un unique article où d'ailleurs un tutoriel est indispensable (les documents du W3C sont des références pour développeurs et n'ont vraiment rien de pédagogique). Lanatur 27 septembre 2007 à 10:56 (CEST)

Pourquoi diable, s'il s'agit de pédagogie, ne pas créer un Wikibooks ou un cours sur Wikiversity sur le sujet, plutôt que de se cantonner ici à pulser des liens vers votre site ? Peut-être ne le conaissiez-vous pas, mais ce sont des projets tout à fait appropriés pour cela, om votre aide et vos compétences seront très bienvenues. --Lgd 27 septembre 2007 à 11:04 (CEST)

Doucement, il n'y a pas d'obligation de travailler sur Wikipédia à ce jour! Lorsque j'ai supprimé des liens vers openweb ils ont été immédiatement rétablis et si je les avais encore supprimé comme tu as fais dans cet article, on m'aurait traité de vandale à coup sûr. Pourquoi une politique spéciale pour cette page? Je suis uniquement l'auteur d'un site Web qui n'est pas lié sur Wikipédia et je ne l'ai jamais essayé de le faire alors cesse de m'accuser d'auto-promotion! Je demande des avis techniques sur la pertinence d'un lien et n'ai pas à subir un procès personnel, je n'en fais à personne. Lanatur 27 septembre 2007 à 11:21 (CEST)

J'ai en effet d'abord confirmé d'anciennes suppressions par d'autres contributeurs, mais après désaccord récent, déplacé ensuite en page de discussion. Laquelle, après un appel sur le Bistro, ne recueille guère pour l'instant que peu d'avis, il faut l'avouer (tout le monde s'en fiche un peu, ce qui est normal vu le côté technique confidentiel, quoique pertinent). Mais ces avis sont négatifs sur la conservation de votre lien.

sinon, attention à une méconnaissance éventuelle de ce qu'est Wikipédia: il n'y a en effet aucune obligation à « contribuer ». En revanche, il y a une position consensuelle, qui n'a jamais été remise en cause à ma connaissance, et qu'exprime très bien le modèle {{bienvenue spammeur}}: contribuer uniquement pour l'ajout de liens externes est très problématique. Disons que le choix offert dans la pratique par Wikipédia est soit de contribuer au contenu, soit de s'abstenir de poser des liens externes.

Enfin, il n'y a, de ma part, aucune « politique spéciale » à l'égard de cette page ni de vous-même: c'est au contraire une réflexion générale sur ce problème des « liens externes tutoriels dans les articles techniques sur la publication Web », qui m'a d'ailleurs conduit en premier lieu, depuis quelques temps, à commencer par supprimer les liens (voire les articles) vers mes propres tutoriels. Pour continuer par l'évacuation argumentée de tous les liens de ce type dans les articles de vulgarisation sur les technologies Web.

Sinon, j'ai tenté d'expliquer ci-dessus pourquoi cette idée d'« avis technique sur un lien » n'étais pas pertinente ici. Relisez, s'il-vous-plaît. --Lgd 27 septembre 2007 à 11:37 (CEST)

C'est un délire! Tu décide tout seul de la politique de WP sans consulter personne, tu vandalise des pages en supprimant des liens utiles, qui sont là depuis plus d'un an et tes contributions à WP sont en fait en nombre minime! Lanatur 27 septembre 2007 à 18:38 (CEST)

Hum... Des avis d'autres contributeurs sur mes propres contributions seraient évidemment plus pertinents, mais: outre la refonte complète de l'article Feuille de style en cascade, une participation à celle d'HTML et quelques articles de moindre importance comme Acid2, je participe en effet depuis longtemps surtout à la surveilance des RC, tout simplement parce que j'en ai la possibilité (et que c'est un moyen précieux d'observer l'exemple de web collaboratif qu'est wikipédia, mais c'est une autre histoire).

Cela signifie en effet du contenu quand je peux, mais assez solide je crois. Et beaucoup de révocations de vandalismes, de créations aberrantes et... de spam.

Mais je pense pas que mes interventions dans ce domaines aient vraiment fait l'objet de contestations. Tout cela pour dire que je vois pas vraiment où est le problème, et que ce que je tente de vous expliquer n'est pas juste une opinion personelle.

Maintenant, il est tout à fait possible que je me trompe dans ce cas précis, évidemment. Il est possible que les tutoriels du site xul.fr soit en fait une référence citée par les experts dans ce domaine, tels que les développeurs d'IE responsables de l'implémentation d'XMLHttpRequest dans ce navigateur, les membres du WG ARIA du W3C, les spécialistes du Web2.0, voire ceux de XUL, tout simplement. Dans ce cas, et si vous pouvez le montrer, il va de soi que je me serait honteusement trompé, et que ce lien a toute sa place dans l'article dont nous parlons. Dans le cas contraire, est-il vraiment utile de poursuivre ? --Lgd 27 septembre 2007 à 20:26 (CEST)

Voila la réponse à ta question. Ce n'est pas moi qui ai mis ce lien sur Mozilla mais un développeur. L'article est aussi listé sur Dmoz et une fois encore, je précise que ce n'est pas moi qui l'ai mis. Lanatur 28 septembre 2007 à 10:34 (CEST)

Bah... si l'article est listé sur Dmoz, je ne vois pas bien votre problème dès lors que le lien Dmoz est présent ? Votre tutoriel est donc accessible via Dmoz ? Et donc depuis wikipédia via le lien Dmoz ? Tout va bien, donc, avec le lien Dmoz ? Ou faut-il aussi, à votre avis, un lien dans Wikipédia vers Mozilla developpement center, qui se charge de recenser et d'assumer les ressources "mode d'emploi" qui n'ont hélas pas leur place sur wikipédia ? --Lgd 28 septembre 2007 à 12:42 (CEST)

Les bons documents, on risque de les retrouver un peu partout. Si Wikipedia ne les reprenais pas parcequ'ils sont déjà listés ailleurs, elle se condamnerait à ne lier que des documents médiocres et impopulaires. Il n'y a pas de logique dans ce que tu dis. Lanatur 28 septembre 2007 à 14:41 (CEST)

Il y a surtout un gros problème à la base de toutes vos tentatives : non, Wikipédia n'est pas destinée à lier des documents... (« Wikipédia n'est pas un annuaire »). Il n'y a pas à prendre en considération la facilité avec laquelle un document qui n'est pas une source du contenu cité en note, ni une référence entrant dans la catégorie "sites officiels", sera trouvée ou non par le lecteur désireux de chercher des tutoriels, des sites personnels, etc. Pour cela, il y a justement les annuaires... --Lgd 28 septembre 2007 à 14:47 (CEST)

A propos de Dmoz

Rappellons que Dmoz est un répertoire de sites tandis que les liens internes et externes de Wikipedia se font plutôt sur des pages. Décider d'utiliser Dmoz comme seule référence à ces inconvénients:
1) Il faut aller sur Dmoz.
2) Il faut choisir les bons sites
3) Sur les sites il faut trouver les bonnes pages
C'est pour éviter ce travail que l'on met des liens externes sur des pages dans Wikipedia.
Cela a déjà été débattu et intégré dans les règles de WP, un seul contributeur ne peut pas décider de les changer à son idée.
Sur le plan encyclopédique, Dmoz est aussi quelques tons en dessous et liste en majorité des sites commerciaux... Lanatur 28 septembre 2007 à 10:34 (CEST)

Puis-je vous inviter à lancer un sondage circonstancié sur la question ? cela me semble intéressant. Pour le moins risqué, mais intéressant. --Lgd 28 septembre 2007 à 12:44 (CEST)

Changer les règles

Je dois rappeller que si l'on veut modifier les règles de WP, c'est possible... en passant par cette page: Wikipédia:Prise_de_décision.
Lanatur 28 septembre 2007 à 11:06 (CEST)

Hum... Une prise de décision nécessite d'abord un minimum de concertation. Je vous encourage à commencer par aborder la question par exemple sur le Bistro, ou de voir quel projet serait approprié pour poser vos questions sur le sujet et tâter le terrain. --Lgd 28 septembre 2007 à 12:48 (CEST)

Je fais allusion à tes réflexions personnelles sur la politique de liens. Moi je ne veux rien changer. Lanatur 28 septembre 2007 à 14:38 (CEST)

Bah si, manifestement: ce dont vous dites ci-dessus « C'est pour éviter ce travail que l'on met des liens externes sur des pages dans Wikipedia. Cela a déjà été débattu et intégré dans les règles de WP, un seul contributeur ne peut pas décider de les changer à son idée. » ... N'a jamais été intégré nulle part dans aucune règle de Wikipédia. C'est pourquoi je vous renseigne sur la manière de procéder si vous souhaitez tenter de changer les règles en ce sens. Les avez-vous lu, au fait ? --Lgd 28 septembre 2007 à 15:02 (CEST)

AJAX sans CSS

Bonjour,

---

"AJAX n'est pas une technologie en elle-même, mais un terme qui évoque l'utilisation conjointe d'un ensemble de technologies libres couramment utilisées sur le Web :

(...)

CSS pour la présentation des informations ;"

---

AJAX n'implique pas l'utilisation de CSS.

Le développement web implique souvent l'utilisation de CSS, ce qui a pour conséquence que le développement AJAX utilise souvent des CSS, mais il n'y a pas de lien direct entre les deux.

(étant donné que je suis nouveau ici et que l'ambiance est un peu tendue autour de cette page, je préfère éviter de modifier sans en avoir discuté :))

Cordialement, --Fredb24 4 octobre 2007 à 17:38 (CEST)

A propos de la section concurrence

Je ne suis pas experte, mais il me semble que Silverlight utilise les technologies Ajax, le tout dans une surcouche à la sauce Microsoft, mais c'est de l'Ajax comme le sont certains composants asp.net. Je pense également que cette section n'est pas vraiment nécessaire, en tout cas pas à ce niveau dans la table des matières (un paragraphe à ce sujet dans le chapitre Comparaison avec les applis web traditionelles me parait plus légitime en terme de quantité de contenu)

À propos des antivirus

Dans la section « Avantages et inconvénients » il est noté :

Par contre, l'utilisateur d'applications AJAX doit autoriser l'exécution de code Javascript par son navigateur, ce qui peut laisser craindre des problèmes de sécurité (cependant il existe des antivirus bloqueurs de scripts efficaces). (gras ajouté)

Cette dernière information me semble bien optimiste. Étant donné que de nombreux codes malveillants utilisent des techniques de chiffrement et des systèmes de rebond (un code JavaScript qui charge un autre code JavaScript, qui charge etc.), je ne vois pas trop comment un antivirus, sans interpréteur JavaScript, pourrait déduire efficacement la malveillance d'une page web... Or je ne pense pas que beaucoup d'antivirus aient implémenté JavaScript, j'aurais plutôt tendance à penser qu'aucun ne l'a encore fait !

Par contre il existe des outils bloqueurs de JavaScript très sélectifs, noScript sur Firefox en est un bon exemple. Est-ce que ça suffit à laisser passer AJAX et à bloquer les scripts malvaillants ? Aucune idée, il me semble donc qu'il faudrait un peu plus de modération dans cette partie-là...

Avantages et inconvénients: référencement et robots d'indexation

Je ne comprend pas à quoi se réfère le "les" dans la phrase:

Un autre inconvénient est la question du référencement puisque les robots d'indexation ne sont pas en mesure d'indexer les contenus engendrés dynamiquement. La solution, comme pour toute page Web, est alors de les inclure dans la page principale.

Etant donné que personne ne semble pouvoir répondre. Je supprime la phrase concernant cette solution puisque comme je la comprend ce n'en est pas une (Je la comprend comme "l'ajax pose des problèmes de réferencement, la solution est de ne pas utiliser cette technologie.").

"pas en mesure d'indexer les contenus engendrés dynamiquement. La solution, comme pour toute page Web, est alors de les inclure"

=> les = les contenus dynamiques :) --Fredb24 (d) 26 février 2008 à 10:40 (CET)

Première phrase

Bonjour,

La première phrase me gêne un poil :

« AJAX, ou Asynchronous JavaScript And XML (« XML et Javascript asynchrones »), est un acronyme désignant une solution informatique libre pour le développement d'applications Web. »

AJAX est un acronyme, d'accord, mais Asynchronous JavaScript And XML n'en est pas un (évidemment). Seulement c'est ce que laisse penser cette phrase, à mon avis : « AJAX, ou Asynchronous JavaScript And XML, est un acronyme [...] ». Non ? — Delhovlyn — (CinéNiavlys) « ... » ^contribs?, le 5 mai 2008 à 15:18 (CEST)

"Asynchrone" contre "Requêtes asynchrones"

Je pense qu'il serait utile de préciser quelque part dans l'article que les requêtes HTTP entre les scripts Javascript (qui s'exécutent dans le navigateur) et le serveur ne sont pas asynchrones (comme le nom « Asynchronous JavaScript And XML » pourrait le laisser croire). En effet, dans le protocole HTTP, toutes les requêtes sont synchrones. C'est-à-dire qu'une requête du client vers le serveur est toujours suivie d'une réponse du serveur vers le client.

AJAX n'utilise donc pas de communications asynchrones. Le fait qu'une requête XmlHttpRequest ne soit pas bloquante relève du parallélisme : chaque requête lance un processus léger qui attend la réponse du serveur. Voici un exemple de communication asynchrone : le demandeur fait une requête et n'attend pas de réponse, et le serveur fait ensuite après un certain temps une autre requête en retour et en guise de réponse (dans l'autre sens). Voir l'article Asynchronisme.

« Asynchrone » serait donc un abus de langage, à moins que ce ne soit les interactions-utilisateur qui soit qualifiées d'asynchones. Et encore, même dans ce cas ça se discute...

Êtes-vous d'accord avec ceci ? Si oui, pensez-vous qu'il serait bon de préciser dans l'article que les requêtes ne sont pas asynchrones ?

–– Martin Bouladour –– 9/12/2008 ––

Sauf erreur, c'est le javascript qui est asynchrone dans AJAX ([Asynchronous javascript] and xml), il n'attend pas la réponse du serveur pour continuer, et quand le serveur a fini son travail et envoie une réponse, le gestionnaire d'événements déclenche l'appel à une fonction pour traiter la réponse. --Fredb24 (d) 13 décembre 2008 à 03:16 (CET)

Oui, je crois que ça fonctionne plus ou moins comme ça, en effet. Ça n'empêche que je ne comprend pas vraiment comment un script Javascript (ou autre) peut s'exécuter de manière « asynchrone ». De manière séquentielle ou parallèle, okay, mais asynchrone, j'ai du mal. En somme, ce sont juste les appels aux fonctions qui lancent des requêtes HTTP qui ne sont pas bloquants, et j'ai l'impression que ça relève plus du parallélisme que d'un éventuelle asynchronisme. Peut-être que c'est juste une différence de point de vue et que je n'arrive pas à voir ça du point de vue de Jesse James Garrett. -- Mboulado (d) 15 décembre 2008 à 01:21 (CET)

« Le fait qu'une requête XmlHttpRequest ne soit pas bloquante relève du parallélisme : chaque requête lance un processus léger qui attend la réponse du serveur. »
La réponse n'est pas attendue. La fonction javascript qui a déclenché l'appel se poursuit, jusqu'à son terme, indépendament de la réponse. Et quand la réponse arrive, de façon asynchrone, l'appel à la fonction de traitement, différente de celle qui a lancé l'appel, est déclenché.
Pour reprendre l'exemple de la page Asynchronisme: quand vous envoyez un email, vous n'attendez pas la réponse pour continuer à vivre, mais quand cette réponse arrive, vous réagissez.
AJAX est donc, me semble-t-il, bel et bien asynchrone, sans abus de langage Fredb24 (d) 4 juillet 2009 à 12:18 (CEST)

De l'objectivité SVP

• Discutez dans les chapitres prévus.
• Liens utiles : À recycler - À traduire - À fusionner - Orthographe à vérifier - Soupçons de copyright - Articles non neutres

Proposé par : 78.231.73.92 (d) 26 juillet 2010 à 23:32 (CEST)

Raisons de la demande de vérification

La page devrait AMHA être écrite de façon plus objective. Le but n'est pas de présenter AJAX comme la perle rare qui sera la solution ultime. Ne me sentant pas très calé sur ajax/javascript, je préfère ne pas éditer directement la page (en plus de certaines tensions, d'après ce que j'ai pu voir dans la page de discussions).

Parmis les points qui me semblent discutables :

Dans la comparaison avec les app web traditionnelles :

- Les apps web et ajax nécessitent, dans la plupart des cas, plusieurs requêtes, les apps ajax demandent plus de requêtes qu'un app trad.

- Le temps de réponse d'une app dépend fortement du temps de réponse du serveur dans les deux cas.

- Les éléments communs sont mis en cache dans les deux cas.

- Le temps de traitement côté serveur est réduit, mais de façon négligeable, le temps de traitement serveur étant composé en grande majorité d'appels à la BDD, dont ajax ne permet pas de s'affranchir. Donc pas significatif.

Tout au long du document :

- La portabilité d'ajax n'est pas vraiment un point fort, étant donné que chaque navigateur a sa propre idée de ce qu'est javascript. C'est moins pire qu'à une époque, et c'est toujours plus portable que flash (encore que ça dépend des points de vue).

- Les faibles ressources nécessaires à ajax par rapport à java et autres... @/

- La sécurité ? Il me semble que l'utilisation du javascript en général n'est pas le rêve de toute personne intéressée par l'aspect sécurité... Et je ne vois pas en quel honneur les js seraient mieux stoppés par les antivirus que flash et/ou java.

Discussions et commentaires

Toutes les discussions vont ci-dessous.

Pourquoi un exemple avec jquery ?

Cela obscurcit le discours. AJAX est indépendant de jquery et de tout framework. Hors, l'exemple semble le rendre nécessaire. On voir ici un tutorial sans aucun framework : http://www.w3schools.com/ajax/default.asp Pcouderc (d) 12 juillet 2013 à 10:56 (CEST)