Discussion :

[ericduval]

Bonjour,

Le bout de code xhtml suivant :
[...]
<div id="mondiv">Premier contenu</div>
[...]

Imaginons un appel vers un script php via xhr qui
renvoi des données à une fonction javascript qui
modifie le div de la façon suivante :
[..]
document.getElementById( "mondiv" ).innerHTML = retour_data_du_script_php;
[...]

Comment gérez vous la conservation des données d'origine du div ?

En cas de reload de la page, les données d'origine seront automatiquement
restaurées, comment pratiquez vous pour maintenir les dernières données
affectées au div ?

Quelles sont les bonnes pratiques pour ce type de gestion ?

Merci d'avance pour vos réponses.

[Invité]

Peut-être stocker le nouveau contenu du div dans un cookie et vérifier son existence au chargement de le page : s'il existe on n'affiche pas le contenu par défaut mais le contenu du cookie.

[ericduval]

Oui j'ai utilisé cette méthode qui est limitée par la taille
max que peux supporter un cookie qui si je me souviens bien
est de 4096 octets.

Je fais des tests en ce moment avec la gestion des sessions
en php. Cela donne de meilleurs résultats qu'avec les cookies.

Mais je ne sais toujours pas si ses méthodes cookies, sessions, etc.... font
parties des méthodes "adoc" ;-)

Peut être y a t-il "LA METHODE", celle qui efface toutes les autres ;-)

[Invité]

A mon avis les sessions c'est pas mal et je vois pas trop ce qu'on pourrait faire de plus propre, mais après je suis pas trop qualifié non plus !

[Nicolas.Cogi]

A mon sens, la bonne methode, c'est celle du "degrade gracefully", mais comme toute bonne methode, elle est bien pénible à implementer

Chaque page de ton application, ajax ou pas, doit correspondre à une url unique.
Une mise à jour de la page via une requete async xhr modifie le DOM et modifie en plus l'url courante (document.location.replace() .en javascript).
Ca permet au passage de faire fonctionner l'appli aussi sur un navigateur ne supportant pas les techniques avancées (javascript désactivé, regles de securité dans une boite, etc...) puisqu'au lieu de javascript, le navigateur suivra simplement les liens hypertextes de ton appli, d'où le "degrade gracefully" plus haut

Avec cette technique (pas simple, pas applicable partout, difficile à developper, mais apres tout on discute là ), il est possible de bookmarker la page (bien pour un catalogue par exemple), d'envoyer le lien de la page à un ami, etc.., et resout au passage ton fameux probleme d'etat.

C'est ce que fait YahooUI, il me semble et sans l'avoir jamais vraiment experimenté moi-meme, leur technique a l'air plutot au point...

[Mike_69]

Dojo Toolkit gère les bookmarks aussi.
je pense que le but si tu veux développrer en AJax est d'utiliser les librairies qui existent.
Sinon, tu vas te casser la tête pour des trucs qui existent déjà

[frodum]

Pour ce genre de chose, j'utilise les # dans l'url.
Comme l'a dit Nicolas.Cogi, j'utilise le document.location.replace de javascript pour modifier l'url.
Par exemple, http...appliAjax.html#page=3;var=value

Puis dans mon code, au lancement de la page ou de la fonction javascript, je check ces variables et je mets à jour ce qu'il faut.

Ca présente l'avantage de ne pas recharger la page puisque l'url de base reste la même http...appliAjax. Le bouton retour et les bookmarks marchent du coup.

C'est pas ce qu'il y a de plus propre mais bon ça fonctionne. Bon l'affichage de l'url n'est pas super joli du coup, mais bon ...

Voilà mon expérience.

[ericduval]

Pour répondre à Nicolas.Cogi, est ce que le jeu "degrade gracefully" en vaut la chandelle ? Je n'en suis pas certain. Je viens de transformer un morceau du code, juste pour voir. C'est beaucoup de gestion en plus aussi bien coté serveur que client.

Beaucoup d'articles (pour ceux que j'ai lu) traitant du "degrade gracefully" datent de 2005. A cette époque les navigateurs n'embarquaient pas tous un interpréteur JavaScript respectant les RFC ou réagissant de la même manières à telles ou telles solicitations.

Aujourd'hui j'aurai tendance à penser que la qualité des implémentations des interpréteurs JavaScript est de bien meilleure qualité.

Est ce qu'aujourd'hui il ne suffit pas d'indiquer sur un site les outils nécessaires
pour le consulter et à faire en sorte que si les outils ne sont pas disponibles proposer un affichage et des fonctionnalités moins riches, voir très pauvres ?

Que deviennent les autres supports de consultations, links, lynx, téléphone, ... ? Je ne sais pas répondre. Bien que, je fais un site pour présenter un travail photographique, est ce que links, lynx etc.... sont des navigateurs adaptés à ce type de site ? Je ne le pense pas. Par contre proposer une page d'accueil indiquant pourquoi le site ne sera pas utilisable me paraît indispensable.

C'est une réflexion ...

Pour répondre à Mike_69, je suis d'accord avec l'usage des API (Aculo, Prototype, Dojo, ....). Par contre il me semble important d'essayer sans pour rencontrer les limites ou/et problèmes de l'utilisation d'AJAX.


Très bon article concernant la gestion des URL transitoires avec AJAX :
http://www.contentwithstyle.co.uk/Articles/38

Sinon, la gestion des sessions (ici en php) donne de bons résultats. Cette semaine je fais implémenter des fonctionnalités plus complexe pour voir si
cette seule gestion est suffisante.

Si vous voulez consulter le site qui nous sert (Phil et moi même) de labo AJAX :
http://www.phptof.org/
User : nouser
Pass : nogroup

Accès abonné :
User : nouser
Pass : nogroup

Les liens à utiliser pour l'observation du mécanisme sont :

Mon profil,
Exposition,
Le lien sur le logo PhpTof
le reload de la page et FireBug pour y voir plus clair.

[Nicolas.Cogi]

Oui, c'est beaucoup de boulot...
c'est pour ca que j'indiquais en fin de post YahooUI, avec leur technique qui, si j'ai vaguement compris, propose de surcharger du html classique propre par leur librairie, transformant ainsi ce html propre qui marche directement, en html plus dynamique, avec utilisation d'ajax là ou c'est interessant, tabcontrol, etc.

Toujours si j'ai bien compris, eux propose de developper pour le navigateur pourri de base, et d'enjoliver le tout pour les navigateurs upperclasse. Et donc, ca fonctionne partout. et donc, ca permet d'avoir une URL par page. et donc c'est cool

Ton affaire de page explicative de pourquoi ca marche pas me rappelle les ptits logos qu'on a vu un peu partout, disant "Site pour Netscape 4.7 only", puis "Site pour Netscape 4.7 et IE 4, en 800x600", puis "Site pour IE only"...

Je pense qu'on sera tous d'accord pour dire aujourd'hui que c'etait une mauvaise pratique. Que des developpeurs peuvent arriver encore aujourd'hui à ce genre de chose (faineantise ou mauvaise comprehension...) alors qu'on peut rendre tout le monde content avec des techniques clean, meme si ca nous demande de travailler plus dure à la source.

tout depend de ta cible, mais imaginons un site comme amazon ou ebay qui ne fonctionnerait qu'avec javascript sans proposer d'alternative (c'est peut-etre le cas, je sais pas ), ca veut dire qu'ils se coupent de tous leurs potentiels clients qui ont désactivés javascript, de ceux qui ont un antivirus ou un antitruc installé, ceux qui ont des contraintes fortes dans leur entreprise, etc, etc...

Donc voila, pour un site entre moi et mes potes, ou je veux m'amuser, impec, je balance toute la sauce de ce qu'il est possible de faire. Pour une appli dont la cible n'est pas connue d'avance (browsers exotiques, ...), il faut trouver une solution de replie sans pour autant désavantager les bons navigateurs.

Tu dis que c'est plus de boulot, tu m'etonnes : je viens de passer 20mins à taper ce post

[ericduval]

Après pas mal de lecture, il ressort les règles suivantes (non exhaustives) à prendre en compte pour mener un développement correct :

- Le site doit fonctionner avec ou sans javascript.

- La navigation ne doit pas dérouter l'utilisateur ceci implique une gestion
propre des actions pages précédentes / pages suivantes, des rechargements de page et des "marque ta page" (bookmark).

- Une gestion de session est plus adapté (plus portable) que l'usage des cookies. Les mécanismes de gestion de session peuvent travailler avec ou sans cookie permettant ainsi de fonctionner même avec les cookies désactivés sur le navigateur.

- L'utilisation d'AJAX (de l'objet XMLHttpRequest) doit être utilisé avec parcimonie. Toutes les requêtes ne sont pas forcément à passer à l'objet XMLHttpRequest. La navigation classique peut être utilisé dans un site à forte tendance AJAX. Cette répartition des modes de navigation est totalement dépendant du projet.

- Les requêtes via l'objet XMLHttpRequest peuvent être synchrone ou asynchrone, ceci étant dépendant du contexte. On préferera le mode asynchrone. Dans le cas du mode synchrone on affichera un message informatif d'attente à l'attention de l'utilisateur.

- L'utilisation du cache doit être maitrisé par l'application au niveau des entêtes.

- Le codage des caractères (charset) doit être correctement initié au niveau des entêtes.

- Le format d'échange des données doit être judicieusement choisi. Il existe différents formats d'échange : XML, JSON, HTML, XHTML (liste non exhaustive). La gestion du XML est bien implémenté dans tous les langages et permet d'échanger facilement les données avec d'autres applications.


Reste plus qu'à le faire ...