Alexandre Rock Ancelelet PHP / Symfony trainer Follow me `@pierstoval` **(everywhere)**
Programme:
* Quelques rappels sur Symfony
* De Symfony 1 à Symfony 2
* La BC promise de Symfony 2.3
* De Symfony 2 à Symfony 3
* De Symfony 3 à l'avenir
* Flex & Symfony 4
* Framework PHP open-source
* Framework orienté HTTP
* Plus de 45 composants
* Licence MIT
* Entre 7 et 8% des entreprises dans le monde l'utilisent
* _Touche française_ 🥐
* PHP 5.2.4+
* Utilisation d'un contexte statique _(Singleton)_
* Plugins réutilisables _(mais assez fermés au reste de l'application)_
* Pas de gestion de dépendances _(Composer v1.0.0-alpha1 : Mars 2012, premier commit un an plus tôt)_
* Complexité parfois élevée _(formulaires, surcharge dans les plugins, etc.)_
* PHP 5.3.2+ (arrivée des namespaces & closures)
* Framework HTTP
* Remplacement du contexte par un DIC (Dependency Injection Container)
* "Plugins" deviennent "Bundles", beaucoup plus flexibles
* Simplification / réécriture d'une très grande partie du code de Symfony 1
* Gestion des dépendances avec des submodules `git` pour la v2.0
* Sortie de v2.1.0 en Septembre 2012 et intégration de Composer
* Commence à la v2.3.0 (Juin 2013)
* BC (Backward compatibility) = Rétrocompatibilité
* Rétrocompatibilité systématique suivant [Semver](http://semver.org/)
* Les interfaces et l'annotation `@api` définissent le contrat de rétrocompatibilité
* Migrations vers des versions ultérieures simplifiées
* Déprécations visible dans le profiler & les logs
* À partir de la v2.7.0 (Mai 2015), le PHPUnitBridge affiche lui aussi les déprécations
* PHP 5.5.9+ (générateurs, syntaxe `MyClass::class`)
* Suppression de TOUTES les déprécations de la v2
* Optimisation de fonctionnalités pour les composants **Console**, **DependencyInjection**, **Yaml**, **Form**, **Translator**, **VarDumper**, **Security**, pour les tests...
* Grosse mise à jour du composant **Form**
* Nouvelle architecture de dossiers
* Nouveautés issues de la v2.8:
* Nouveaux composants: **PropertyInfo**, **Guard**, **LDAP** et les différents **Polyfills**.
* Nouveau design du profiler, de la debug toolbar et de la console
* **MicroKernel** (pour utiliser Symfony comme micro-framework)
* **Autowiring**
* Nouveaux composants: **Cache** (avec [PSR-6](http://www.php-fig.org/psr/psr-6/)), **Workflow**
* **DateTimeNormalizer** et **DataUriNormalizer** pour le Serializer
* Amélioration du composant Yaml (nouvelles specs Yaml 1.2)
* Améliorations générales de plusieurs composants: **Security**, **Console**, **Yaml**, **Cache**, **Filesystem**, **HttpFoundation**...
* Support d'Unicode dans le routing
* Variables d'environnement dans la configuration (Yaml : `my_param: %env(MY_ENV_VAR)%`)
* Service locators * Service autoconfiguration * Persisted deprecation logs * **WebLink** component * **SecurityBundle** improvements * Redesigned exception pages * Faster routing * A simpler way to get the project root directory * Improved flash messages * **Workflow** improvements * Deprecated the special `SYMFONY__` env vars * `about` command * Better handling of command exceptions * `Lock` component
* Load config files with glob patterns * Deprecated cache clear with warmup * Simpler service configuration * `Kernel::build()` Method * Deprecated `X-Status-Code` * Deprecated the `ClassLoader` component * Manifest-based asset versioning * Asset preloading with HTTP/2 Push * XLIFF linter * Getter injection * Deprecated the autowiring types * Import config files with glob patterns * Custom YAML tags * PSR-11 containers
* Automatic `Console` logging * Simple Cache * `Dotenv` component * `Dependency Injection` deprecations * Memcached Cache Adapter * Search in dumped contents * Optional class for named services * WebServerBundle * Cookie improvements * Improved command descriptors * Added new shortcut methods * Improved the Profiler configuration panel * Support for form action & method attributes * JSON authentication
* Nouveaux composants : **DotEnv**, **Lock**, **WebLink**, **WebServerBundle**
* Authentification JSON
* Classe en tant qu'id de service
* Simple cache (avec [PSR-16](http://www.php-fig.org/psr/psr-16/))
* Assets preload & HTTP/2 Push
* Assets basés sur un "manifeste" JSON
* Paramètre `%kernel.project_dir%`
* Autoconfiguration de services
* PHP 7.1+ * 5.6 : args variadiques, const expr, `use function|const` * 7.0 : return types, scalar typehints * 7.1 : const visibility, nullables...
* Suppression de TOUTES les déprécations de la v3
* Intégration avec Flex
* Nouvelle architecture de dossiers
* L'édition Standard de Symfony ([`symfony/symfony-standard`](https://github.com/symfony/symfony-standard/)) sera (certainement) modifiée pour automatiquement utiliser Flex
1 | $ composer create-project symfony/standard-edition my_project |
1 | $ symfony new 3.2 my_project |
Situation : * Tout est installé par défaut (Monolog, Twig, Swiftmailer) * Pas de workflow frontend par défaut (avant, il y avait Assetic) * Installation de dépendances fastidieuse (documentation, copier/coller) * Appli web clé-en-main mais trop générique
Mot d'ordre: ## _Composition over inheritance_
* Un plugin Composer (`symfony/flex`)
* Lors d'un `composer require/remove`, Flex cherche une "recette"
* Si une recette existe sur le serveur de Symfony Flex, le plugin récupère son "manifeste"
* Flex exécute toutes les actions définies par le manifeste
* Bonus : S'il n'y a pas de recette mais que `"type": "symfony-bundle"` existe dans votre `composer.json`, celui-ci est ajouté au Kernel
* Bonus 2 : Symfony Flex va créer des alias comme `cli` pour `symfony/console` ou `orm` pour toute la suite Doctrine ORM
1 2 3 4 | $ composer create-project symfony/skeleton:3.3.x-dev demo
$ cd demo
$ composer req cli
$ composer req orm |
Sources: * https://github.com/symfony/skeleton * https://github.com/symfony/recipes/blob/master/symfony/console/3.3/manifest.json * https://github.com/symfony/recipes/blob/master/javiereguiluz/easyadmin-bundle/1.16/manifest.json * https://github.com/symfony/recipes/blob/master/symfony/orm-pack/2.4/manifest.json * https://packagist.org/packages/symfony/orm-pack
Deux projets où seront stockées les recettes avec leurs manifestes: * https://github.com/symfony/recipes * https://github.com/symfony/recipes-contrib Ces projets sont utilisés par le serveur de Symfony Flex pour récupérer toutes les informations utiles afin d'installer vos packages Composer associés à une recette.
* Gérées et déciées par l'équipe de Symfony * Les seules à pouvoir définir un "alias"
* Gérées et déciées par la communauté (un bot peut même valider & merge les PR !) * Pas d'alias possible * Nécessite un petit ajustement à votre projet: ``` composer config extra.symfony.allow-contrib true ```
`symfony/skeleton` utilisant Flex permet l'utilisation de la nouvelle structure:
./
├── .env
├── .env.dist
├── .gitignore
├── composer.json
├── composer.lock
├── etc
│ ├── packages
│ │ ├── dev/
│ │ │ └── framework.yaml
│ │ ├── prod
│ │ │ └── doctrine.yaml
│ │ ├── test
│ │ │ └── framework.yaml
│ │ ├── app.yaml
│ │ ├── doctrine.yaml
│ │ └── framework.yaml
├── Makefile
├── src
│ ├── Controller/
│ └── Kernel.php
├── var
│ ├── cache/
│ └── logs/
├── vendor
└── web
├── bundles/
└── index.php### Avantages et nouveautés : * Utilisation de **variables d'environnement** * Un **MicroKernel** au lieu d'un Kernel complet * Configuration chargée par des chemins "glob" * Plus de bundle par défaut, tout est dans `src/` * Config des dépendances dans `etc/packages/` * Un `Makefile` pour les commandes, Symfony ou autre * Un seul point d'entrée web: `index.php`
Flex encourage la création de "packs" sur Packagist.
Un Pack est juste un fichier `composer.json` avec des instructions `require`, rien de plus.
Exemple : https://packagist.org/packages/symfony/orm-pack
{
"name": "symfony/orm-pack",
"type": "metapackage",
"license": "MIT",
"description": "A pack for the Doctrine ORM",
"require": {
"php": "^7.0",
"doctrine/orm": "^2.4.5",
"doctrine/doctrine-bundle": "^1.6"
},
"extra": {
"branch-alias": {
"dev-master": "2.4.x-dev"
}
}
}Recette du DoctrineBundle : https://github.com/symfony/recipes/tree/master/doctrine/doctrine-bundle/1.6
Comme d'habitude avec Flex, si un package possède une recette, elle sera récupérée.
Grâce au package `symfony/orm-pack` et à sa recette, pour installer Doctrine ORM & toute la config nécessaire, il suffit d'exécuter cette commande :
1 | composer req orm |
Pour créer un projet Symfony, nous utilisons ce code avec Flex: #### `composer create-project symfony/skeleton my_project`
`symfony/skeleton` n'est rien d'autre qu'un **pack** qui a Flex pour dépendance.
Chaque dépendance de ce projet sera installée et vu que Flex est la première, celle-ci va automatiquement détecter les recettes de toutes les autres dépendances.
On peut ainsi imaginer tout un tas d'applications clé-en-main:
1 2 3 4 5 6 7 | composer create-project symfony/skeleton-cms
composer create-project symfony/skeleton-ecommerce
composer create-project symfony/skeleton-blog
composer create-project symfony/skeleton-microservice
composer create-project symfony/skeleton-cli
(ces packages n'existent pas, mais l'idée est là) |
Toujours ce même mot d'ordre : _**Composition over inheritance**_
On **compose** notre application en fonction de nos besoins.
On ne crée plus une application "prête-à-l'emploi" contenant parfois trop de composants.
Flex est compatible avec **tout package Composer**, pas seulement avec Symfony. On peut créer des recettes pour tout un tas d'autres projets !
Sauf Laravel 
Merci à tous. Questions?
@pierstoval