Club de Badminton Derré Yann, Becker Esteban
Introduction : 3 Organisation : 3 Cahier des charges 4 Base de données : 5 Documentation des tables : 5 Relations : 6 Site web : 7 BDD.php 7 menu.php 7 index.php : 7 connexion.php : 7 inscription.php : 7 enregistrement.php : 8 modifier_profile.php : 8 appliquer_modification.php : 8 classement_reservation.php : 9 licence.php : 9 enregistrement_licence.php : 9 recherche.php : 9 upgrade_admin.php : 9 Profile.php 10 Aurevoir_reservation.php 11 Edit_reservation.php 11 Apply_edit.php 12 Reservations.php 12 Add_réservation.php 14 Edit_reservation_admin.php 14 DIVERS 14 Conclusion 15
Nous avons choisi le club de badminton car contrairement au projet de banque alimentaire, nous avions directement une idée de comment structurer la base de données lié au site web.
De plus, faisant régulièrement du sport, nous étions plus familiers des sites web liés aux club sportif.
L’organisation du projet aura été complexe. Nous avons tout de suite défini que nous travaillerons avec GitHub (https://github.com/derreyann/websiteif3) plutôt que des outils d’édition de code en simultané. Afin de pouvoir rapidement commencer à se départager les pages web à programmer, on a décidé de construire en premier la base de données afin de l’exporter et de l’a partager sur nos deux postes de travail.
Au début nous avons voulu utiliser Notion, un outil qui permet de faire de la gestion de projet, en faisant par exemple des frises chronologiques pour nous organiser. Mais, malheureusement, par manque de motivation et de rigueur nous avons délaissé l’outil. À la place, nous codions les pages du site quand nous avions du temps libre. Cette méthode possède un défaut majeur, nous avions du mal à nous synchroniser. Il nous est arrivé de commencer à travailler sur la même page avant de nous rendre compte que nous codions la même chose.
De plus, cette organisation trouvera certainement ses limites sur un projet beaucoup plus complexe, où il y a plus d’interactions entre les différentes parties.
Voici la liste des fonctions que doit permettre le site web :
- Permettre à un utilisateur de s’enregistrer
- Permettre à un administrateur de gérer les profils
- Permettre à un cotisant de réserver un terrain
- Permettre à un administrateur de gérer les réservations
- Permettre à un administrateur d’ajouter une cotisation
- Permettre aux utilisateurs d’effectuer une recherche par nom ou prénom
- Permettre à un utilisateur de modifier son profil
- Permettre à un utilisateur de modifier sa réservation
- Permettre à l’utilisateur de naviguer le site avec un menu visible en tête de page
Afin de concevoir la base de données nous avons utilisé un diagramme. Il nous a permis d’avoir une vision claire de la base de données ainsi que de vérifier qu’elle correspondait au norme 1NF, 2NF et 3NF.
Utilisateur : Table qui représente un utilisateur du site
| Nom | Type de valeur | Description |
|---|---|---|
| id | Entier, clé primaire | |
| type_compte | Entier | Définit si un utilisateur est admin 0 -> admin 1 -> Utilisateur normal |
| nom | Chaine de caractère | |
| prenom | Chaine de caractère | |
| Chaire de caractère | ||
| MdP | Chaine de caractère | Mot de passe hashé avec la fonction PASSWORD de SQL |
| naissance | date |
Licence : Table qui représente la liste de toutes les licences
| Nom | Type de valeur | Description |
|---|---|---|
| user_id | Entier, clé primaire clé étrangère qui fait référence à utilisateur.id |
|
| date_souscription | date | Date à laquelle l’utilisateur à commencer sa licence |
| durée | int | Durée de la licence en jour |
Réservation : Table de jointure entre terrain et utilisateur qui représente une réservation par un utilisateur
| Nom | Type de valeur | Description |
|---|---|---|
| id_user_1 | Entier clé étrangère qui fait référence à utilisateur.id |
Utilisateur qui effectue la réservation |
| id_user_2 | Entier clé étrangère qui fait référence à utilisateur.id Optionnel |
Utilisateur avec qui la réservation est effectué (Peut rester vide) |
| id_terrain | clé étrangère qui fait référence à terrain.id | Terrain réservé |
| date | date | Date de la réservation |
| h_debut | Entier | Horaire de la réservation |
| durée | Entier | Durée de la réservation en heure |
Terrain : Table qui représente les terrains
| Nom | Type de valeur | Description |
|---|---|---|
| id | Entier, clé primaire | Id du terrain |
- Souscrit : relation 1:N
Relie un utilisateur avec toutes les licences qu’il a souscrit.
- Réserve : relation N:M
Relie un utilisateur aux terrains qu’il a réservé en utilisant une table de jointure.
Cette page n’affiche rien, il s’agit uniquement de script php à inclure dans d’autres pages.
Le scripte effectue la connexion à la base de données. Avoir une seule page permet de modifier les paramètres de connexion à la base de données à un seul endroit pour tout le site.
La fonction « iscotisant » renvoie TRUE ou FALSE si l’utilisateur en cotisant en fonction de son id.
Cette page affiche un menu en haut du site web.
« menu.css » Permet d’afficher les option du menu cote à cote.
Cette page est composée d’un formulaire demandant les informations de connexion d’un utilisateur et d’un bouton vers la page inscription.php.
Quand le formulaire est soumis il renvoie vers la page connexion.php.
La page permet d’afficher un message d’erreur en l’incluant dans le lien.
La page vérifie si les informations rentrées dans le formulaire de index.php sont dans la base de données.
Si elles sont correctes, la page crée une session avec les identifiants de connexion et redirige vers profile.php
Si elles sont fausses, la page renvoie vers index.php avec un message d’erreur
Cette page est composée d’un formulaire demandant les informations d’inscription d’un utilisateur en utilisant les vérifications de format des données entrées.
Quand le formulaire est soumis il renvoie vers la page enregistrement.php.
La page permet d’afficher un message d’erreur en l’incluant dans le lien.
Cette page est un scripte php qui vérifie si l’adresse e-mail existe déjà dans la base de données.
Si elle existe elle renvoie vers inscription.php avec un message d’erreur.
Si elle n’existe pas, les informations du formulaire sont ajoutées dans la base de données. Une session est créée et le la page renvoie vers profile.php.
Cette page affiche le formulaire qui permet de modifier un profile.
Si aucun id n’est indiqué dans l’url, la page modifie le profil de l’utilisateur actuellement connecté. Si aucun utilisateur est connecté, la page renvoie vers index.php avec un message d’erreur
Si l’id d’un utilisateur est indiqué dans l’url, la page vérifie que l’id existe réellement. Si l’utilisateur n’existe pas la page affiche un message d’erreur.
Elle va aussi vérifier si l’utilisateur connecté est un administrateur. Si l’utilisateur n’est pas un administrateur, la page va rediriger vers index.php avec un message d’erreur.
La page est constituée d’un formulaire où les champs sont préremplis avec les informations de l’utilisateur.
Le bouton de soumission de formulaire renvoie vers appliquer_modification.php
Cette page effectue la mise a jour dans la base de données des informations rentré dans modifier_profile.php
Elle va d’abord vérifier que l’utilisateur qui effectue la requête a bien les autorisations nécessaires, sinon, la page affichera un message d’erreur.
Si l’utilisateur a bien les autorisations la page effectue les modifications et renvoie vers profile.php
Cette page affiche le classement des utilisateurs ayant le plus de réservations
Elle effectue une requête SQL dans la base de données en groupant les résultats par id et en les classant par ordre décroissant.
La page vérifie que l’utilisateur connecté est un administrateur et que l’utilisateur à qui on veut ajouter une licence existe et ne soit pas cotisant. Si ces critères ne sont pas réunie la page affiche un message d’erreur.
Il s’agit d’un simple formulaire qui demande la durée de la licence et le bouton de soumission renvoie vers enregistrement_licence.php
Cette page vérifie que l’utilisateur connecté est un admin, si l’utilisateur n’est pas admin elle renvoie un message d’erreur.
Un fois la vérification effectuée, elle ajoute la nouvelle licence dans la table licence de la base de données.
Cette page vérifie que l’utilisateur est connecté. Elle possède un champ qui permet d’effectuer une cherche dans les noms et les prénoms de la base de données. Une fois le formulaire soumit, la page est actualisée avec la liste des profils avec un nom ou un prénom correspondant.
Chaque un de ces résultats permet d’être redirigé vers la page de l’utilisateur en cliquant dessus.
Cette page vérifie que l’utilisateur connecté est admin puis modifie le type de profile de l’utilisateur dont l’id est dans l’url.
Cette page est la page d’arrivée après la connexion. Elle permet à l’utilisateur de consulter ses réservations et de consulter ses informations. Elle recherche dans la base de données les informations de réservations possédant l’id de la session utilisateur en tant qu’id_user_1 de la table réservations.
Une boucle while dans le tableau se charge ensuite d’afficher chaque résultat.
Une difficulté rencontrée était d’afficher des boutons d’édition et de suppression afin que l’utilisateur altère sa réservation. Pour y remédier, nous avons utilisé des formulaires cachés pour transmettre les données de la ligne.
Les boutons visibles ne sont finalement que les submits des formulaires invisibles. Nous réutiliserons les données dans les différentes pages d’édition et de suppression.
Le profil dispose également d’une section historique, affichant les réservations effectuées à une date antérieur à celle de l’horloge du serveur.
Cette page se charge simplement de supprimer la ligne dont les données correpondent à celles du formulaire invisible renvoyé dans profile.php
Cette page est une page d’édition d’une ligne de réservation de profile.php. Le formulaire est pré-rempli avec les valeurs transmises par un formulaire invisible. Puis les nouvelles valeurs sont renvoyées à la page apply_edit.php. Un utilisateur lambda voit la première case désactivée, s’agissant de la personne ayant fait la réservation.
Recherche les informations des emails utilisateurs rentrés dans le formulaire, puis insère les IDs des utilisateurs correspondants dans la base de donnée. La philosophie adoptée pour le stockage et l’affichage des utilisateurs est d’effectuer une conversion email-id à l’input, et id-nom à l’affichage dans tous les formulaires.
Réservation.php est une autre page principale du site, où les utilisateurs connectés peuvent consulter les réservations en cours, et faire une nouvelle réservation. Le tableau d’affichage est virtuellement le même que celui de profile.php, mais celui-ci recherche tous les enregistrements disponibles.
Un formulaire permet de rajouter une nouvelle réservation, renvoyant à la page add_réservations. Si un utilisateur souhaite ramener des invités, il peut laisser le champ vide.
Check du type_compte dans la table utilisateur (visible aux administrateurs uniquement)
Pour les administrateurs, la page propose de modifier et de supprimer les réservations, en redirigeant vers une page d’édition spéciale.
Cette page vérifie que le créneau demandé est bien disponible en recherchant les réservations sur la date dans la période indiquée.
Cette page effectue une conversion des emails rentrés pour obtenir leurs ids respectifs, puis insère une nouvelle ligne dans la base de données réservations avec ces données.
Elle redirige ensuite vers profile.php
Pour les comptes administrateurs, il faut pouvoir modifier si besoin les réservations des utilisateurs, ou bien verrouiller un créneau périodiquement pour un cours par exemple.
La page est essentiellement la même qu’edit_reservation.php à l’exception de la possibilité de modifier l’auteur de la réservation (accès au champ joueur1), et d’ajouter périodiquement un cours sur un nombre de semaines.
Cette page vérifie le status du compte afin de s’assurer que seuls les administrateurs puissent le modifier. Sinon, il redirige vers le profil.
Nous avons expérimenté avec le CSS. Vers la fin du projet, nous avons décidé de donner un style aux formulaires et tableaux sur les pages. N’étant pas complètement familier avec la syntaxe, l’utilisation de stylesheets est encore très maladroite. Le résultat obtenu permet tout de fois une meilleure prise en main du site web.
Nous avons finalement réussi à concevoir un site web fonctionnel, utilisable par des utilisateurs lambda au travers d’une interface compréhensible et d’un contrôle des entrées utilisateurs.
Les problèmes organisationnels peuvent cependant poser problème sur des projets de plus grande ampleur, une répartition du travail plus équitable au cours du temps pouvant empêcher des sessions de code trop longues.
Ce projet nous a permis de devenir à l’aise avec la construction et l’interaction sql-php. Nous aurons également appris à se mettre à la place de l’utilisateur afin de concevoir des fonctions attendues d’un produit comme ce site de réservation.
Ces compétences pourront être réutilisées dans le futur, même si le langage/contexte utilisé diffère.