Blog ENI : Toute la veille numérique !
🐠 -25€ dès 75€ 
+ 7 jours d'accès à la Bibliothèque Numérique ENI. Cliquez ici
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. PHP et MySQL
  3. Énoncé 3 : Les demandes
Extrait - PHP et MySQL Entraînez-vous à développer une application collaborative
Extraits du livre
PHP et MySQL Entraînez-vous à développer une application collaborative Revenir à la page d'achat du livre

Énoncé 3 : Les demandes

Introduction

Durée

5 heures 45

Mots-clés

Modèle, vue, contrôleur, action, entité, authentification, autorisation, validation.

Objectifs

Les derniers TP du chapitre Gestion des utilisateurs ont servi de transition vers le développement MVC (Modèle-Vue-Contrôleur). Cette approche organise le code de façon à séparer les différentes fonctions de l’architecture. Le contrôleur comprend la logique de traitement des requêtes, ses fonctions sont appelées actions. Le modèle est un objet de données (aussi appelé entité ou PDO pour PHP Data Object). Il sert à la fois d’entrée (il contient les valeurs de formulaire postées par le navigateur) et de sortie (les valeurs résultant du traitement de la requête à afficher). La vue est en charge de la présentation des données, elle ne contient pas de traitement, lesquels sont toujours déportés en dehors de la vue, généralement dans un contrôleur.

Ce chapitre développe des exercices s’appuyant sur le framework FPL. Ce mini framework, conçu dans le cadre de cet ouvrage, supporte la cinématique MVC et propose quelques services utiles comme la validation des saisies ou la sécurité (authentification, autorisation).

Prérequis

Pour valider les prérequis nécessaires, avant d’aborder le TP, répondez aux questions ci-après :

1.

Quel est le mot-clé PHP pour définir un espace de noms ?

 

a.

spacename

 

b.

namespace

 

c.

spaceman

 

d.

package

2.

Quel est le mot-clé PHP pour hériter d’une classe ?

 

a.

implement

 

b.

inherits

 

c.

extend

 

d.

baseClass

3.

Quelles sont les applications de la réécriture d’URL ?

 

a.

Pour faciliter l’indexation par les moteurs de recherche

 

b.

Pour modifier la façon dont les traitements serveur sont déclenchés

 

c.

Pour optimiser la vitesse de traitement d’un site

 

d.

Pour sécuriser un site web

4.

Comment désigne-t-on les traitements implémentés dans un contrôleur ?

 

a.

Des requêtes

 

b.

Des réactions

 

c.

Des actions

 

d.

Des méthodes-requêtes

5.

Qu’est-ce qu’un view model ?

 

a.

Une page servant à la fois de modèle et de vue

 

b.

Un objet de transfert de données entre une vue et un contrôleur

 

c.

Un template de vue

6.

Quelle est la syntaxe PHP pour définir des annotations ?

 

a.

Les annotations sont définies par les signes [ et ]

 

b.

Les annotations sont définies par les signes { et }

 ...

Énoncé 3.1 Afficher la page d’accueil en MVC

Durée estimative : 30 minutes

Ce premier exercice consiste à afficher la page d’accueil du site teamup à l’aide du framework FPL et des éléments déjà réalisés au premier chapitre. Nous avons besoin d’un contrôleur homeController et d’une action appelée index. Le fichier router.php reçoit toutes les requêtes situées sous l’URI teamup/application dont l’URL se termine par .do, le script décode certains segments de l’URL qui définissent la route : http://localhost/teamup/application/general-home-index.do

http

Protocole, peut être http ou https

localhost

Nom de domaine ou adresse IP

Peut être remplacé ici par 127.0.0.1

teamup

Répertoire (virtuel) de l’application

application

Dossier contenant les pages du site

general

Décodé par router.php comme zone. Une zone est un ensemble de pages web, une sorte de module au sens fonctionnel.

home

Décodé par router.php comme contrôleur. Un contrôleur comprend un ensemble de traitements appelés actions.

index

Décodé par router.php comme action. Une action est le traitement d’une requête.

.do

L’extension .do transfère l’exécution de la requête au script router.php

Dans cet exemple...

Énoncé 3.2 Réaliser la page de connexion en MVC

Durée estimative : 30 minutes

Passons maintenant à la réalisation d’une page comportant un formulaire à traiter en MVC. Cette page de connexion demande à l’utilisateur son identifiant et son mot de passe, lesquels doivent respecter certaines règles de conformité (valeurs non vides). Dans un premier temps, les crédits de connexion sont vérifiés à partir de valeurs configurées par défaut, et le TP 3.4 sera l’occasion d’améliorer ce fonctionnement en raccordant la vérification à la base de données. 

 Créez dans le dossier application\controllers un sous-dossier usermgt. Il s’agit de la zone de gestion des utilisateurs.

Créez un contrôleur userController.php en reprenant les étapes du précédent TP.

Pensez à définir l’espace de noms et à nommer la classe comme il convient.

Créez dans le dossier models le fichier loginmodel.php portant la classe entité loginModel selon le script ci-dessous. Les annotations @Required sont utilisées pour définir les règles de validation.

class loginModel { 
  
   /** 
    * @Required(error="L'identifiant est requis",property="login") 
    * @var string 
    */ 
   public $login; 
 
   /** 
    * @Required(error="Le mot de passe est requis",property="pwd") 
    * @var string 
    */ 
   public $pwd; 
 
   public $login_action; 
} 

Définissez dans le contrôleur l’action login($view_model). Dans...

Énoncé 3.3 Activer l’authentification

Durée estimative : 45 minutes

Par défaut, les utilisateurs sont anonymes et les accès sont autorisés pour ces utilisateurs à l’ensemble des contrôleurs et de leurs actions. L’annotation @Autorisation appliquée soit au niveau du contrôleur soit au niveau de l’action filtre les accès à certains utilisateurs (anonymes ou nommés). Pour activer l’authentification au niveau de tout le site, il convient d’interdire l’accès aux utilisateurs anonymes à l’ensemble des contrôleurs, excepté userController qui réalise l’authentification. Pour l’instant, l’application n’a défini qu’un seul contrôleur en dehors de celui de connexion.

 Appliquez l’annotation @Autorisation(access_control_mode=Autorisation::DENY_ANONYMOUS) au niveau du contrôleur homeController.

Testez l’URL http://localhost/teamup/application/general-home-index.do et vérifiez que le navigateur est redirigé vers la page de connexion. Après saisie de logins valides, l’utilisateur authentifié accède bien à la page d’accueil.

 Créez dans le contrôleur userController une action listusers() puis une vue listusers.php. Cette vue reprend le code du TP 2.5. Testez l’affichage...

Énoncé 3.4 Brancher l’authentification sur la base de données

Durée estimative : 20 minutes

À titre de tests, le fichier config.php prévoit quelques logins codés en dur. Il est temps de dépasser cette limitation et de raccorder le module de sécurité à la base de données.

 Ouvrez le fichier comfpl\security.php et recherchez la méthode check_credentials(). Modifiez cette méthode pour vérifier les crédits utilisateurs passés en paramètres dans la table utilisateur.

Les informations de connexion à la base sont disponibles dans le fichier config.php.

 Vérifiez que l’authentification fonctionne à l’aide de crédits utilisateurs insérés dans la base de données au chapitre Gestion des utilisateurs.

Énoncé 3.5 Tables SQL pour les demandes et les classes de données

Durée estimative : 45 minutes

Ce TP ne présente pas de difficulté, mais il est essentiel à la réalisation des prochains exercices. Une demande est en soi un formulaire pour décrire une tâche à réaliser. Elle peut être assignée à n’importe quel utilisateur.

 Créez la table type_demande(id_type_demande,type_demande_label) et insérez les valeurs suivantes :

1

Simple demande

2

Rendez-vous

3

Appel

4

Document

Créez la table demande(id_demande,demande_objet,demande_texte,demande_date_creation,demande_date_echeance,id_type_demande,id_utilisateur NULL). Insérez quelques lignes dans la table.

 Créez les PDO typeDemandeEntity et demandeEntity.

 Créez les classes TypeDemandeDAO et TypeDemandeService contenant la méthode getlisttypedemande().

 Créez les classes DemandeDAO et DemandeService contenant les méthodes getlistdemandes(), adddemande(demandeEntity) et editdemande(demandeEntity.

Énoncé 3.6 Saisir des demandes

Durée estimative : 60 minutes

Ce TP illustre le fonctionnement et l’intérêt de MVC dans une page comprenant un formulaire.

 Créez une zone demandes au niveau contrôleur et vue.

 Ajoutez un contrôleur demandeController ainsi qu’une action index().

 Ajoutez une vue index.php affichant provisoirement « Liste des demandes ».

 Ajoutez une action adddemande($view_model) et une vue adddemande.php basée sur le template _mainlayout. Insérez un lien vers adddemande() dans index.php.

 Créez une entité demandeViewModel composée d’une entité demandeEntity et d’un tableau de typeDemandeEntity.

 Appelez TypeDemandeService::gettypedemandelist() et convertissez le tableau d’entité en un tableau associatif, où la clé correspond à l’identifiant du type de demande et la valeur à son libellé. Modifiez l’action adddemande pour transmettre à la vue une instance de demandeViewModel initialisée du tableau associatif ainsi créé.

Instanciez également le champ demande à partir de la classe demandeEntity.

 Créez un formulaire structuré selon les colonnes de la table demande.

Le formulaire peut se créer directement à partir des balises HTML <input>...

Énoncé 3.7 Affichage d’une demande

Durée estimative : 30 minutes

À présent que les URL des actions nous sont connues (zone-contrôleur-action.do), nous allons introduire des paramètres. Le but est de sélectionner dans la table demande l’enregistrement qui correspond à l’identifiant indiqué dans la requête. Pour cela, l’attribut @Route vient préciser quels arguments admet la requête.

 Créez dans le contrôleur demande une action editdemande($view_model) qui renvoie vers la vue du même nom. Répliquez le code de l’action adddemande pour charger la liste des types de demande.

 Ajoutez juste avant la déclaration de l’action editdemande() l’annotation @Route ci-dessous pour déclarer un paramètre id :

@Route(parameters="id-{id}") 

Le script router.php va maintenant décoder l’URL de la façon suivante : http://localhost/teamup/application/demandes-demande-editdemande.do-id-XXX où XXX est l’identifiant de la demande (a priori un nombre entier, si c’est bien le format choisi en base de données).

Le paramètre $view_model comporte désormais la propriété id valorisée selon le nombre indiqué dans l’URL. Recopiez cette propriété de $view_model dans l’entité...

Énoncé 3.8 Liste des demandes

Durée estimative : 25 minutes

Bien entendu, nous attendons de notre application qu’elle génère elle-même les URL en incluant le paramètre id. C’est l’objet de cet exercice.

 Ajoutez dans le contrôleur une méthode getdemandedata($page=null,$limit=null) qui interroge la base de données et pagine les résultats.

Il serait intéressant de modifier les requêtes SQL pour paginer le résultat en dehors du code PHP et ainsi améliorer les performances du site.

Ajoutez une action listdemandedata($page=null,$limit=null) qui retourne la liste getdemandedata() sous la forme d’un flux JSON. Le code est identique aux TP 2.5 et 3.3.

 Créez la vue listdemandes.php et présentez les colonnes ID, demande_date_creation, demande_objet dans une grille de données.

Le code HTML est là encore très semblable aux TP 2.5 et 3.3.

 Modifiez la grille de données en ajoutant une colonne Edit à partir du script suivant :

{ field: 'id_demande', title:'Edit', renderer:  
  function (value, record) {  
         return "<a href='<?php html::action_href('demandes', 'demande', 
'editdemande')?>-id-" + value + "'>Edit</a>";  
  }...

Énoncé 3.9 Pour aller plus loin : gérer un workflow

Durée estimative : 45 minutes

La liste des tâches est partagée entre tous les utilisateurs. Ce dernier TP ajoute un filtre sur l’affectation des demandes et donne la possibilité de réassigner une demande.

 Modifiez la méthode getlsitdemandes() dans DemandeDAO pour récupérer le nom de l’utilisateur associé à une demande (en plus de son identifiant). Il faut pour cela ajouter la propriété utilisateur_nom dans demandeEntity.

 Ajoutez la colonne utilisateur_nom à la grille de données.

 Ajoutez à la vue listedemandes une liste déroulante lstName. Chargez la liste des utilisateurs à l’aide d’un appel jQuery sur le service web utilisateur users-user-getuserlist. Le flux JSON retourné doit être parcouru en jQuery pour alimenter la liste.

 Ajoutez un bouton d’action pour appliquer le filtre. Utilisez l’événement click pour rafraîchir la liste :

$('#btnFiltre').on('click', function () { 
   grid.reload({ name: $('#lstName').val() }); 
}); 

 Ajoutez à l’action listdemandedata() un paramètre $name=null. Adaptez le code pour filtrer les enregistrements à la condition que $name soit non nul.

Vérifiez...

Énoncé 3.10 Finaliser la page de liste des demandes

Durée estimative : 15 minutes

Nous avions esquissé au premier TP la page « liste des demandes ». Il est temps de terminer cette réalisation en combinant la vue index et la vue listdemandes.

 Recopiez dans la vue listdemandes le contenu de la vue index.

 Modifiez le fichier menu.json pour appeler l’action listdemandes depuis le menu général.

 Ajoutez au bundle de script dans le fichier config.php la référence vers le script suivant :

https://unpkg.com/gijgo@1.9.13/js/messages/messages.fr-fr.js 

 Ajoutez à la grille de données la propriété locale: ’fr-fr’ pour activer les messages en français.

 Ajoutez dans l’action listdemandes() une propriété title à l’objet view_bag :

\FPLGlobal::$view_bag->title='Teamup - Demandes'; 

Adaptez dans le template de page _mainlayout.php le contenu de la balise <title> selon que la propriété view_bag->title est définie ou non.

 Testez le résultat.