Discussion :

[Pgs]

Bonjour,

Je m'interroge sur la différence entre :

* l'utilisation des procédures Ajax,
* l'utilisation d'une page web contenant deux cadres (dont un n'est pas visible car hauteur à 0) : la page visible appelle la page contenue dans le cadre caché : cette dernière contient les instructions de mise à jour de la page principales (echo '<javascript...').

Merci pour tout éclaircissment.

Phil

[juliens9]

Meme si tu peux obtenir les memes résultats, passez par de l'ajax est beaucoup pus propre que des faires des cadres, sachant que sur certains navigateur et appareil de téléphonie mobiles, les cadres ne passent pas.

Puis tu pourra aller beaucoup plus avec de l'ajax car ton code est inclus dans la page et non à l'extérieur.

[Rakken]

Pareil que la réponse précédente. Avoir un cadre caché pour faire des opérations n'est franchement pas une solution propre.

[Pgs]

Merci pour ces éléments.

Concernant le problème de compatibilité des cadres, Ajax résoud il ce problème ? Est il compatible avec plus de plateformes ?

A bientôt

Phil

[Rakken]

En fait, pas reelement. Le problème d'Ajax, c'est que ca reste du javascript, et quand le javascript n'est pas activé (si on utilise un navigateur texte par exemple (utilisé par les aveugles notamment), ou googlebot) ben rien ne fonctionne. Mais si ca ne marche pas en ajax, il n'y a pas vraiment de raison que ca fonctionne avec des frames.
C'est juste plus propre.
Après, dans la plupart des cas, avec du php ou du java, il y a moyen de s'en passer. Le javascript devrait a mon sens rester a une utilisation de confort, le traitement réel doit être fait par un langage coté serveur.

[Pgs]

Bonjour Rakken,

Je suis totalement d'accord avec toi. Je trouve que le côté serveur a en plus le gros avantage de rendre le code privé.

Mais alors, serait il possible, par exemple, de gérer côté serveur la mise à jour partielle de la page en fonction des actions côté client (le choix dans un menu modifie les options d'un autre menu etc.).

Bonne journée.

[Rakken]

Pour qu'il y ait mise a jour de la page, il faut un aller-retour, navigateur-serveur. Ca se fait de facon completement transparente avec par exemple les lien html (a href).
Maintenant, si tu veux une mise a jour "partielle", un vrai problème se pose. Les liens basiques chargent "une page", pas un morceau de page. Pour contourner ca, on en revient a l'ajax ou aux frames. Ou alors on charge tout, en réaffichant completement même les morceaux qui n'auraient pas eu besoin d'être rechargé.

J'ai été confronté au problème, j'avais un site avec un menu dans une frame qui chargait du contenu dans la page principale. A la navigation, c'était très agréable, parce que seule la partie contenu était rechargée, mais pour des raisons de référencement notamment (très mauvais référencement des pages internes, et quand elles étaient affichées, c'était sans cadre, donc sans moyen de voir l'intégralité du site) j'ai transformé le tout et maintenant, a chaque fois que je clique sur un lien de mon menu, ca me recharge tout. J'y ai effectivement beaucoup gagné en référencement.
Ca m'a fait beaucoup raler a l'époque, mais il n'y a pas d'autres choix. Frame, Ajax ou rechargement complet. Après il faut que tu pèses le pour et le contre de chaque solution et que tu choisises la plus adaptée (ou la moins mauvaise).

Eh oui, le web 2.0 a aussi ses lacunes, et pas petites en plus.

[Pgs]

Entre rechargement complet et ajax, tu sembles pencher pour la première solution. Quelles limites vois tu à ajax ?

Phil

[Rakken]

Googlebot n'est pas capable de suivre les liens ajax. Ce qui signifie a la fois que le site ne sera pas "accessible", et qu'il aura un référecement interne inexistant (bon, il y a toujours moyen de mettre en place des palliatifs (du genre sitemap), mais ca reste une béquille.
Et le second point, ca ne marche pas si l'utilisateur n'a pas le javascript activé.
Le rechargement total, lui fonctionne partout est est bien référencé. Mais pour l'utilisateur c'est un peu moins agréable pour cause de rechargement inutile, mais le problème est réduit avec les caches des navigateurs et le haut-debit.

Un test interessant est de télécharger Lynx, un navigateur texte, correspondant globablement a ce que les moteurs de recherche voient de ton site (et également utilisé par les aveugles en couplage avec un système de lecture braille/sonore). Si ca passe sous lynx, alors c'est tout bon. Enfin, ca n'empeche pas de suivre les normes de la w3c, mais elle vont naturellement dans ce sens pour la plupart de toute maniere.

[Pgs]

Merci pour ces éclaircissements.

Phil