Projet Web 2
L'application doit être réalisée en ayant une architecture Modèle Vue Contrôleur sur le Framework PHP Symfony avec comme moteur de Template « twig ».
* Une version minimum (point en gras dans la feuille d’évaluation) qui utilise la structure jointe en ressource.
* Lors de l’évaluation les points suivants seront pris en compte : application REST, sécurité… , utilisation de l'ORM doctrine.
* Le « design » dans ce projet est évalué.
Objectif : Réaliser une application pour commander des produits
La base de données doit comprendre au minimum 7 tables (« produit », « typeProduit »,
« commande », « user », « lignes_commande », « panier », « etat » (en attente, expédié) ). . Pour chaque produit qui compose une commande (une ligne du panier), enregistrer :
* Le nombre de produit associé (ainsi que le prix lors de l'achat car le vendeur peut faire évoluer le prix d'un produit dans le temps).
* L'identifiant du client (qui est dans la session)
* La date de la commande
Pour garder une trace du panier, on n'utilise pas de variable de sessions pour sauvegarder le panier.
Dans ce cas le diagramme ERD (entity relational diagram) est composé de différentes entités:
Dans chaque entité, les attributs placés sous « +--- » sont générés automatiquement par l’assistant
Le nom des entités ainsi que le nom des contrôleurs qui gèrent les événements sur ces entités doivent respecter les noms sur ce schéma : nom identique (pour éviter les copier/coller avec le projet de l’année dernière)
dateAchat ou dateAjout
* exemple de tables SQL générées :
Commandes (front Office) :
Un client peut remplir un panier en étant connecté. Il peut alors valider sa commande durant une petite période (à définir) . (on suppose que l'adresse de livraison est l'adresse du client).
Lorsque le client ajoute un produit dans le panier, 2 cas peuvent se présenter :
* Si le produit n'existe pas dans le panier, il faut alors créer une nouvelle ligne avec les références du produit dans le panier.
* Si le produit est déjà présent dans le panier, il faudra mettre à jour la quantité de ce produit
* Prévoir un moyen pour soit modifier la quantité (champ d'entrée), soit décrémenter la quantité (bouton + / -), soit supprimer le produit du panier.
La validation du panier provoque la création d'une commande, le panier n'est plus affiché, mais le client pourra consulter ses commandes ainsi que leur état.
Dans la théorie, le client doit s'acquitter du payement avant de valider la commande (par paypal, banque … ), cette partie n'est pas à gérer.
Prévoir une vue qui affiche les produits et le panier pour faire la démo, cependant vous pouvez par la suite la modifier
Gestion des Commandes (back Office) :
Après connexion, le vendeur peut mettre à jour toutes les informations des produits d'une semaine disponibles à la vente (ajout/modification/suppression).
Préparation des commandes
Il peut naviguer facilement de commande en commande et passer l'état d'une commande de « À préparer » à « Expédier » (il n’est pas nécessaire de gérer les états « Préparer » et « Livrer ») Il peut facilement signaler qu'un produit n'est plus disponible.
La structure minimum est évaluée chaque semaine avec des objectifs (voir feuille de suivi)
Lors de la dernière séance, plusieurs éléments qui améliorent l'application seront validés Coté client (front Office)
- Un client peut afficher les produits par type ou/et par tranche de prix(min/max).
- Un client peut ajouter des commentaires : si il a commandé un produit, il peut laisser un commentaire sur ce produit
* utiliser de préférence un éditeur « wysiwyg » pour les commentaires (http://www.tinymce.com/
par exemple), lors de la création des commentaires
* Un utilisateur (client) peut changer de nom, email, mot de passe, prénom, adresse ….
* Mettre un système de captcha lors de la création des comptes
Coté vendeur (back Office)
* lors d'une commande le stock est mis à jour (option)
- le vendeur peut voir à l'affichage : stock réel, stock après expédition des commandes en cours.
- le vendeur peut mettre à jour le stock (arrivage de produits, produits défectueux …), une modification du MR pourrait permettre de garder une trace de ces modifications
* comme sur certains sites de vente : le stock restant est affiché si il y a moins de 10 produits sinon le produit est indiqué comme « disponible », un client ne peut pas commander plus de produits que dans le stock.
* Chargement d'image : le vendeur peut faire un « upload » des images de ces produits
* synthèse sur les ventes pendant une période (les 7 derniers jours par défaut), l’administrateur dispose d’un formulaire pour modifier cette période.
- tableau des produits qui marchent le mieux : les plus vendus, ceux avec le meilleur chiffre d’affaire ; afficher le nombre de vente, le chiffre d’affaire par produit (pour les produits qui ont le plus de succès (sur une période : les 7 derniers jours par défaut). Afficher aussi le nombre de produits vendus et leurs CA pour le site de vente sur cette période.
Sécurité
* Middleware pour contrôler les routes en fonction des droits des personnes authentifiées
* Application REST : chaque fois qu'un événement « click souris» ou une validation permet
d'ajouter/modifier/supprimer un/des enregistrement(s) dans une table, utiliser un formulaire avec le bon verbe dans la route (post/put/delete)
* Token : application REST : méthodes post/put/delete en passant par un formulaire pour ajouter/modifier/supprimer des enregistrements dans une table (utilisation d’un « token »), utilisation d’un « middleware » pour contrôler ce « token ».
Interface
Pour ce projet, l'ergonomie de l'interface est prise en compte ainsi que l'utilisabilité du site.
* Un jeu de test (image …. ) qui donne un aspect « réel » à l'application
* Une bonne utilisation du « framework BootStrap » est un plus afin d'obtenir un site
« responsive », autre d'un autre framework CSS.
* La gestion des erreurs dans les formulaires.
* Affichage du front-office (client) : produits affichés sous forme de grille « responsive »
semaine 2 :
- créer un nouveau projet symfony
- créer 3 entités : Produit , TypeProduit et User
- réaliser le CRUD pour gérer les Produit, vous pouvez utiliser l’assistant (commande pour générer un crud), cependant modifier les routes pour que toutes les routes commencent par /admin - gestion de l’authentification (créer l’entité User), seul l’administrateur peut ajouter, modifier, supprimer des enregistrements dans les 2 entités ci-dessus
- créer les fixtures pour 3 utilisateurs (admin (ROLE_ADMIN), user1 (ROLE_USER) et user2 (ROLE_USER))
semaine 3 :
- espace client (affichage des produits) / affichage du panier
- ajout/suppression des produits dans le panier
semaine 4 :
- Modification du nombre des produits dans le panier/ validation de la commande semaine 5 :
- consultation des commandes - changement login/email/adresse de l'utilisateur
semaine 7/8 :
- validation du projet
