Chapitre 11 Des langages particulier : les langages du web

11.1 Pourquoi programmer ?

Une réponse générale s'impose: pour obtenir des pages web dynamiques.

Attention, parler de « pages web dynamiques » ne signifie pas qu'on parle nécessairement de pages où tout bouge dans tous les sens. Il s'agit simplement de pages qui n'ont pas d'existence statique, et qui sont construites à la volée, au momment où elles sont demandées au serveur.

Leur utilité se fait sentir quand on doit écrire des pages qui doivent s'adapter (besoin de l'heure, accès à des bases de données, réponse personnalisée, traitement de formulaire, etc.), mais aussi pour faciliter la gestion d'un site (de grande taille par exemple), séparation du contenu (la structure) et du traitement (la présentation).

11.2 Quels langages ?

Beaucoup. Pratiquement tous les langages de programmation peuvent être utilisés, et il existe des langages spécifiques à la programmtion web.

On les classes en deux catégories :

Exécution côté serveur : PHP (syntaxe de type C), ASP (serveur Microsoft), JSP (syntaxe Java), CGI (tout langage, toute plateforme), etc.
Exécution côté client : Javascript (syntaxe Java), applet Java, flash, etc.

11.3 Avantages et inconvénients

	Exécution côté serveur	Exécution côté client
Code source	Pas visible : on n'obtient que le résultat de l'exécution	Javascript : code source visible dans le source de la page¹. Applet : précompilé, donc non lisible.
Rapidité dans l'exécution	Dépend de la vitesse et de la charge du serveur.	Dépend de la vitesse et de la charge du client.
Compatibilité	Totale : le client ne reçoit que du HTML.	Problématique : le client doit posséder le logiciel capable d'exécuter le script (par exemple la bonne version de flash ou de java).
Désactivation par le client	Impossibile, le client n'a pas le contrôle du serveur.	Très simple, il suffit de désactiver le logiciel.
Contrôles de sécurité	Parfaits : tout se passe sur le serveur	Inexistants : tout se passe sur le client².

11.4 Choisir

Lequel choisir ? Bof ! Ça dépend de ce qu'on veut faire. La seule chose certaine c'est que les fonctions importantes (vitales pour l'affichage ou mettant en jeu la sécurité du site) ne doivent pas être confiées à un script qui s'exécute côté client.

À quoi ça ressemble ? Vous trouverez à cette adresse de quoi tester tout ça :
/~torre/Enseignement/TPs/ProgWeb/

1: Ne jamais confier à javascript le contrôle des mots de passe : ils devraient alors être écrits en clair dans le code source de la page web.
2: Ne jamais confier au seul javascript le contrôle de validité des données d'un formulaire, ou un quelconque contrôle de sécurité.

D.Gonzalez (gonzalez@univ-lille3.fr) en date du th ,