Travail effectué - RobinDumontChaponet/synthese GitHub Wiki

Structure du site

Partie visuelle

La charte graphique du site a été établie. Elle nous permet d'instaurer quelques règles concernant l'affichage.

Le menu

Un menu a été placé sous forme d'une colonne bleu verticale placée sur le bord gauche du navigateur.Dans ce menu, il y a deux sous menus: *un en haut de la page: Il regroupes les liens essentiels à l'utilisation du site. Il peut être composé de liens ou de groupes de liens. Le groupe de liens ne sera représenté que par un seul qui, au clic, actionnera une animation: le groupe de liens glisse de la droite vers la gauche pour prendre la place du menu. Une icone en forme de triangle permet d'identifier le lien correspondant à la page active.

*un en bas de la page: Dans ce menu, on retrouve des liens de paramètres. On y retrouve la déconnexion, la gestion de son compte dans laquelle on peut modifier son mot de passe ainsi qu'un bouton d'aide. Au clic du bouton aide, l'utilisateur voit des informations complémentaires s'afficher à différents endroits de la page afin qu'il puisse se retrouver plus facilement sur le site.

Le contenu de la page

Ce contenu est placé sur fond gris clair. Toutes les pages respectes un même schéma. On retrouve toujours le même menu décrit précédemment sur la gauche. Le contenu est donc disposé sur la droite du menu. Le titre de la page est disposé sur la première ligne de chaque page. Tous les boutons d'envoi de formulaire on le même style : bord arrondi, fond gris, couleur de texte noire. Tous les formulaires ont également le même style. Le nom du champs est placé sur la gauche du champs avec dans la majorité des cas, une petite icone illustrative. Le champs quand à lui n'est jamais vide. Soit il a déjà une ancienne valeur à l’intérieur soit il contient le descriptif de la valeur attendue. Le bouton d'envoi du formulaire se trouve toujours en dessous du formulaire. Lorsque l'on est dirigé vers un contenu particulier d'une page, la page descend automatiquement vers la partie visée et une petite animation met en évidence la section demandée.

Organisation interne du site

Framework

Nous avons opter de suivre l'architecture MVC. Ainsi, on retrouve nos objets métiers dans un dossier models contenant tous les modèles avec les DAOs,on retrouve toutes les vues dans un dossier views, tous les contrôleurs des pages dans un dossier controllers. L'index gère l'appel à tous les fichiers nécessaires en fonction de la page demandée. Plusieurs règles ont été établies:

  • le contrôleur se nomme de la même manière que la vue
  • l'index demande le contrôleur et le contrôleur demande la vue.
  • on n'affiche strictement rien dans un contrôleur, c'est toujours la vue qui s'en charge Tous les éléments se rapportant au style des vues se trouvent dans un dossier style. Tous les éléments javascript se trouvent dans un dossier script Un dossier includes est présent. Il contient un certains nombre de fichiers ne correspondant ni au modèle, ni a la vue ni au contrôleur. Pour accéder à un fichier se trouvant dans le dossier includes, il suffit d'inclure le nom du fichier. Pour accéder à un controlleur, il faut utiliser la constante CONTROLLERS_INC suivi du nom du fichier, pour accéder à un model, il faut utiliser la constante MODELS_INC.

Base de données

Implémentation de la base de données

La base de données établie dans la partie d'analyse du projet a été implémentée sur phpMyAdmin. Elle représente un total de 33 tables implémentées. Un petit jeu d'essai à également été mis en place afin de pouvoir tester nos futures requêtes, fonctions en attendant que l'importation du CSV ne soit effective et donc nous permette d'avoir un jeu d'essai plus réaliste et plus conséquent.

Objets metiers

But:

Le but des objets métiers est de pouvoir stocker les informations de la base de données de manière ordonnée dans nos scripts.

Ce qui a été fait:

Nous avons suivi quelques règles pour établir les objets métiers:

  • Chaque entité à un objet
  • Dans une majorité des cas, nous gérons les associations par un objet.
  • Lorsque dans la base de données, la table dispose d'un id, l'attribut de l'objet correspondant s'appelle toujours id.
  • Nous contrôlons les informations reçues dans les objets. Si ces informations ne sont pas bonnes, une exception sera générée.
  • Les attributs sont tous privé
  • Pour récupérer la valeur d'un attribut, un utilise une méthode nommée get+nom de l'attribut
  • Pour modifier la valeur d'un attribut, on utilise une méthode nommée set+attribut(nouvelle valeur)
  • Pour des soucis d’harmonisation des objets, les constructeurs appellent les setters.

Classes DAO

But:

Les classes DAO sont nécessaires pour récupérer les informations de la base de données. Il ne faut effectuer aucune requête en dehors de ces classes. Les DAOs doivent renvoyer des données structurées sous forme d'objet métiers décris plus haut.

Réalisation:

Toujours dans un soucis d'harmonisation, toutes les classes DAO respectent des règles strictes:

  • Il y a une classe DAO par objet métier.
  • Toutes les méthodes de chacune des classes sont statiques.
  • Pour chaque requête, nous récupérons une instance de la connexion au SGBD
  • Toutes les DAOs contiennent au minimum le CRUD (create, research, update, delete)
  • Toutes les méthodes gèrent les exceptions

Connexion au SGBD

La connexion au SQGB se fait grâce à la librairie PDO de Php. Chaque méthode de DAO demande une instance de PDO. A chaque appel, on ne rouvre pas une connexion au SGBD. L'instance de Pdo est stockée dans un objet SPDO qui suit le principe su singleton qui a été définit plus haut.

Recherche

La recherche est divisée en deux parties. Il y a tout d'abord le formulaire dans lequel on rempli les critères de recherche. Ces critères sont les suivants:

  • nom, prenom
  • plage de promotion disponible dans un menu déroulant
  • spécialisation de l'ancien
  • le Diplôme obtenu par l'étudiant à l'IUT dans le département
  • le type de spécialisation
  • le diplôme effectué après l'IUT ainsi que l'établissement
  • si l'ancien travail ou pas

La seconde partie est constitué dans tableau contenant la liste des anciens trouvés suivant ses critères. Tous les résultats ne sont pas affichés sur la même page, il peut y en avoir plusieurs. On peut sélectionner les étudiants et leur envoyer un mail. Le mail ne peut être envoyé que depuis un administrateur ou un professeur.

Importation du csv

L'importation du CSV est disponible en tant qu'administrateur dans la page des promotions. Elle fonctionne comme elle a été définie dans l'analyse fonctionnelle.

Vue des anciens, des promotions

N'importe quel utilisateur du site peux rechercher une personne, voir la liste des promotions et la liste des anciens. On peut visualiser les informations d'un ancien par la page profil. Seuls les administrateurs et l'ancien concerné peuvent modifier les information d'un ancien.

Les événements

Les principales fonctionnalités des événements sont gérées:

  • Les administrateurs ou les professeurs peuvent créer des événements en fonction d'une catégorie et d'une date. Ils peuvent placer une description à cet événement.
  • Tout le monde peut s'inscrire à un événement.

Le réseau social

But:

le réseau social doit permettre de mettre en relation des personnes dans des groupes. Il doit y a voir un groupe général, un groupe pour chaque promotion et différents groupes crées par les anciens ou les professeurs.

Etat actuel:

Actuellement, cette fonctionnalité n'est pas opérationnelle. Il est bien possible de créer des groupes, de poster dans le groupe, de commenter un post, de tout modifier mais il n'est pas encore possible de pouvoir ajouter des utilisateurs à un groupe. Cet ajout devrait ce faire en sélectionnant des étudiants dans la recherche.