Faire de l'Ajax sans le savoir
Par Laurentj le dimanche, novembre 6 2005, 23:19 - Technologies Web - Lien permanent
Dans un billet précédent, "Ajax est obsolète", j'expliquais que pour moi, Ajax n'est pas une solution d'avenir car trop complexe et trop bas niveau (le fameux xmlhttprequest).
J'avais alors émis l'idée d'avoir plutôt des balises spécialisées, interpretées directement par le navigateur, qui se chargeraient des opérations bas niveau et avec lesquelles on aurait juste à indiquer des informations minimales dans des attributs comme l'URL du service web à invoquer. Elles permettraient donc de faire de l'Ajax sans le savoir, sans avoir à taper des lignes de codes javascript complexes. Exactement en fait comme la balise HTML <a> ou <form>, qui utilisent finalement une forme d'Ajax sans que vous le sachiez : elles ont une url dans un attribut, elles envoient des données via xmlhttprequest à cette url, et elles modifient (ou plutôt remplacent) la page courante à partir du contenu de la réponse reçue.
J'avais donné alors l'exemple de la balise template en XUL qui est parfaitement dans cet esprit : on cache ce qui est bas niveau (xmlhttprequest), on permet d'éviter l'usage du javascript. Le résultat est alors une techno simple à utiliser pour développer, économe en temps de dev, de débuggage, et économe en bande passante ou en ressource système (il n'y a pas 50ko de scripts à executer puisque les balises sont directement interpretées par le navigateur).
Je voulais commencer à faire une bibliothèque JS qui permettrait de vous montrer concrétement mon idée. Mais en fait d'autres l'ont fait avant moi. Je suis en effet tombé, au hasard du surf, sur l'offre de backbase. Ce qui est intérressant sur ce site, c'est le code source de leur page. Que voit-on ? Des balises <include>, <event>, <buffer>, des attributs behavior, followstate etc.
On devine alors aisément à quoi elles servent : inclure des morceaux de pages à des endroits précis, qui sont éventuellement rechargés à l'apparition d'évènements particuliers, déclenchés par des actions spécifiques de l'utilisateur. En clair : vous avez le même résultat que ce que l'on fait en Ajax, mais sans avoir à écrire une seule ligne de code javascript. Quelques balises et quelques attributs bien placés, et vous voilà avec une interface utilisateur dynamique.
Exactement donc dans le même esprit que la balise html <a>, <form>, ou la balise XUL <template> : simplicité, efficacité. Bref, une techno accessible à tout développeur web, et pas seulement aux geeks.
Ce qu'a fait Backbase a toutefois un inconvénient : avoir une page utilisant leurs balises nécessite d'inclure leurs fichiers JS qui sont volumineux. Ce javascript sert à parser la page, et à interpreter les balises et attributs. On a donc une page lourde et longue à charger mais aussi longue à s'éxecuter.
Cependant, imaginez que le navigateur puisse interpreter nativement des balises du même style que celles de Backbase. Là je pense qu'on pourra vraiment parler de web 2.0 (ou 3.0 ?) ;-) (tout en résolvant une partie des problèmes d'accessibilité posés par Ajax).
Commentaires
je vais ptet dire une connerie mais tout ça est pas deja faisable en detournant la balise object + attribut text/html
?
backbase n'est quand même pas très clair sur ce qu'il est possible de faire et les termes exacts de la licence community... une alternative totalement libre serait donc un plus!
Goetsu : tu parles d'ajax ? Oui certainement, <mode value="ironie 3ieme degré">mais chut, faut pas le dire, c'est pas assez compliqué comme truc. Tu risques donc de froisser les adorateurs d'Ajax dont la dévise est pourquoi faire simple quand on peut faire compliqué ;-)</mode>
J'ai plus le lien, mais d'autres ont proposé de faire la même chose avec un iframe :-) Ça a tout de même quelques limites (on est loin de pouvoir faire sans une ligne de code ce qu'on peut faire avec le truc de backbase), mais il est vrai que pour certaines chose, c'est faisable et remplace avantageusement Ajax.
Olivier : oui c'est un truc propriétaire. D'ailleurs, j'ai pas reussi à télécharger leurs fichiers JS : je les soupsonne de vérifier le referer et renvoyer un contenu vide quand ce n'est pas une page de backbase qui inclus le fichier js (idem pour les fichiers XML dont on voit le lien dans le source de la page). Toutefois, je trouve leurs idées trés bonnes et je suis d'accord avec toi : il faudrait une alternative libre ;-)
Heu oui mais seul AJAX permet (a l'heure actuelle) d'avoir une code source propre et sémantique il me semble, je dit peut etre une connerie mais mettre <include>, <event>, <buffer> dans sa source revient a mettre des balises qui n'existe pas pour le moment...
Je n'aime pas l'ajax non plus (trop lourd et trop complexe) mais la solution de backbase ne me conviandrais pas non plus.
Effectivement il va falloir attendre que les navigateurs évolue dans ce sens...
Oui, bien sûr, avoir des DIV vides qui contiendront du HTML récupéré par Ajax, c'est sûr que c'est sémantique :-/ Est ce au moins accessible ? pas du tout. Pas plus que Backbase d'ailleurs.
Oui tu dis une connerie. Ces balises, elles existent (la preuve, tu peux les lire dans le source ;-)) car elles fonctionnent (grâce à un script certes).
Tu remarqueras que ces balises sont dans un éspace de nom différent de XHTML (ce qui au passage, n'invalide pas en théorie le contenu XHTML), donc où tu vois un problème de sémantique quelque part ? Elles ont un rôle, une signification, et elles sont tout à fait utilisées pour ce à quoi elles sont déstinées.
Cependant, peut on parler de sémantique pour des balises qui n'ont qu'un rôle technique ? je ne crois absolument pas. Elles n'ont pas vocation à décrire un contenu. Juste à indiquer finalement l'emplacement d'un contenu ou à dire que tel contenu est dynamique.
C'est marrant, ce que tu proposes c'est exactemetn ce que permet de faire Macromedia Flaex 2, avec son méta-langage : MXML.
Oui, mais bon, si il faut choisir entre l'original (XUL) et la copie (MXML), je choisi l'original ;-)
Voici une alternative à Ajax qui n'utilise ni iframe, ni xmlhttprequest : http://zingzoom.com/ajax/ajax_with_image_fr.php
Méaculpa :P Je me suis trés mal exprimé veuillez m'en excusé, j'aurais bien voulu dire (^^) que la solution backbase et certe interressante, mais nous somme obliger de mettre des elements comme <s:loading></s:loading> dans le code source de nos pages. Ce qui rend bien sûr invalide les pages utilisant ce programme (http://validator.w3.org/check?verbose=1&uri=http%3A//www.backbase.com/weblog/%3Fp%3D12)
Voila encore dsl de m'être si mal exprimer, en me relisant j'en ai rigolé ^^
Si tu avais regardé les erreurs annoncées par le validateur, tu aurais vu qu'il est buggé.
XHTML est un dialecte XML. Il est donc tout à fait autorisé (par la norme XML) de déclarer des namespaces comme ceci : xmlns:foo="http://foo.com". Or le validateur ne reconnait pas ces attributs (qui sont d'ailleurs dans le namespace xmlns, c'est à dire le namespace du xml et non XHTML). C'est un bug. Il devrait au moins reconnaître ces attributs (et les valider).
Les éléments que tu cites se situent dans un autre namespace que XHTML, il est donc tout à fait autorisé de les utiliser dans un document XHTML.
Conçernant les autres erreurs, se sont pour la plupart de simples erreurs en XHTML, qui n'ont pas grand chose à voir avec le fait qu'il y ait les balises de backbase.
moi j'ai du mal à comprendre en quoi l'ajax est compliqué ?! C'est avec des reflexions comme ça, que crosoft et son atlas (son implémentation ajax) pourrait percer ...(ayant alors alors une image de "plus simple") Faut pas diaboliser l'ajax, faut se prendre 2 minutes, et tester, c'est vraiment rien de sorcier ... (une lib comme sajax est un bon début) Après tout dépends comment on l'intègre et on le développe, mais il y a moyen de faire très propre ...
Les exemples que je t'ai donné ne te paraisse pas plus simple à utiliser ? Tu ne perçois pas la différence de facilité d'utilisation ?
À mon avis, si tu ne vois pas la différence, c'est que tu es un peu trop dans ton code. Lève les yeux de ton écran. Prend du recul. Penses aux autres développeurs ;-) Pense même à toi. Même aux amateurs qui veulent pouvoir faire des pages perso modernes sans avoir à lire 15 pages de doc pour faire une seule chose.
Si le web est devenu ce qu'il est aujourd'hui, c'est pas grâce à des trucs compliqués comme xmlhttprequest. C'est grâce à la "facilité" de faire une page web en HTML. Tout le monde, y compris les non informaticiens, arrive à comprendre en deux minutes le fonctionnement de la balise <a>. Il suffit de 2 phrases pour expliquer à quoi elle sert et comment s'en servir.
Ce n'est pas le cas de xmlhttprequest.
Et j'ai montré dans mon billet que même pour faire des trucs aussi complexe qu'avec Ajax, on pouvait tout à fait atteindre un niveau de simplicité proche de <a> ou <form> tout en évitant d'avoir à utiliser xmlhttprequest ou des libs à gogo.
Il "suffirait" que les navigateurs implémentent des balises un peu plus dynamiques...
Je trouve ca trés bien au contraire. Je suis informaticien et ca me soule de voir tout le monde se dire Webmaster... Vos critiques sont peut être fondées mais il faut évoluer, et c'est surement une des étapes importantes.
Ouahou ! Et alors ? Tu nous fait un complexe ou quoi là :-) ? Jaloux que l'on puisse faire les choses plus facilement ? Parce que tu as fait des études en informatique, alors il faudrait ne pas remettre en cause tes connaissances, que tout reste compliqué pour ne pas perdre le monopole de ton savoir faire ? Et en tant qu'informaticien, tu te qualifie de webmaster ? Et tu crois que le "webmaster" amateur aura ton expertise (si tu en as une) ?
Permet moi de te dire que si c'est oui à toutes ces questions, tu es un mauvais informaticien :-p.. Il faut savoir évoluer ! Depuis toujours, le but de l'informatique est de simplifier, faciliter les choses. Si tu n'accepte pas que les choses deviennent plus facile, change de métier. D'un autre coté, il y a encore beaucoup à faire pour rendre des technos plus faciles. Des nouvelles apparaissent tout le temps, manquant de maturité, qu'il faut alors faire évoluer pour la rendre plus accessible, plus productive. Mais c'est sûr qu'il faut savoir s'adapter.
oui, il faut évoluer. Simplifier les choses pour ne pas s'embeter avec des complexités inutiles, surtout quand on sait comment les rendre plus facile à utiliser (cf mes exemples).
Laurent: C'est bien connu les informaticiens codent leur page en Assembleur, car c'est plus « human readable » que le binaire et que l'on peut faire « view source ». Bon trèves de plaisanteries.
Je suis d'accords avec ton billet. Il y avait eu un débat à ce sujet entre deux carnets Web.
trés bien expliqué le ajax merci.