Articles précédents : Développeur
- [20] Archetype Javascript Framework 0.1
- [50] gna.org à la recherche de machines hébergées
- [25] PhpMyObject 0.10 : nouvelle version
- [0] Le code bar rouvre ses portes le samedi 13 octobre
- [5] Créer des Web services en deux clics (ou presque) grâce à Apache CXF et à la POA
- [5] OpenSceneGraph 2.2 est disponible
- [60] Sortie de Friendsnippets
- [345] Lisaac 0.12 en GPL v3
- [5] Trophées du Libre 2007 : derniers jours pour les candidats
- [14] Squeak By Example
Liens connexes
- ASK (726 hits)
- Release notes (42 hits)
- Robert Nyman (34 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : ASK : Un framework Ajax accessible
Posté par fyah (page perso, ). Modéré le 28 octobre 2007.
"The purpose of ASK is to offer you a simple way to get content into your page on-the-fly through asynchronous JavaScript and XmlHttpRequest, without sacrificing accessibility or usability"
Ce qui peut se traduire par: « L'objectif de ASK est de vous offrir une solution simple pour actualiser votre page à la volée en utilisant Javascript et XmlHttpRequest, sans pour autant perdre en accessibilité ou en utilisabilité »
En effet, de plus en plus de sites se mettent à la mode « 2.0 » et sacrifient divers aspects :
- Gestion des bookmarks ;
- Gestion des fonctions suivant, précédent, rafraîchir ;
- Accessibilité de certains navigateurs ;
- Accessibilité pour les clients n'utilisant pas Javascript.
Il suffit de surfer quelques temps avec l'extension NoScript de Firefox pour vite s'apercevoir que tous les webmaistres n'envisagent pas le minitel 2.0 du même point de vue.
ASK est donc une manière élégante et légère (8 Ko) d'implémenter l'Ajax sur votre site, tout en limitant les sacrifices d'accessibilité.
NdM : la licence est précisée en entête du script. L'auteur a précisé qu'il n'avait pas approfondi la question de la licence et qu'il n'avait rien contre changer pour une licence open-source si cela avait un intérêt.
![[en]](../../../images/en.png)
ASK (726 hits)-
Release notes (42 hits)
-
Robert Nyman (34 hits)
> Lire la dépêche (10 commentaires, moyenne: 1,9).
- Inclure ask.js dans votre page: ;
- Ajouter deux choses aux liens que vous souhaitez faire agir dynamiquement :
- La classe CSS ask ;
- La classe CSS target-idOfTargetElement, où idOfTargetElement est l'ID de l'élément de la page que vous souhaitez mettre à jour
Un exemple de lien utilisant ASK, qui présentera le contenu dynamiquement dans l'élément target :
<a href="http://www.robertnyman.com/ask/content.php?continents=true&countries=true&cities=&footertext=" class="ask target-countries">Get countries</a>
ASK présente les fonctionnalités et restrictions suivantes :
Navigateurs supportés :
- IE 5+
- Firefox 1.0+
- Safari 1.2+
- Opera 8+
La fonctionnalité d'historique ne fonctionne pas avec les navigateurs suivants :
- IE 5.0
- Safari
- Opera 8.0, pas du tout. Dans Opera 8.5+, le comportement n'est pas stable à 100% avec le bouton 'suivant'.
La fonctionnalité de bookmarking ne fonctionne pas avec les navigateurs suivants :
- IE 5.0
Chapeau bas à l'auteur, Robert Nyman, qui en plus propose d'autres scripts intéressants :
lien enrhumé
Un exemple de lien utilisant ASK, qui présentera le contenu dynamiquement dans l'élément target :
Get countries
le lien n'est pas complet, ça ne marche pas!
voici le vrai: http://www.robertnyman.com/ask/content.php?continents=true&a(...)
Apparemment, ça marche bien avec Konqueror (3.5.8) aussi.
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
[+] [^]Re: lien enrhumé
Posté par superna (Jabber id, page perso, ) le 28/10/2007 à 13:02. (lien). Évalué à -2.En effet si cela fonctionne avec Safari, ce serait idem pour Konqueror !
-
[^]Re: lien enrhumé
Posté par zero heure (Jabber id, page perso, ) le 28/10/2007 à 14:59. (lien). Évalué à 5.Ben non, ce n'est pas évident:
l'historique ne marche pas avec Safari, en revanche il marche avec Konqueror.
Ce n'est d'ailleurs pas très surprenant: Konqueror évolue en permanence tandis que Safari ne change qu'avec les nouvelle versions de MacOSX.--
J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm
-
[^]Re: lien enrhumé
Posté par Temsa (Jabber id, page perso, ) le 29/10/2007 à 10:13. (lien). Évalué à 2.Absolument pas !
Il ya de vrais grosse différences entre les 2. Surtout niveau "chargement" (tout ce qui se passe en gros avant le "onload").
En fait même Safari 3 entre la version Mac et Windows il y a des différences. Archetype semblerait ne pas fonctionner sur la version Mac (néanmoins on a très peu d'informations et pas de Mac pr debugger :'( ) alors qu'elle fonctionne comme un charme sur la version Windows.
Sinon, personnellement je préfèrerais que les gens se concentrent sur l'intègration de moteur javascript (spider monkey, rhino ...) dans les navigateurs "accessibles" pour l'accessibilité plutôt que de se limiter dans ce qu'il font, alors qu'à part le chargement javascript, les applications peuvent facilement être accessibles ...
Pour moi arrêter de faire du javascript car les navigateurs accessibles ne le supportent pas est débile :/
P.S.: Je suis d'ailleurs tout à fait pret à aider un projet dans ce sens s'il en existe ! ;)
-
-
[^]Re: lien enrhumé
Posté par fyah (page perso, ) le 28/10/2007 à 15:42. (lien). Évalué à 2.Le problème de lien est du à un problème dans le système de post de DLFP...
J'ai ouvert une entrée dans le système de suivi pour cela:
https://linuxfr.org/tracker/685.html
pour résumer: a chaque fois que l'on post un message sur dlfp, on passe le contenu du message 'à la moulinette'(tm) (boutons vérifier, valider).
Cette moulinette à l'avantage de supprimer toutes les balises que l'on ne souhaite pas et c'est très bien. Cependant, si je souhaite écrire une balise interdite en tant que texte, j'utilise alors les codes html des caractères, ainsi la balise n'est pas reconnue.
Le problème c'est que les caractères encodés sont décodés par la moulinette, et donc interprété au deuxième passage (validation)...
donc par exemple, pour réussir à afficher cette balise script, j'ai du la reéditer après l'étape de vérification pour remplacer les balises par leur code html correspondant juste avant la validation.
<script type="text/javascript" src="js/ask.js"></script>--
Je ne connais de sérieux ici-bas que la culture de la vigne. Voltaire]
Amélioration possible
Au départ j'avais mal compris le fonctionnement de ce "framework" AJAX.
En fait, j'avais pensé qu'en indiquant comme class "ask target-bidule" pour un lien, il allait récupérer via AJAX (XmlHTTPRequest) le résultat de la requête et qu'il allait dans ce résultat récupérer le contenu de la balise d'identifiant "bidule" pour la remettre dans la balise d'identifiant "bidule" de la page. Et ensuite j'ai découvert que dans content.php il y avait des "if" pour afficher ou non le contenu selon ce qu'il y avait dans la requête et si on était ou non en mode AJAX :(
Vous allez me dire "Mais à quoi ça sert d'envoyer tout le contenu pour en récupérer juste un bout ?". A cela je réponderais : "Pouvoir profiter simplement d'une des fonctionnalités offerte par AJAX sur des applications-webs dont il serait coûteux de toucher au code : le non-rechargement de la page".
En effet, en indiquant via "target-bidule" les zones que l'on veut récupérer, cela permetterait d'éviter des rechargement inesthétique de page. Ok on dépense autant de bande passante, mais ce n'est pas incompatible avec une mise à jour futur du code où à l'appel d'une requête on filtre le contenu selon la requête pour n'envoyer que le nécessaire. Bref, on profite des fonctionnalités d'AJAX en 2 temps : d'abord le non-rechargement, ensuite si on a le temps de toucher fortement au code de la réduction des échanges.
Le pied serait aussi de pouvoir avoir plusieurs target : class="ask target-bidule target-machin" avec le parsing qui va bien.
Sinon, je vois qu'il manque le support des requête en POST, c'est à dire la soumission des formulaires. Dommage car ce n'est pas rare d'en trouver. Cela pourrait se faire via la gestion d'évènement sur les onSubmit car beaucoup d'applications-webs utilisent du javascript pour soumettre les formulaires au changement d'une zone via onChange par exemple.
Si quelqu'un développe mon idée concernant un parsing via DOM au retour de la requête pour mettre à jour uniquement les targets, je lui offrirais mon plus grand respect :)
[+] C'est ça le progrès!
Bof l'argument "Accessibilité pour les clients n'utilisant pas Javascript.". Faut vivre à son époque tout de même sinon on roulerait encore avec une botte de foin dans le coffre pour le cheval!. Pourquoi pas "Sans bugs pour IE7" tant qu'on y est!!!
-
[^]Re: C'est ça le progrès!
Posté par kaouete (page perso, ) le 29/10/2007 à 21:28. (lien). Évalué à 3.Mais c'est ce qui est fait dans beaucoup de framework, des fixs pour les bugs de ie6/7 et même pour d'autre navigateur :)
-
[^]Re: C'est ça le progrès!
Posté par wismerhill (page perso, ) le 30/10/2007 à 08:54. (lien). Évalué à 8.C'est vrai que les aveugles on en a rien à foutre hein, ils ont qu'a avoir des tablettes braille qui supportent le javascript.
Et les personnes déficientes moteur n'ont qu'à apprendre à pointer avec la langue, la navigation au clavier c'est un truc du siècle dernier!
Cette page a été générée par Templeet en 11.3651s (dont 0.0076 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.