Table des matières
Serveur Web 2.0
Ensemble des fichiers : serveur20.zip
Présentation
Objectif : programmer en python un serveur http et un site dynamique.
Dans les sites internets anciens, chaque page était rédigée à la main. Les pages changeaient donc peu et leur rédaction nécessitait quelques bases de programmation.
Nous allons envisager un site dont le contenu peu évoluer automatiquement. Pour l'exemple, nous considérerons le site d'une bibliothèque avec sa base de données contenant les livres, les usagers, les emprunts…
Le contenu d'un tel site doit évoluer dynamiquement en fonction de l'évolution de la base de données :
- Un utilisateur emprunte un livre, le livre doit automatiquement être déclaré indisponible sur le site,
- Un bibliothécaire doit pouvoir ajouter un nouveau livre dans la base et disposer pour cela d'une interface adaptée car il n'est pas censé être programmeur web.
- L'ajout d'un livre par le bibliothécaire doit être automatiquement visible lors des consultations du site par les usagers.
- On pourrait envisager – on ne le fera pas ici – que les usagers puissent ajouter des commentaires sur les livres. Les usagers deviennent ainsi rédacteur du site web. On parle de web participatif ou web 2.0 selon l'expression populaire vers 2005.
Nous avons donc un échange entre une base de données (BDD) et des usagers, l'interface se faisant via une page html.
Deux stratégies
Il existe deux grandes stratégies. Nous suivrons la première. Je donne la seconde pour information.
Première stratégie
- L'utilisateur accède au site sur son ordinateur, le client. Il agit en cliquant sur des liens ou en appuyant sur des boutons de l'interface html.
- Les actions de l'utilisateur se traduisent par des requêtes http du client vers le serveur – requêtes GET et POST.
- Le serveur est à l'écoute, il intercepte les requêtes et réagit.
- Le serveur répond à une requête, par exemple en agissant sur la BDD. Puis en fonction des données, il fabrique automatiquement une page html qu'il renvoie au client.
- Le client affiche la page reçue.
Dans ce cas, le serveur travaille beaucoup car c'est lui qui gère la BDD et qui fabrique les pages pour tous les utilisateurs qui se connectent.
Deuxième stratégie
- L'utilisateur accède au site sur son ordinateur, le client.
- Lors de la première connexion, il reçoit d'un coup toutes les informations concernant l'affichage. Ces informations contiennent notamment une bonne part de code javascript qui s'exécutera dans le navigateur du client.
- L'utilisateur agit en cliquant sur des liens ou en appuyant sur des boutons de l'interface html.
- Les actions de l'utilisateur se traduisent par une exécution de code javascript côté client. Si nécessaire, si une action sur la BDD est requise, le code javascript envoie une requête vers le serveur.
- Le serveur se contente d'agir sur la BDD selon la requête. Il renvoie au client la réponse de la BDD sous une forme brute.
- Si l'affichage doit changer côté client, c'est javascript qui se charge de réactualiser la page.
Dans ce cas, le serveur se contente d'envoyer un gros paquet au début puis de gérer les échanges avec la BDD. Il n'a pas à calculer les pages, c'est javascript qui s'en charge. Les échanges sont plus légers, le travail du serveur réduit. Le client travaille plus mais ce n'est pas gênant car chaque utilisateur dispose d'un client.
Les modules
Nous allons développer différents modules. Un des intérêts du projet est de vous faire découvrir les problématiques d'un travail volumineux et à plusieurs et que vous compreniez l'intérêt de bien découper les différentes parties de l'ensemble.
J'agis comme un chef de projet qui vous donne des consignes concernant les parties que vous devez programmer. Dans un premier temps vous ne comprendrez pas forcément pourquoi il faut développer telle ou telle fonction. Peu importe, respectez les contraintes données.
Répartissez vous le travail : un élève par module !
Construction d'une page
On prend l'exemple d'un utilisateur demandant l'affichage d'un auteur particulier.
Dans la suite nous allons définir les différentes briques de cet ensemble.
Pour bien programmer
Chaque module correspond à un fichier *.py
Vous penserez à faire commencer tous vos fichiers de modules par un commentaire de la forme :
''' module: nom du module description: un mot de description sur ce que fait le module auteur: nom de l'auteur du module '''
Dans le cas des classes, on vous définit l'interface. Ce sont les méthodes et attributs qui doivent figurer obligatoirement.
Vous êtes libre d'en ajouter mais dans ce cas, rendez-les privés pour ne pas alourdir l'interface.
Les méthodes et attributs privés ne sont pas accessibles de l'extérieur de la classe. Ils permettent donc de faciliter la rédaction de la classe sans encombrer l'utilisation.
Python ne gère pas vraiment la visibilité public / privé mais on convient de faire précéder tout attribut ou méthode privé d'un underscore _
Certains préconisent __ mais cette solution a quelques inconvénients sans apporter de protection supplémentaire.
Dans la signature des méthodes ou pour les attributs, quand c'est possible, je précise les types. Une description est aussi bienvenue. Par exemple :
def longueur(p1:Point, p2:Point) -> float:
"""
p1: premier point
p2: second point
renvoie la distance entre p1 et p2
"""
# et ensuite le code de la fonction
Liste des modules
Je vais maintenant définir des modules. Il y en a 6 à rédiger – donc à vous répartir :
- html,
Il faut ajouter les modules suivants :
- bdd qui sera étudié plus tard,
- serveur qui est quasiment complet et sera achevé à la fin,
- routesdefinition qui est commencé et pourra être complété à mesure que le module
bddprogressera.
Et le programme principal main.

