Les
deux navigateurs analysent le même code mais n'arrivent pas au même
résultat.
|
Le
world wide Web est un bon exemple d'architecture client serveur. Lorsqu'un
internaute saisit un url sur son navigateur, il accède à un
serveur web qui lui renvoie le code html de la page demandée. Le
navigateur analyse alors le code obtenu et affiche une page sur l'écran
de l'internaute. Si le navigateur rencontre une balise <img>, il enverra
une nouvelle requête au serveur pour obtenir l'image.
Ce mode de fonctionnement limite la consommation de bande passante et le temps de calcul pour le serveur. En effet, le plus gros du travail est à la charge du navigateur qui s'exécute sur la machine de l'internaute (le client). Cela explique pourquoi d'un navigateur à l'autre, l'apparence d'une même page html est parfois très différente. Les deux navigateurs analysent le même code mais n'arrivent pas au même résultat. Ce manque de cohérence constitue l'un des écueils les plus frustrants du développement html. il est encore plus vif lorsque nous souhaitons ajouter de l'interactivité aux pages web avec Javascipt (langage de programmation coté client), car les différences d'interprétation entre Netscape Communicator et Microsoft Internet Explorer sont considérables dans ce domaine. L'autre
alternative est de réaliser l'ensemble du traitement sur le serveur
et d'envoyer le résultat au client. Cette technique permet une
bien meilleure robustesse de l'application, mais sollicite le serveur
dans des proportions considérables. Cependant, cette dernière
solution s'impose dès lors que la fourniture de contenu statique
n'est plus suffisante. En effet, dans le cas, très fréquent,
d'une page dont le contenu provient d'une base de données, les
solutions purement client sont inenvisageables. Cela reviendrait à
demander à l'internaute de télécharger l'intégralité
de la base de données avant de la consulter. Le réalisateur
de site web doit alors recourir à des solutions de développement
au niveau du serveur dont ASP fait partie. |
|