Présentation

Une route permet de diriger une url (ou un pattern d'url) vers une méthode de controller appelée Action.

La documentation officielle de Symfony sur les routes et La documentation officielle de Symfony sur les controllers

Il est possible de décrire des routes selon les formats de fichiers : XML, JSON, Classe PHP et en annotation. Pour plus de commodité nous utiliserons les annotations.

Structures d'une route

Une route peut être constante : /blog ou dynamique : /blog/{slug} Ici slug englobé de { } devient une variable dynamique qui prend tous les caractères alphanumériques par exemple : /blog/42 /blog/lorem-ipsum /blog/titi-32_tata Ces 3 urls correspondent à la méthode ciblée par la route avec une variable slug différente. Cette variable peut être récupérée par le controller.

/**
 * @Route("/blog/{slug}", name="article_blog")
 */
public function article($slug)
{
    ...
}

• Une route est au minimum un chemin (path) et un nom

• Ces variables peut être mise par défaut grâce à "defaults"

• Ces variables peuvent être soumises à une validation de format via "requirements"

/**
 * @Route("/{id}", name="index", requirements={"id"="\d+"}, defaults={"id"=1})
 */
public function index($id)
{
    ...
}

• On peut également préfixer l'url avec le mot clé "prefix"

• On peut définir un path différent en fonction de la locale

• Vous pouvez cumuler plusieurs routes pour une méthode Action

• On peut spécifier le moyen d'accès à une route (GET, POST, PUT, ...)

Annotations

Pour pouvoir utiliser une annotation il faut :

use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;

à ajouter après le namespace dans votre Controller.

Compléments sur les annotations

Routes et paramètres

On définit une variable d'url via des accolades {ma_variable} :

/**
* @Route("/page", defaults={"page": "nopage"}, name="blog_index")
* @Route("/page/{page}", name="blog_index")
*/
public function indexAction($page)
{
    echo $page;
}

Ici on a deux routes pour la méthode indexAction avec une variable $page qui est à nopage si on accède à l'url /page.

On peut cumuler plusieurs variables :

/**
* @Route("/page/{page}/{subpage}", name="blog_index")
*/
public function indexAction($page, $subpage)
{
    echo $page.' '.$subpage;
}

Génération d'url

Pour générer une url en PHP on utilise :

$this->generateurl('nom_de_la_route', $variables);

Ou sous TWIG on a deux fonctions :

{{ path('nom_route', {'page': 'toto', 'vars2': 'titi'} ) }}

{{ url('nom_route', {'page': 'toto', 'vars2': 'titi'} ) }}

Controller

Les routes redirigent vers une méthode de Controller (une action); un controller Symfony se nomme de la sorte : NomDuController où le suffixe Controller est obligatoire et le nom du fichier et de la classe est en CamelCase.

Les différentes méthodes se nomment de la sorte :

nomDeLaMethode est lui en miniCamelCase

L'usage du suffixe Action n'est plus requis dans Symfony.

Dans le cas idéal, le controller doit contenir le minimum de code possible (20 lignes maximum selon les standards de Symfony). Il ne doit que faire le lien entre les différents éléments de l'application et une réponse.

Response

Une Action renvoie toujours un type Response ; il existe plusieurs type de Response : JsonResponse, RedirectResponse, HttpResponse, BinaryFileResponse etc ...

La plus utilisée est Response pour l'utiliser on va ajouter dans le "use" suivant :

use Symfony\Component\HttpFoundation\Response;

et dans la méthode action on :

public function index(){
    return new Response('Ma response');
}

Affiche à l'écran Ma response. Dans l'état cette réponse n'est pas du HTML, car rien n'est précisé dans le retour de la méthode.

Une méthode render() (définie quand la classe AbstractController dont votre controller doit hériter) permet aux Actions de récupérer une vue et d'afficher le contenu de la vue compilée avec les différentes variables envoyées.

/**
 * @ Route("/", name="page")
 */
public function index() 
{
    // votre code

    return $this->render('default/index.html.twig', 
        ['variable' => $variable]
    );
}

Ici on va récupérer le template présent dans templates/default/index.html.twig pour affecter la variable variable.

Exercice 1

• Créer 2 nouvelles pages :

  • http://localhost/time/now : afficher la date l'heure minute et seconde

  • http://localhost/color/blue : affiche "blue" à l'écran dynamiquement

  • http://localhost/color/red : affiche "red" à l'écran dynamiquement

  • Ajouter un menu avec des liens vers les 2 pages créées.

Manipuler les requests

L'objet "request" contient toutes les données envoyées par l'utilisateur (formulaire, ...), mais aussi les données envoyées par le navigateur.

En passant en paramètre un objet de type Request, on peut le manipuler selon les méthodes ci-dessous.

Passer un objet en paramètre de cette manière est ce que l'on nomme de l'injection de dépendance. Le lien est fait automatiquement par Symfony grâce au mécanisme d'autowiring.

use Symfony\Component\HttpFoundation\Request;

public function index(Request $request)
{
    $request->isXmlHttpRequest(); // is it an Ajax request?

    $request->getPreferredLanguage(array('en', 'fr'));

    // retrieves GET and POST variables respectively
    $request->query->get('page');
    $request->request->get('page');

    // retrieves SERVER variables
    $request->server->get('HTTP_HOST');

    // retrieves an instance of UploadedFile identified by foo
    $request->files->get('foo');

    // retrieves a COOKIE value
    $request->cookies->get('PHPSESSID');

    // retrieves an HTTP request header, with normalized, lowercase keys
    $request->headers->get('host');
    $request->headers->get('content_type');
}

Exercice 2

Ajoutez une méthode (route, méthode et vue) qui permet de récupérer l'IP du client. On peut utiliser la méthode getClientIp() de l'objet request.

Symfony nécessite tout un environnement pour fonctionner. On a déjà vu Composer pour gérer les dépendances par exemple.

Symfony implique aussi différents "langages" et utilise un vocabulaire spécifique (souvent repris dans d'autres framewrok).

Composer

Composer est un logiciel gestionnaire de dépendances libre écrit en PHP. Il permet à ses utilisateurs de déclarer et d'installer les bibliothèques dont le projet principal a besoin. Le développement a débuté en avril 2011 et a donné lieu à une première version sortie le 1 mars 2012. Développé au début par Nils Adermann et Jordi Boggiano (qui continuent encore aujourd'hui à le maintenir).

Le logiciel Composer est fortement inspiré du logiciel npm pour Node.js.

ENTITÉ (EQ. DU MODÈLE)

Une entité est une classe PHP. Elle peut faire le lien avec une base de données, on y déclare les différentes propriétés accessibles; Symfony utilise par défaut un outil de persistence de données : Doctrine pour lier une entité à une table de base de données.

ORM : OBJECT RELATIONNAL MAPPING

Système permettant de se libérer des requêtes pour la base de données. Il se charge de générer les requêtes à effectuer sur les Entités spécifiées.

Repository

Classe PHP qui fait le pont entre une entité et l'ORM, il permet notamment de structurer des requêtes complexes.

YAML

Format de structuration de données très utilisé dans Symfony, mais on peut utiliser du JSON, XML ou des classes PHP, les fichiers de configurations par défaut sont en YAML.

ANNOTATION

Commentaire PHP directement dans les classes utiles (controller, entité) interprété par Symfony pour générer des fichiers de config temporaires; Nous utiliserons pour un soucis de simplification en majorité cette notation.

Routes

Les routes permettent de faire un lien entre une URL et un contrôleur.

Bundles

Sorte de modules Symfony qui peuvent contenir tout et n'importe quoi ; C'est la force de Symfony les modules peuvent fonctionner indépendamment et même sur d'autres structures PHP, autre framework etc.

Cette notion a disparu avec la V4 de Symfony, mais il reste possible d'installer des Bundles tiers.

ENVIRONNEMENTS

Symfony propose par défaut 2 environnements : dev et prod qui permettent de donner des configs différentes en fonction de l'environnement de travail ; dev permet une utilisation sans cache avec des outils de dev comme le profiler ; prod lui permet d'utiliser le site sous cache et sans aucun message d'erreurs. De plus on peut configurer les différentes environnements pour par exemple rediriger tous les mails vers toto@titi.com en dev et laisser le fonctionnement normal pour prod ; pratique pour les debugs.

Symfony propose également de définir autant d'environnement que nécessaire afin d'avoir différentes configurations. Le changement d'un environnement à un autre se faire en modifiant la ligne suivante dans le fichier ".env" :

   ###> symfony/framework-bundle ###
   APP_ENV=dev

Profiler

Le profiler est un outil puissant (et indispensable) pour débuger une application. Par défaut le profiler n'est pas installée. Pour l'ajouter il faut executer la commande suivante :

composer require profiler --dev

Le profiler est toujours visible en bas de la page en mode développement.

Pour créer une page dans Symfony, il faut, au minimum :

• Une route : pour faire le lien entre une URL et une méthode d'un contrôleur

• Un contrôleur : qui contient des méthodes, chacune, en générale, associée à une route

• Une méthode : permet l'execution d'une action précise, généralement en lien avec une route

Premier controller

// src/Controller/LuckyController.php
namespace App\Controller;
use Symfony\Component\HttpFoundation\Response;

class LuckyController
{
    public function number()
    {
        $number = mt_rand(0, 100);
        return new Response(
            'Lucky number: '.$number.''
        );
    }
}

Ce code est votre premier contrôleur (à déposer dans src/Controller). Ce contrôleur est composé d'une méthode qui calcul un nombre aléatoire et retourne une réponse qui est du code HTML. Ce code n'utilise pas directement les vues de Symfony, et ne fonctionne pas (en tout cas il n'est pas possible de l'appeler), car il n'est pas lié à une route.

Route

Il faut définir les routes. Il existe de nombreuses méthodes (yaml, xml, php, annotations) Pour information voici la syntaxe en YAML, à mettre dans le fichier routing.yaml.

# config/routes.yaml

# the "app_lucky_number" route name is not important yet
app_lucky_number:
    path: /lucky/number
    controller: App\Controller\LuckyController::number

Le site sera accessible à cette adresse (en exécutant le serveur local à Symfony) http://localhost:8000/lucky/number

Autre solution

Nous allons utiliser les annotations, qui permettent une syntaxe plus simple, et une proximité entre la définition de la route et la définition de la méthode. Pour cela, il faut installer les annotations à Symfony avec la commande suivante :

composer require annotations

Et modifier le contrôleur précédent en intégrant directement la route sous forme d'une annotation.

// src/Controller/LuckyController.php
namespace App\Controller;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class LuckyController
{
    /**
     * @Route("/lucky/number", name="app_lucky_number")
     */
    public function number()
    {
        $number = mt_rand(0, 100);
        return new Response(
            'Lucky number: '.$number.''
        );
    }
}

Ajout d'une vue

Cette solution fonctionne, mais écrire tout le code HTML dans la méthode n'est pas très pratique. Nous devons donc écrire des vues. Par défaut, Symfony utilise Twig. Pour cela, il faut l'installer

composer require twig

Il faut ensuite modifier le contrôleur pour utiliser les vues.

// src/Controller/LuckyController.php
namespace App\Controller;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

class LuckyController extends AbstractController
{
    /**
     * @Route("/lucky/number", name="app_lucky_number")
     */
    public function number()
    {
        $number = mt_rand(0, 100);
        return $this->render('lucky/number.html.twig', array(
            'number' => $number,
        ));
    }
}

Il faut maintenant écrire la vue.

{# templates/lucky/number.html.twig #}
<h1>Your lucky number is {{ number }}</h1>

Et Voilà !

L'ensemble de ce cours se base sur la version 4.1 de Symfony

Introduction

Dans Symfony la notion de modèle se retrouve sous la forme (entre autre) d'une Entité. Une entité est une classe PHP, qui peut être connectée à une table de votre base de données via l'ORM. Lorsqu'une entité est liée à une table, via l'ORM, il y a en général un fichier "repository" associé. Un repository permet la génération de requêtes simples ou complexes et dont le développeur peut modifier à volonté.

Un ORM (Object Relation Mapper) permet de gérer manipuler et de récupérer des tables de données de la même façon qu'un objet quelconque, donc en gardant le langage PHP. Plus besoin de requête MySQL, PostgresSQL ou autre.

Symfony utilise Doctrine comme ORM dans son système par défaut. Nous allons utiliser Doctrine mais vous pouvez utiliser d'autres systèmes si vous le souhaitez. Doctrine peut-être géré de plusieurs façon : XML, JSON, YAML, PHP et en Annotation nous allons utiliser ce dernier format de données.

Vous êtes libre d'écrire le code qui permet le traitement métiers en dehors des entités et d'avoir votre propre logique d'organisation.

Mise en application

Configuration

Comme à chaque fois, il est d'abord nécessaire d'installer les bundles nécessaires pour manipuler la base de données avec un ORM. Il vous faut donc exécuter la commande ci_dessous :

On va également installer, si vous ne l'avez pas encore fait, le bundle "maker" qui contient des outils pour générer du code sous Symfony grâce à la console.

Une fois ces deux éléments installés, il faut configurer la connexion à la base de données. Pour ce faire, il faut éditer le fichier .env à la racine de votre projet, qui doit normalement contenir une ligne d'exemple.

Création de la base de données

Une fois le fichier à jour avec vos données, vous pouvez créer votre base de données depuis la console.

Les modifications de structure de votre base de données devront être réalisées avec la console pour que Symfony puisse faire le lien entre les tables et l'ORM.

Création d'une entité liée à une table

Utilisez la commande make:entity (qui est dans le bundle maker) pour avoir une série de question vous permettant de créer votre entité avec l'utilisation de l'ORM Doctrine. Vous pouvez créer une nouvelle entité ou modifier (ajouter des champs) une entité déjà existante en saisissant son nom.

Vous allez devoir répondre à une suite de question avec le nom de l'entité (par défaut cela donnera le nom de la table), et les champs à créer. Dans Symfony une entité possède toujours un champs id, qui est la clé primaire et qui est auto-incrémenté. Vous ne devez donc pas l'ajouter dans la console.

Pour la création d'un champs, il vous faudra donner :

• son type

• sa taille le cas échéant

• si ce champs peut être null

• s'il doit être unique (index)

Vous pouvez obtenir la liste des types supportés en tapant "?" à la question du type.

Une fois terminé, le fichier d'Entité et le repository associé sont générés.

Exemple dans la console :

Et le code de l'entité généré dans src/Entity/Product.php :

A ce stade l'entité est créé, mais n'existe pas dans la base de données. Il reste deux étapes à exécuter.

La création d'un fichier de migration qui va contenir le code SQL a exécuter en fonction de votre SGBD.

La mise à jour de votre base de données en fonction du fichier précédemment généré.

Si vous consultez votre PHPMyAdmin vous verrez la table apparaître.

Modifications de champs et lien base de données

Pour modifier des champs vous pouvez éditer directement le code généré dans la partie annotation: nom (par défaut le nom de la variable), taille, type.

Pour ajouter des champs il vous faut relancer la commande make:entity en remettant le nom de votre entité.

Après chaque modification ou ajout il faut de nouveau générer le fichier de migration et mettre à jour la base de données. Vous pouvez bien sûr modifier ou créer plusieurs entités avant de faire une mise à jour de votre base de données.

ORM

Une fois la base de données mise en place on va pouvoir insérer, modifier, supprimer et récupérer des informations de la base de données sans saisir de requêtes via des méthodes en initialisant l'entité fraichement créée :

Il existe à la place de $em->persist, $em->remove($post); qui permettra de faire une suppression.

Ce dernier code effectue une création dans la base de données; pour une modification il suffit de modifier l'instanciation de l'entité de la sorte :

ici on récupère le repository de Post et on récupère l'id 1 ; tout le restant du code reste inchangé.

Recherche d'entité

Symfony et Doctrine proposes des requêtes prédéfinies, qui répondent aux usages les plus courant.

Si $em est le manager associé à une entité :

• $em->find( $id ); on récupère qu'un seul élément de l'entité avec l'id $id;

• $em->findAll(); on récupère toutes les entrées de l'entité concernée

• $em->findBy( $where, $order, $limit, $offset ); on recherche avec le tableau $where on tri avec le tableau $order on récupère $limit éléments à partir de l'élément $offset.

• $em->findOneBy($where,$order); on récupère le premier élément respectant le tableau $where et trié avec le tableau $order;

• $em->findByX($search); requêtes magiques où X correspond à n'importe quel champs défini dans votre entité

• $em->findOneByX($search) ; requêtes magiques où X correspond à n'importe quel champs défini dans votre entité

  Par exemple findBySlug('home'); ou findByTitle('Bonjour); génèrera des requêtes de recherche automatiquement. Pour les requêtes avec plusieurs éléments il faudra faire une itération (foreach) ou lister les différents éléments.

Exemple

Si aucune requête prédéfinie ne correspond à vos besoin, vous pouvez bien sûr en créer une en passant par le repository.

Vous pouvez également générer vos requêtes manuellement pour avoir une requête complexe et précise directement dans le controller mais idéalement il faudrait le placer dans le repository dédié.

Et l'utiliser dans votre controller

Exercice

• Créer une entité "Post" avec :

  • title string 255

  • dateCreated datetime

  • content text

  • enable boolean

• Créer une entité "PostCategory" avec :

  • title string 255

• Créer une page qui va sauvegarder une catégorie avec le nom "Catégorie 1".

• Créer une page qui va sauvegarder un post avec le nom Post 1 à la date courante avec comme contenu Lorem ipsum et en enable à true.

• Créer une page qui va afficher le titre de la catégorie en id 1 et le post en id 1.

• Créer un nouveau post identique au premier en changeant le titre.

• Créer une page qui affiche la totalité des entités Post.

• Créer une page qui récupère le Post avec le Titre "Post 1"

Generating Controllers To save time, you can install Symfony Maker and tell Symfony to generate a new controller class:

php bin/console make:controller BrandNewController

created: src/Controller/BrandNewController.php If you want to generate an entire CRUD from a Doctrine entity, use:

php bin/console make:crud Product

Introduction

Deux notions majeures interviennent dans la conception de sécurité de Symfony :

• Authentification : Qui êtes vous ? ; vous pouvez vous authentifier de plusieurs manières (HTTP authentification, certificat, formulaire de login, API, OAuth etc)

• Authorization : Avez vous accès à ? ; permet d'autoriser de faire telle ou telle action ou accéder à telle page sans forcément savoir qui vous êtes, utilisateur anonyme par exemple.

Pour fonctionner, il est nécessaire d'ajouter le composant security à votre symfony.

composer require symfony/security-bundle

La sécurité dans symfony implique plusieurs éléments :

• Le firewall: qui est la porte d'entrée pour le système d'authentification, on définit différents firewall (au minimum 1 seul) qui va permettre de mettre en place le bon système de connexion pour l'url spécifiée via un pattern.

• Le provider : qui permet au firewall d'interroger une collection d'utilisateurs/mot de passe ; C'est une sorte de base de tous les utilisateurs avec les mots de passe. Il existe deux type par défaut :

  • in memory : directement dans le fichier security.yml mais du coup les hash des mots de passes sont disponible dans un fichier

  • Entity : N'importe quelle entité qui implémente à minima Symfony\Component\Security\Core\User\UserInterface

  • Enfin, plusieurs providers peuvent fonctionner en même temps par exemple in_memory et entity voire plusieurs entités simultanément. http://symfony.com/doc/current/security/entity_provider.html

• Un encoder : qui permet de générer des hashs/d'encoder des mots de passe ; le plus connu étant MD5 mais vous pouvez utiliser d'autres encoders tels que : sha1, bcrypt ou plaintext (qui n'encode rien c'est le mot de passe en clair) http://symfony.com/doc/current/security/named_encoders.html

• Les rôles : qui permettent de définir le niveau d'accès des utilisateurs connectés (authentifiés) et de configurer le firewall en fonction de ces rôles. Les rôles peuvent être hierarchisées afin d'expliquer par exemple qu'un administrateur (ROLE_ADMIN par exemple) et avant tout un utilisateur (ROLE_USER).

Configuration

A partir de la version 4, et avec le composant "maker", la gestion de la sécurité a été grandement facilitée. Là où sur les précédentes versions (la 2 notamment), il était d'usage de passer par un bundle tierce (FOSUserBundle par exemple), aujourd'hui cela n'est plus nécessaire.

Créer sa classe User

Si vous ne disposez pas encore d'une classe permettant la gestion des utilisateurs, il est possible d'en créer une avec la consôle. Si vous disposez déjà d'une classe utilisateur (ou que vous souhaitez utiliser plusieurs entités, il faudra modifier votre code en implémentant l'interface UserInterface et en respectant les conventions imposées).

L'instruction ci-dessous permet de lancer la consôle pour créer la table User.

bin/console make:user

Symfony va vous poser plusieurs questions afin de configurer les éléments (le nom de l'entité, si vous utilisez doctrine, le champ correspondant au login, et l'encodage du password.

The name of the security user class (e.g. User) [User]:
 > 

 Do you want to store user data in the database (via Doctrine)? (yes/no) [yes]:
 > 

 Enter a property name that will be the unique "display" name for the user (e.g. email, username, uuid) [email]:
 > 

 Will this app need to hash/check user passwords? Choose No if passwords are not needed or will be checked/hashed by some other system (e.g. a single sign-on server).

 Does this app need to hash/check user passwords? (yes/no) [yes]:
 > 

 created: src/Entity/User.php
 created: src/Repository/UserRepository.php
 updated: src/Entity/User.php
 updated: config/packages/security.yaml


  Success! 


 Next Steps:
   - Review your new App\Entity\User class.
   - Use make:entity to add more fields to your User entity and then run make:migration.
   - Create a way to authenticate! See https://symfony.com/doc/current/security.html

Une fois cette commande executée vous avez un fichier d'entité de créé, un repository associé, et le fichier security.yaml (dans config) qui a été mis à jour.

Il faut ensuite mettre à jour votre base de données, avec les commandes suivantes:

bin/console make:migration
bin/console doctrine:migrations:migrate

Créer la partie connexion

Une nouvelle fois la console va nous permettre de dégrossir le travail et produire le contrôleur, le fichier de configuration et le formulaire de connexion.

bin/console make:auth

Pour le résultat ci-dessous.

 What style of authentication do you want? [Empty authenticator]:
  [0] Empty authenticator
  [1] Login form authenticator
 > 1

 The class name of the authenticator to create (e.g. AppCustomAuthenticator):
 > LoginAuthenticator

 Choose a name for the controller class (e.g. SecurityController) [SecurityController]:
 > 

 created: src/Security/LoginAuthenticator.php
 updated: config/packages/security.yaml
 created: src/Controller/SecurityController.php
 created: templates/security/login.html.twig


  Success! 


 Next:
 - Customize your new authenticator.
 - Finish the redirect "TODO" in the App\Security\LoginAuthenticator::onAuthenticationSuccess() method.
 - Review & adapt the login template: templates/security/login.html.twig.

Comme indiqué cette commande va créer plusieurs fichiers :

• src/Security/LoginAuthenticator.php : qui va contenir la logique de votre authentification. Que faire une fois l'authetification réussie, ou en cas d'échec. Comment récupérer les informations de l'utilisateur.

• src/Controller/SecurityController.php : qui va être le contrôleur gérant la partie sécurité et authentification. Par défaut la méthode login pour afficher le formulaire et traiter (avec l'aide de l'authenticator précédent), valider les données. C'est dans ce contraôleur que vous pouvez ajouter la déconnexion, l'enregistrement et le mot de passe perdu par exemple.

• templates/security/login.html.twig : la vue contenant le formulaire de connexion, que vous pouvez librement adapter.

• Mettre à jour le fichier security.yaml afin qu'il fasse le lien avec les différents éléments de sécurité.

Les étapes suivantes expliques ce qui a été créé.

L'encodage du mot de passe (encoders) :

Là aussi, tout est pré-confiuré, vous pouvez bien sûr adapter. L'encodage permet de définir le "format" de cryptage du mot de passe.

encoders:
   # use your user class name here
   App\Entity\User:
       # bcrypt or argon2i are recommended
       # argon2i is more secure, but requires PHP 7.2 or the Sodium extension
       algorithm: bcrypt
       cost: 12

Partie "User Provider" (providers) :

Le Provider permet d'assurer quelques tâches nécessaires pour la sécurité. Notamment le fait de récupérer le fait qu'un utilisateur soit connecté (lire la session par exemple), gérer le "se souvenir de moi", ... Cette partie est configurée par défaut dans le fichier security.yaml. Elle peut être suffisante dans de nombreux cas et notamment quand la gestion se fait par une entité.

providers:
    # used to reload user from session & other features (e.g. switch_user)
    app_user_provider:
        entity:
            class: App\Entity\User
            property: email

L'authentification et le firewall

C'est la partie essentielle du process de sécurisation. C'est lui qui permet de dire quand il faut vérifier et authentifier un utilisateur. Le firewall permet de déterminer pour un pattern d'url (une requête (request)), la méthode d'authentification à utiliser (une page de connexion, une clé d'API, une dépendance à un fournisseur OAuth, ...).

 firewalls:
     dev:
         pattern: ^/(_(profiler|wdt)|css|images|js)/
         security: false
     main:
         anonymous: true
         guard:
             authenticators:
                 - App\Security\LoginAuthenticator

L'exemple ci-dessus permet de définir que pour les routes particulières (les assets, le profiler), il n'y a pas de vérification. Pour toutes les autres routes (main), les "anonymes" sont autorisées (c'est à dire les personnes non authentifiées).

Symfony propose des exemples pour de nombreuses méthodes d'authentification (login, ldap, json, ...) que vous trouverez sur la documentation officielle

La gestion des rôles et les autorisations

La gestion des roles se fait dans la partie "access_control" du fichier security. Il permet de définir pour chaque pattern d'URL quel rôle peut y accèder.

Exemple:

access_control:
  # require ROLE_ADMIN for /admin*
  - { path: ^/admin, roles: ROLE_ADMIN }

ou

access_control:
  # matches /admin/users/*
  - { path: ^/admin/users, roles: ROLE_SUPER_ADMIN }

  # matches /admin/* except for anything matching the above rule
  - { path: ^/admin, roles: ROLE_ADMIN }

De cette manière les URL seront automatiquement bloquées si l'utilisateur ne dispose pas du bon rôle. Il est aussi possible de tester ce rôle directement dans un contrôleur ou dans une vue selon les besoins. Voir la documentation pour plus d'éléments sur ce point

Récupérer l'utilisateur connecté

Enfin, il est souvent nécessaire de récupérer les informations sur l'utilisateur connecté. Pour cela, dans un contrô leur il est possible d'utiliser directement l'instruction :

$user = $this->getUser();

Gérer la déconnexion

Sur la même idée que pour la connexion, il est possible de gérer la déconnexion. Pour cela, dans le fichier security.yaml, il faut définir le path (la route) pour la méthode qui gére la déconnexion, et la cible (une route, optionnelle), une fois la déconnexion réussie.

firewalls:
     main:
         # ...
         logout:
             path:   app_logout
             # where to redirect after logout
             # target: app_any_route

La méthode dans le contrôleur peut se résumer à :

/**
 * @Route("/deconnexion", name="app_logout")
 */
public function logout(): void
{
}

Cette méthode qui ne retourne rien, permet la déconnexion, et la redirection se fait via le target définit dans security.yaml.

Exercice

Mettre en place une classe User, et créer le formulaire de connexion en suivant la documentation. Filtrer la partie création de catégorie uniquement à des utilisateurs ayant le rôle ROLE_ADMIN.

Présentation

Un template ou une vue est le meilleur moyen d'organiser et de restituer le code HTML à partir de votre application, que vous deviez rendre le code HTML à partir d'un contrôleur ou générer le contenu d'un courrier électronique . Les templates dans Symfony sont créés avec Twig: un moteur de modèle flexible, rapide et sécurisé.

Twig est un moteur de rendu de template comme Smarty ou Blade (laravel). Twig a cependant été développé pour Symfony à l'origine et peut être utilisé dans d'autres contextes.

La documentation officielle de Symfony sur les vues et TWIG et La documentation officielle de TWIG

Exemple d'une vue avec twig

Exemple d'un code que vous pourriez écrire en PHP

<body>
    <h1><?php echo $page_title ?></h1>
    <ul id="navigation">
        <?php foreach ($navigation as $item): ?>
        <li>
                <a href="<?php echo $item->getHref() ?>">
                    <?php echo $item->getCaption() ?>
                </a>
            </li>
        <?php endforeach ?>
    </ul>
</body>

Ce même code, écrit avec TWIG serait :

<body>
    <h1>{{ page_title }}</h1>

    <ul id="navigation">
        {% for item in navigation %}
            <li><a href="{{ item.href }}">{{ item.caption }}</a></li>
        {% endfor %}
    </ul>
</body>

La syntaxe est plus "legére" et moins encombrées des balises PHP. Le code semble donc plus lisible et par conséquent plus facile à maintenir.

Affichage

La syntaxe Twig est basée sur uniquement trois constructions:

• {{ ... }}, utilisé pour afficher le contenu d'une variable ou le résultat de l'évaluation d'une expression;

• {% ... %}, utilisé pour exécuter une logique, telle qu’une condition ou une boucle;

• {# ... #}, utilisé pour ajouter des commentaires au modèle (contrairement aux commentaires HTML, ces commentaires ne sont pas inclus dans la page rendue).

Variables

TWIG est très puissant lorsqu'il s'agit de manipuler des variables. Pour lui, si c'est un tableau associatif ou un objet avec des propriétés cela est identique dans la syntaxe.

Par exemple si vous avez le tableau $tab['param1'] vous écrirez en TWIG

{{tab.param1}}

Si vous avez un objet $tab, qui est une instance d'une classe ayant comme propriété $param1, la syntaxe en TWIG sera :

{{tab.param1}}

Si vous avez un objet $tab, qui est une instance d'une classe ayant comme propriété $param1, qui est un tableau associatif avec une clé key1, la syntaxe pourrait être :

{{tab.param1.key1}}

La manière dont TWIG inspecte votre code pour trouver la meilleure façon d'interpréter une variable est la suivante :

For convenience's sake foo.bar does the following things on the PHP layer:

• check if foo is an array and bar a valid element;

• if not, and if foo is an object, check that bar is a valid property;

• if not, and if foo is an object, check that bar is a valid method (even if bar is the constructor - use __construct() instead);

• if not, and if foo is an object, check that getBar is a valid method;

• if not, and if foo is an object, check that isBar is a valid method;

• if not, and if foo is an object, check that hasBar is a valid method;

• if not, return a null value.

foo['bar'] on the other hand only works with PHP arrays:

• check if foo is an array and bar a valid element;

• if not, return a null value.

Logique

• {% %} permet d'utiliser des logiques tels que :

  • {% if %} {% else %} {%endif %} : condition

  • {% for item in items %}{%endfor} : foreach

  • {% set foo='foo' %} : set des variables

Tests

Il est possible d'écrire des tests, la syntaxe est très proche de celle de PHP. Attention toutefois, les opérateurs de comparaison ne s'écrive pas de manière identique.

Le && de PHP s'écrit "and" dans TWIG, et le || de PHP s'écrit "or" dans TWIG.

Il est possible d'avoir des elseif (autant que nécessaire) et un bloc else (1 au maximum)

{% if condition %}

{% elseif condition %}

{% else %}

{% endif %}

Boucles

Il n'existe que la boucle for dans TWIG (elle est un peu l'équivalent d'un foreach).

Le code ci-dessous est une boucle qui varie de 1 à 10.

{% for i in 1..10 %}

{% endfor %}

La boucle ci-dessous est une boucle qui parcours une "collection" users (l'équivalent du foreach). Attention la syntaxe est inversée par rapport au PHP

<ul>
    {% for user in users %}
        <li>{{ user.username }}</li>
    {% endfor %}
</ul>

Dans le cadre d'une boucle TWIG propose une variable nommée loop qui permet d'avoir des informations sur la boucle :

La boucle ci-dessous intègre un test. Ce qui simplifie l'écriture. Elle intègre également un else dans le cas ou la boucle ne ferait aucune itération. Il est possible d'utiliser le else sans le if et réciproquement.

<ul>
    {% for user in users if user.active %}
        <li>{{ user.username }}</li>
    {% else %}
        <li>No users found</li>
    {% endfor %}
</ul>

Le code ci-dessus serait équivalent en PHP au code suivant:

<?php
if (count(users) > 0) {
    foreach ($users as $user) {
        if ($user->active) {
            echo '<li>'.$user->username.'</li>';
        }
    }
}
else {
    echo '<li>No users found</li>';
}

Héritage

TWIG permet l'héritage de template via un extends dans les templates enfants :

{% extends 'base.html.twig' %}

Dans les templates mère on définit des "block" que l'on vient surcharger dans les templates enfants :

{% block body %}
toto
{% endblock %}

On peut également reprendre le block parent via

{{ parent() }}

On crée donc des templates mère assez flexibles pour pouvoir en hériter et surcharger les différents blocks

Exercice 1

• Utiliser l'héritage pour mettre le menu dans un seul fichier mais visible sur les 2 pages.

• Intégrer bootstrap (CDN)

• Pour la page /color afficher le mot de la même couleur dynamiquement ("bleu" en bleu) (en CSS)

• Pour la couleur rouge afficher en plus le Message : "Attention risque de virus" en rouge

• Dans le menu rajouter un lien vers les pages couleurs : red, blue, yellow, pink, violet, salmon en utilisant un foreach

• Mettre en souligné l'url active

Inclusions

De la même manière que l'on peut hériter d'un template de base, on peut aussi inclure des "morceaux" de template dans une vue. Toujours dans la perspective de ne jamais multiplier un morceau de code identique dans plusieurs fichiers.

Filtres

Il est possible d'appliquer des filtres sur les variables pour effectuer des transformations : Majuscules, minuscules, dates, ...

{{ variable|upper }}

Vous trouverez la liste des filtres sur l'adresse : Liste des filtres de TWIG

Il est possible de cumuler les filtres. Mais il faut faire attention à l'ordre dans lequel on les appliques. Il est aussi possible de créer ses propres filtres.

Assets

TWIG propose de gérer facilement les URL de vos images, fichiers CSS ou encore javascript.

Pour cela vous aurez besoin d'ajouter le bundle suivant :

composer require symfony/asset

Ensuite, vous pouvez écrire dans TWIG

<img src="{{ asset('images/logo.png') }}" alt="Symfony!" />

<link href="{{ asset('css/blog.css') }}" rel="stylesheet" />

Par défaut, vos "assets" doivent se trouver dans le répertoire public de Symfony.

Depuis la version 3.4 et 4, Symfony propose de gérer les assets avec WebPack-Encore, qui est une adaptation de Webpack pour Symfony Vous trouverez les éléments sur WebPack-Encore ici : https://symfony.com/doc/current/frontend.html

Exercice 2

• Modifiez le code précédemment écrit pour manipuler des assets directement dans votre projet. Vous intégrer une image de votre choix et Bootstrap en version locale (supprimer toutes les dépendances aux CDN).

Présentation

Découvrir et appréhender un framework PHP web.

Pré-requis

• PHP

• Programmation Orientée Objet

• Structure MVC

• Base de données

Organisation

• 20 heures de TD

• 12 heures de TP

• Notes :

  • 1 évaluation écrite (dernier TD)

  • 1 note pratique (lors du dernier TP)

Rappels des concepts du MVC

C: Controller / Contrôleur

C'est lui qui reçoit l'interaction (la demande/request) du visiteur. Il se charge de récupérer les éléments nécessaires auprès du/des modèle(s). Il transmets toutes les données nécessaires à la vue.

V: View / Vue

C'est lui qui apporte la réponse (response/render) au visiteur. Une vue peut être une page web, un fichier pdf, ... Ne se préoccupe que de l'affiche des informations, n'assure aucun traitement

M: Model / Modèle

C'est lui qui s'occupe de récupérer et préparer les données. Le modèle peut être en lien avec une base de données. Le modèle peut être en lien avec des API. Le modèle prépare les données pour qu'elles soient facilement manipulables par la vue.

Notion de Framework

Définition générale

En programmation informatique, un framework ou structure logicielle est un ensemble cohérent de composants logiciels structurels, qui sert à créer les fondations ainsi que les grandes lignes de tout ou d’une partie d’un logiciel (architecture). Un framework se distingue d’une simple bibliothèque logicielle principalement par :

• son caractère générique,

• faiblement spécialisé,

• contrairement à certaines bibliothèques ;

Un framework peut à ce titre être constitué de plusieurs bibliothèques chacune spécialisée dans un domaine. Un framework peut néanmoins être spécialisé, sur un langage particulier, une plateforme spécifique, un domaine particulier : reporting, mapping, etc. ;

Le cadre de travail (traduction littérale de l’anglais : framework) qu’il impose de par sa construction même, guidant l’architecture logicielle voire conduisant le développeur à respecter certains patterns (modèle de conception) ; les bibliothèques le constituant sont alors organisées selon le même paradigme.

Framework Orienté Objet

Un framework dit orienté objet est typiquement composé de classes mères qui seront dérivées et étendues par héritage en fonction des besoins spécifiques à chaque logiciel qui utilise le framework.

Le développeur qui utilise le framework pourra personnaliser les éléments principaux du framework par extension, en utilisant le mécanisme d’héritage : créer des nouvelles classes qui contiennent toutes les fonctionnalités que met en place le framework, et en plus ses fonctionnalités propres, créées par le développeur en fonction des besoins spécifiques à son application.

Article comparatifs des 10 frameworks PHP les plus populaires de 2019: https://coderseye.com/best-php-frameworks-for-web-developers/

Symfony

• Framework MVC en PHP 5 (V2) et PHP 7 (V3 et V4), libre

• Développé en 2005 par la société Sensio pour répondre à ses besoins

• Division de la société Sensio en deux entités l’agence Web et l’entreprise qui soutient et maintient Symfony : SensioLabs, dirigée par Fabien Potencier, l’auteur de Symfony

• Framework français !, De renommée mondiale

• Premier framework en France et en Europe

SYMFONY : AVANTAGES

• Connectable à presque tous les SGBD

• De nombreux Bundles, contributeurs, utilisateurs

• Moteur de template puissant et simple

• Depuis la V4, Symfony est très léger et très rapide

Symfony V4 : Un retour aux bases

Avec sa version 4 (et suivante), Symfony à pris un virage important par rapport aux précédentes versions, et se rapproche des "standards" de la majorité des framework, mais à aussi grandement optimisé son poids et sa vitesse d'exécution. Dans une grande logique de simplification Symfony à également automatisé de nombreux mécanismes qui auparavant auraient impliqués de nombreuses lignes de configuration.

SKELETON ET FLEX

La version Skeleton de Symfony : Apporte un framework Symfony très léger, avec le minimum pour faire fonctionner un controller.

La version 4 de Symfony introduit Flex qui est un gestionnaire de "recipes" (recettes), qui permet l'ajout de fonctionnalité à Symfony (gestionnaire de vue, de base de données, d'email, ...) avec un mécanisme d'auto-configuration de ces "bundles". Cela permet donc de fournir par défaut un framework très léger, avec une grande facilité pour lui ajouter tous les composants nécessaires, sans en mettre plus que nécessaire.

Par défaut Symfony version Skeleton ne sais rien faire ! Par contre, il n'embarque pas des dizaines de Bundles dont vous n'aurez peut être jamais besoin (fonctionnement des versions 2 et 3 avec plus de 46 bundles par défaut, contre 10 aujourd'hui).

Grâce à Flex vous installez rapidement le nécessaire pour répondre à votre projet.

Installations

Configuration requise pour votre serveur

• Un serveur Web

• PHP 7.2 ou supérieur

• Git (différent de GitHub)

• Le gestionnaire de dépendance Composer (pour exécuter FLEX)

• Une maîtrise de son système d'exploitation ! (fichiers cachés, variables PATH, php.ini, console...)

Exercice 1 : Installation des outils

• Installer un serveur local (si ce n'est pas déjà fait)

• Installer Git

• Installer Composer

• Pour les utilisateurs de Windows : Installer une vraie console ! https://cmder.net/ par exemple.

• Installer un vraie IDE ! (PhpStorm / NetBeans, ou éventuellement VSCode).

Pensez à vérifier que tout fonctionne correctement :

php -v
composer -v
git -v

Vous devez vous afficher les numéros de version. Corrigez les messages d'erreurs éventuels.

Exercice 2 : Installation de Symfony.

Symfony propose deux versions :

• La version skeleton, la plus minimaliste et légère, qui n'installe que le stricte minimum, vous laissant ainsi la liberté d'ajouter les composants dont vous avez réellement besoin.

• Le version website-skeleton, qui va installer tout le nécessaire pour faire fonctionner un site (vues, annotations, base de données, ...)

On va privilégier la version skeleton.

Placez-vous dans le répertoire où vous souhaitez installer Symfony (www, public_html, ...) et exécutez la commande suivante (cela va créer un répertoire du nom de votre projet).

composer create-project symfony/skeleton nomDuProjet

Par défaut cette commande récupère la dernière version stable de Symfony. Le téléchargement peut prendre quelques minutes.

Il est possible de tester immédiatement le bon fonctionnement de l'installation en utilisant la ligne de commande en php suivante :

cd nomDuProjet
php -S 127.0.0.1:8000 public/index.php

Si vous vous rendez sur l'URL http://127.0.0.1:8000 vous devriez voir la page d'accueil de Symfony avec le numéro de la version installée.

Il est également possible d'installer un serveur embarqué avec Symfony. Cela peut servir pour des tests rapides. Pour cela il faut installer ce serveur (la version skeleton ne contenant que le strict minimum)

cd nomDuProjet
composer require symfony/web-server-bundle --dev

Et l'exécuter :

 php bin/console server:run

Et vous trouverez par défaut, votre site à l'URL : http://localhost:8000/

Présentation

Réaliser un forum, en utilisant Symfony. Votre forum devra intégrer les fonctionnalités suivantes :

• Inscription, connexion, déconnexion

• Création de message dans les catégories du forum

• Possibilité de répondre à un message

• Une recherche simple

• Liste des catégories, sous catégories, et messages associés

• Administration : Création des catégories et sous-catégories, administration des messages

• Il y aura 2 niveaux d'accès : Administrateur, membre (possibilité de créer un message ou de modifier ses messages)

• Un message pourra intégrer des fichiers (images a minima)

Vous êtes libre de la structure, de la mise en page et des données de votre base de données, mais vous devez répondre à la commande d'un forum

Notation

L'esthétique du forum n'est pas prise en compte. L'usage d'une librairie CSS ou d'un template est suffisant.

Par contre, vous veillerez à l'ergonomie et à la lisibilité.

Le respect des consignes peut vous apporter jusque 15 points.

Les 5 points supplémentaires seront acquis en fonction des ajouts (pertinents) que vous ferez, soit pour proposer des fonctionnalités pertinentes, soit dans la qualité de la navigation et de l'accessibilité.

TP

Le sujet pourra évoluer en fonction de l'avancement du cours

Pour cette première séance vous devrez mettre en place les éléments suivants :

Première étape

• Une nouvelle installation de Symfony (4.3 minimum)

• Mettre en place les controllers et les vues nécessaires à la navigation "publique" du site

  • Les vues seront des prototypes, n'hésitez pas à mettre des données fictives pour les remplacer ensuite par les données issues de la base de données.

  • Ces données pourraient venir du controller de manière fictive.

• Intégrer un template ou une librairie CSS et faire un minimum de mise en page

• Réfléchir au MCD que vous aller mettre en place.

Deuxième partie

• Mettre en place la base de données, les tables et les relations.

• Intégrer des données fictives et modifier vos controllers pour alimenter vos vues avec ces données

• Intégrer les formulaires et la gestion des messages sur la partie publique.

Troisième partie

• Mettre en place l'administration et les accès sécurisés.

• Mettre en place les CRUD pour le back-office.

Présentation

Réaliser un outil de dépôt de travaux étudiants, en utilisant Symfony. L'outil devra intégrer les fonctionnalités suivantes :

• Inscription, connexion, déconnexion pour les étudiants

• Création de rubriques (par un administrateur)

• Possibilité de déposer un travail (vidéo, photo, ...), avec titre, description

• Une recherche simple

• Liste des catégories, et travaux associés

• Administration : Création des catégories administration des utilisateurs et des dépôts

• Il y aura 2 niveaux d'accès : Administrateur, étudiants (possibilité de déposer un travail ou de le modifier)

• Les travaux comporteront des fichiers et/ou des liens

• Possibilité de "noter" un travail (système de like par exemple). Affichage d'un top 3 par catégories.

Vous êtes libre de la structure, de la mise en page et des données de votre base de données, mais vous devez répondre à la commande

Notation

L'esthétique du forum n'est pas prise en compte. L'usage d'une librairie CSS ou d'un template est suffisant.

Par contre, vous veillerez à l'ergonomie et à la lisibilité.

Le respect des consignes peut vous apporter jusque 15 points.

Les 5 points supplémentaires seront acquis en fonction des ajouts (pertinents) que vous ferez, soit pour proposer des fonctionnalités pertinentes, soit dans la qualité de la navigation et de l'accessibilité.

La mise en production d'un projet avec Symfony est simple, mais implique de suivre les différentes étapes.

Mise en production avec un FTP

Pour effectuer une mise en ligne de votre projet avec un logiciel FTP, il faut télécharger sur le serveur les fichiers ou répertoires suivants.

• bin/

• config/

• public/ (normalement sans les fichiers uploadés, les fichiers générés, ...)

• src/

• templates/

• .env

• composer.json

• composer.lock

• symfony.lock

Pour une mise à jour d'un produit existant, l'upload de src/ et templates/ peut suffire, selon ce que vous avez modifié sur votre projet.

Il vous faut ensuite exécuter les différentes opérations de mise en ligne de la partie

Mise en production avec Git

Première mise en ligne

Pour une première mise en ligne vous pouvez faire un clone de votre dépôt.

Cette commande va créer un nouveau répertoire et copier les fichiers de votre dépôt sur votre serveur.

Mise à jour d'un projet existant

Pour mettre à jour un projet déjà existant sur votre serveur, et géré avec Git, vous devez executer la commande suivante

Où master est la branche qui contient la version de votre projet que vous souhaitez installer.

Opération à réaliser après la mise en ligne des fichiers

1) Configurer vos variables d'environnement

Si vous n'avez qu'un fichier .env, vous devez le mettre à jour avec les informations de votre serveur de production (base de données, éventuellement serveur de mail, ...).

C'est également dans ce fichier d'environnement que vous devez définir que votre projet est en production et plus en développement :

En production Symfony utilise un système de cache, n'affiche plus le profiler ou les messages d'erreur, mais utilise les pages 404, 500 que vous avez définies.

Les erreurs peuvent être sauvegardées dans des fichiers de log, selon votre configuration.

Toutes les configuration se trouvant dans config/packages/dev sont ignorées et celles se trouvant dans config/packages/prod sont utilisées.

Le répertoire vendor n'est jamais installé ou téléchargé, quelque soit la méthode que vous utilisez. Il faut donc soit le créer (une première installation), soit le mettre à jour (si vous avez ajouté des bundles ou que vous souhaitez obtenir la dernière version des bundles que vous utilisez)

L'information "--no-dev" permet de ne pas installer les bundles qui ne servent qu'en développement (make, profiler, ...). Si vous souhaitez être en développement sur ce serveur, vous devez retirer cette instruction.

En production Syfmony utilise un système de cache très performant. Mais cela peut empêcher de voir vos dernières modifications. Il faut donc s'assurer de nettoyer le cache de Symfony.

La commande suivante permet de supprimer le cache :

4) Mettre à jour votre base de données

Si vous avez ajouté des éléments dans vos entités, vous devez mettre à jour votre base de données. Pour cela vous pouvez executer la commande suivante :

Symfony dispose d'une large communauté très active qui contribue à développer des "bundles" afin de venir enrichir le framework avec des fonctionnalités récurrentes : Back office, gestion d'upload, ...

Il existe un site regroupant les bundles (ou pour les versions précédentes de Symfony ).

Parmis quelques bundles intéressants on peut citer :

• EasyAdminBundle (bundle reconnu par Symfony pour la génération automatique de backoffice)

• SonataAdminBundle

• StofDoctrineExtensionsBundle, qui permet d'enrichir Doctrine (gestion de date created/updated, de traduction, d'upload, ...)

• KnpSnappyBundle, pour la génération de PDF à partir de WKHtmlToPdf

et beaucoup d'autres pour la sérialization, l'authentification, la génération de pagination, ...

Installation

Avec Symfony 4 l'installation d'un Bundle est devenue très simple (notamment si le bundle dispose d'une recette recipe pour l'utilsisation optimale de flex).

Liste des recipes officielles pour Flex et Symfony , et le dépôt des recipes "non-officielles"

Il suffit, en général, d'installer le bundle avec Composer pour que ce dernier installe et configure les éléments.

Cas de VichUploadBundle

Ce bundle permet la gestion de l'upload en lien avec Doctrine.

Avec la version 4, Symfony à grandement simplifié la structure de ses répertoires et à normalisé les appelations pour coïncider avec la pratique de la majorité des framexork.

Symfony à également abandonné la notion de Bundle, qui était nécessaire pour développer son projet.

Architecture globale

• bin/ : contient la console

• config/ : contient les configurations des différents bundles, les routes, la sécurité et les services

• public/ : c'est le répertoire public et accessible du site. Contient le contrôleur frontal "index.php" et les "assets" (css, js, images, ...)

• src/ : contient votre projet (M et C du MVC)

• templates/ : contient les vues (V du MVC)

  var/ : contient les logs, le cache

  vendor/ : contient les sources de bundles tiers et de Symfony

Configuration

Vous remarques des fichiers au format yaml, le format par défaut pour la configuration de Symfony. Vous pouvez aussi remarquer les répertoires dev, prod et test. Ces répertoires permettent de facilement différencier une configuration pour un environnement de développement, pour le site en ligne, ou encore pour un contexte de test.

Par exemple, lorsque l'on développe, on ne souhaite pas réellement envoyer les mails aux usagers, par contre, on souhaite les visualiser. On peut donc configurer ce comportement dans le répertoire dev, pour le bundle de gestion des emails. Un autre exemple est la gestion des logs. En dev, on ne souhaite pas les conserver, mais les afficher, en production, on ne souhaite surtout pas les afficher, mais les stocker dans des fichiers.

Le concept est donc de définir le comportement global quelque soit l'environnement dans le fichier à la racine de config/packages, et de spécifier un comportement en fonction de l'environnement dans les répertoire dev, prod ou test.

Src

Dans ce répertoire se trouve toute la logique de l'application, les contrôleurs, les modèles, nos classes spécifiques, les services, ...

• Controller/ : Tous les contrôleurs de l'application, accessibles par des routes

• Entity/ : Les classes spécifiques pour la gestion de l'application, des données et des API

• Migrations/ : Contient les fichiers permettant la mise à jour de la base de données pour chaque modification effectuée sur la structure.

• Repository/ : Est très généralement lié à une entité, et permet d'ajouter des requêtes spécifiques.

Tous ces points seront détaillées dans les parties suivantes.

Introduction

Il est fréquent que les entités soient liées entre-elles. Et nous avons la notion de clé étrangère qui peut apparaître dans nos tables. Il est possible (voire nécessaire) de gérer cela avec Doctrine.

Pour ce faire, il va falloir expliquer à Doctrine, les liens qui existent entre nos entités. Et Doctrine, se chargera de créer les clés étrangères où cela est nécessaire.

Relations

Il existe les relations suivantes dans doctrine :

• OneToMany (et son inverse ManyToOne)

• ManyToMany

• OneToOne

Il existe également une notion très importante dans ces relations : propriétaire et inverse.

Propriétaire et inverse

Dans une relation entre deux entités, il y a toujours une entité dite propriétaire, et une dite inverse. L'entité propriétaire est celle qui contient la référence à l'autre entité.

Prenons un exemple simple, les commentaires de nos annonces. En SQL pur, vous disposez de la tablecomment et de la tableadvert. Pour créer une relation entre ces deux tables, vous allez mettre naturellement une colonne advert_id dans la tablecomment. La tablecomment est donc propriétaire de la relation, car c'est elle qui contient la colonne de liaison advert_id.

Unidirectionnelle ou bidirectionnelle

Enfin, une relation peut être unidirectionnelle ou bidirectionnelle. Les relations bidirectionnelles peuvent être gérées automatiquement par Symfony modifiant un peu les entités inverses avec inversedBy et mappedBy.

Dans le cas d'une relation bidirectionnelle, il faut aussi explicité la relation dans l'entité inverse. La relation bidirectionnelle permet de faciliter la recherche d'élement en partant de l'inverse (Article vers Commentaires).

RELATION 1..N (ONETOMANY) ET N..1 (MANYTOONE)

La relation 1..n définit une dépendance multiple entre 2 entités de sorte que la première peut être liée à plusieurs entités

Prenons l'exemple des étudiants et des absences. Un étudiant peut avoir plusieurs (many) absences, mais une absence n'est associée qu'a un (one) seul étudiant.

Cette relation peut donc se résumer à : plusieurs (many) absences pour un (one) étudiant, ou de manière équivalent un (one) étudiant pour plusieurs (many) absences.

On se place prioritairement du coté du Many, et on doit écrire la relation ManyToOne. Elle est obligatoire pour définir la relation précédente.

Le code précédent est le minimum pour définir une relation.

On dit dans ce cas que Absence est propriétaire de la relation (toujours du coté du Many).

La relation décrite précédemment est unidirectionnelle. Pour la rendre bidirectionnelle il faut décrire la relation dans l'entité etudiant (avec la relation inverse OneToMany).

Le code de Etudiant devient

Le code de etudiant sera :

La relation OneToMany n'est pas obligatoire. Elle permet juste d'inverser la relation, et de rendre la manipulation plus simple.

Dans ce cas, on fait apparaître un tableau contenant toutes les objets associés à cette relation (many).

Relation 1..1 (OneToOne)

La relation 1..1 est peu utilisée mais permet une flexibilité en terme relationnelle très importante. Elle définit une dépendance unique entre 2 entités :

Utilisateur -> Adresse Produit -> Image Commande -> Facture

Relation N..N (ManyToMany)

Le fonctionnement est assez similaire à une relation ManyToOne/OneToMany, sauf que cette relation est forcément bidirectionnelle. Il faut décrire le comportement dans les deux entités et choisir, selon la logique désirée, qui sera la relation propriétaire (inversedBy) de la relation inverse (mappedBy).

Cette relation va créer une nouvelle table, contenant les deux clés étrangères.

Manipulation de la console

La console (make:entity), nous facilite la création des relations. En créant ou en modifiant l'entité, il est possible d'ajouter le champs contenant la relation. Pour cela le type sera "relation". La console vous demandera de préciser l'entité liée, ainsi que le type de relation. Vous pourrez ensuite selon la relation choisie) préciser la relation inverse, de manière optionnelle ou obligatoire.

Attention, il est d'usage de lancer la console dans l'entité qui porte la relation (propriétaire), ou l'entité qui recevra la clé étrangère.

Comme après chaque modification, il faudra générer le fichier de migration, et appliquer les modifications sur la base de données.

Exercice

• Créer la liaison entre Post et Catégorie.

• Modifier la page de génération de Post pour créer un article "Post 3" avec la relation vers "Catégorie 1"

  • La catégorie de Post 3 sera Catégorie 1.

• Modifier la page avec tous les posts pour afficher la catégorie liée à l'article.

• Créer une page qui supprime "Post 1"

• Essayer d'utiliser les flash messages.

FORM

Introduction

La gestion des formulaire se fait via plusieurs classes PHP qui permettent entre autre :

• La structure et les propriétés du formulaire se gèrent via FormBuilder et peuvent être réutilisées;

• On peut créer des classes spécifiques pour chacun de nos formulaires

• Permet une gestion des validations simplifiée et une sécurité renforcée

• Permet d'hydrater une entité ou un objet rapidement

• Gestion de template simple

Pour pouvoir utiliser les formulaires, selon la version d'installation de Symfony, il peut être nécessaire d'installer les packages :

Pour les exemples ci-dessous, on considère l'entité suivante (exemple issue de la documentation Symfony) :

Création

On peut créer un Form de 2 façons différentes :

Directement dans un controller

Cette première solution est rapide à mettre en place, et ne nécessite pas de fichier supplémentaire. Cependant, le formulaire ainsi créé n'est pas réutilisation dans d'autres méthodes.

Ou via des classes dédiées de type FormType en général dans le répertoire Form

Cette seconde solution, qui implique des fichiers complémentaires, permet une plus grande souplesse et une meilleure ré-utilisation dans d'autres contextes.

Le fichier ci-dessous permet de créer le même formulaire.

On utilise la classe FormBuilder accessible avec la méthode

dans un contrôleur ; l'argument $task est l'entité que vous souhaitez hydrater; l'argument n'est pas obligatoire (pour un formulaire de recherche par exemple)

On peut mettre des champs de formulaire par défaut en modifiant l'entité avant de créer le formulaire et de lier le formulaire à l'entité :

Par exemple

Pré-remplira le formulaire avec Ma tâche pré-définie.

Ensuite nous aurons des suites de ->add('nom_du_champs', TypeDeChamps::class, $options);

Par défaut si vous ne mettez que le nom du champs Symfony se chargera de récupérer un type de champs en fonction du type de champs (string, text, boolean, date, ...)

Dans une classe dédiée le createFormBuilder est déjà instancié il ne vous reste qu'à rajouter les différents add.

TWIG

Une fois le formulaire créé et initié il faut renvoyer le tout à TWIG via la méthode :

Soit par exemple

Ensuite nous aurons plusieurs fonctions twig utiles:

• {{ form }} permet d'afficher tout le formulaire

• {{ form_start }} permet de générer la balise <form> avec les différents attributs

• {{ form_end }} permet de générer la fermeture de <form> avec les différents champs restants non affichés

• {{ form_errors }} affiche les erreurs éventuelles du formulaire

• {{ form_widget(mon formulaire.nomduchamps) }} affiche le type de champs

• {{ form_label(mon formulaire.nomduchamps) }} affiche le label du champs

• {{ form_row(monformulaire.nomduchamps) }} affiche le form_widget et form_label

• {{ form_rest }} affiche les champs restants non récupéré précédemment (token de vérification par exemple)

Ces fonctions permettent une grande maîtrise de la mise en forme d'un formulaire. Cependant, elle implique de détailler les éléments.

Il est donc possible d'afficher un formulaire en une seule ligne, et le rendu dépendra du paramètrage (ou du template modèle) existant.

la variable_form correspond à la variable contenant le formulaire envoyée par le contrôleur. Il est enfin possible de préciser un "thème" pour votre formulaire avec la syntaxe :

Le template est un fichier twig qui vient préciser et définir pour chaque élément du formulaire (de manière globale), le rendu en HTML.

Action / Request

Une fois le formulaire créé et affiche via TWIG il faut rajouter un comportement qui va gérer la soumission du formulaire grâce à ces méthodes :

• handleRequest($request) permet d'associer les valeurs input à la classe Form précédemment créé

• isSubmitted() permet de savoir si le formulaire a été envoyé

• isValid() permet de savoir si les données saisies sont valides

Dans la majorité des cas on va tester si :

Validation

Ces contraintes ou assert peuvent être gérée de plusieurs façon XML, JSON, YAML, PHP ou en annotation dans notre cas; il faudra utiliser cette ligne tout en haut du contrôleur :

Pour ensuite pouvoir utiliser l'annotation :

Ici on vérifiera que le champs name doit être rempli.

Exercice

• Créer un formulaire directement dans DefaultController qui gèrera la création des Post

• Créer un formulaire directement dans DefaultController qui gèrera la modification des Post

• Modifier la page de listing des postes pour rajouter un lien edition et suppression

• Mettre en place les différentes routes pour le backoffice de Post (ajout / modification / suppression / visualisation)

• Déporter le formulaire de gestion de Post vers une classe dédiée Form/PostType.php

• Modifier DefaultController pour utiliser PostType

• Ajouter une validation au formulaire sur le titre qui ne doit pas dépasser 255 caractères

• Rechercher pour mettre en place le template bootstrap pour les Form

• Afficher le message d'erreur en rouge.

Génération de CRUD

Ce que nous venons de faire manuellement peut être généré en ligne de commande par Symfony via la commande :

On vous demandera le nom de l'entité précédé du nom de bundle, le chemin pour ce crud et si vous souhaitez avoir les fonction d'édition (ajout/ modification) mettez oui.

On peut également générer seulement les FormType :

Attention si vous modifier une entité les FormType ne sont pas générés automatiquement il faudra rajouter manuellement le champs fraichement créé.

Exercice

• Générer le CRUD de Post avec l'url /admin/post

• Générer le CRUD de PostCategory avec l'url /admin/postcategory

• Tester le fonctionnement

• Mettre les liens dans le menu pour aller sur le listing post et listing postcategory; mettre en actif si url courante

Exercice

• On va créer une page de recherche

• Modifier le repository de Post pour créer une méthode search($word)

  qui recherchera dans le titre et le contenu le mot $word
• Créer une nouvelle page dans le Controller /search/{word}

• Créer le formulaire directement dans le controller sans le lier à une entité

• A la soumission on va récupérer $form->getData() qui sera notre $_POST

• Pour récupérer la variable $word et utiliser la méthode du repository fraichement créée.

• Pour finalement afficher tout le contenu dans une page de listing.

Composer global sur MacOS

That's a tough question but thankfully, our team is on it. Please bear with us while we're investigating.

Have you had a chance to answer the previous question?

Yes, after a few months we finally found the answer. Sadly, Mike is on vacations right now so I'm afraid we are not able to provide the answer at this point.

Fetching Services

Symfony comes packed with a lot of useful objects, called services. These are used for rendering templates, sending emails, querying the database and any other "work" you can think of.

If you need a service in a controller, type-hint an argument with its class (or interface) name. Symfony will automatically pass you the service you need:

1 2 3 4 5 6 7 8 9 10 11

• Awesome!