1. PHP
2. de symfony 1 à Symfony2
3. Gestionnaire de paquet PHP
4. Micro Framework
5. Silex
6. Symfony 2
7. Quelques paquets utiles

• il reste votre langage quelque soit le framework utilisé
• il a 20 ans cette année (PHP5 a déjà 10 ans)
• il a un vrai modèle objet, évolué
• il vous permet d'industrialiser vos développements
• il n'a pas à rougir face à Java ou .Net
• il est vraiment adapté pour les applications web

• namespaces
  
• late static bindings
  
• fonction anonyme (closure)
  

• Traits
  
• SAPI : cli-server

• generators
  
• finally
  

• variadics
  
• phpdbg, le debugueur interactif
  

• de 2005 à 2006 : beta
  
• 2007 : la v1

• Autoloading
• Code less : shell is your friend (dump assets, cache...)
  
• More configuration : yml / xml
  
• Component and Bundles : on ne doit rien faire en dehors de ces concepts (enfin presque)
  

• Annotations (Doctrine/Annotations)
• Inversion of Control (via injection de dépendance)
• Aspect oriented programation (JMS-AOP Bundle)
• Et beaucoup d'autres choses...

• Les composants  permettent de packager des modules applicatifs
• Les bundles se chargent notamment des controllers, donc fort couplage SF2
• Les services permettent de partager une logique métier pour la rendre disponible dans l'ensemble de votre application
  

• PHP pure
  
• Peut avoir besoin d'autres composants
  
• Logique métier
  
• Normalement pas d'affichage : mais peut générer du html (pas de echo en interne, ce serait une erreur de conception)
  
• Pas d'adhérence au framework
• Ré-utilisable

• Conteneur des Controllers, Command, ...
  
• Défini des Services
• A souvent besoin de composants ou de services
  
• Indépendant de l'application globale => ré-utilisable dans Symfony2
  

• Pattern d'injection de dépendance (cf. Pimple)
• Auto instanciation des objets
• Disponibilité universelle dans vos controllers
  

• Composer : gestionnaire de paquet
  
• Packagist : dépôt centralisé public
  
• Satis : dépôt central privé
  

• Json
  
• décrit un projet
• défini ses dépendances (version de php, module php, composants)
• Application
• résous l'arbre de dépendance
• télécharge les projets
• génère l'autoloader

 {
    "name": "moi/monexemple",
    "license": "MIT",
    "type": "component",
    "description": "Exemple de fichier composer",
    "autoload": {
        "psr-0": { "Moi\\MonExemple": "" }
    },
    "require": {
        "php": ">=5.3.3",
        "guzzle/guzzle": "4.0"
    },
    "require-dev": {
        "atoum/atoum": "~1"
    }
}

• Composer install : 
• lit le composer.lock
• install les composants
• Composer update : 
• lit le composer.json
• résoud les dépendances
• télécharge les dépendances
• génère le composer.lock

• PSR0 : fait correspondre un namespace à un path physique 
  
• PSR4 : permet de supprimer le lien au path physique et de réduire la profondeur de l'arborescence
  

• GIT: Gestionnaire de version de fichier
  
• Github: Dépôt distant de projet git (mode privé payant)
  
• Gitlab: Projet open-source de dépôt git

• Dépôt central par défaut de Composer
  
• Packagist.org pour chercher des projets
  

• Packagist : repository par défaut, et public
  
• Vous avez des composants métiers, donc privé
  
• Packagist ou Github peuvent tomber, vous serez bloqué
  

{
    "require": {
        "silex/silex": "~1.2"
    },
    "minimum-stability": "dev"
}

• app
• bin
• src
• vendor
• web
• composer.*

• Kernel
• Config
• Logs
• Resources (layout)
• Console
• Check

• doctrine
• security checker

• librairies
• bundles
• composants

• les assets (via php console assets:dump)
  
• le front controller via :
  
• app.php (default, optional)
• app_yourEnv.php

• PHP >=5.3.3
• exécutable php dans son PATH
• Composer disponible (c'est plus pratique)
• Git

• symfony/framework-standard-edition
  
• symfony-cmf/standard-edition
  
• gimler/symfony-rest-edition

• Pré-requis : avoir un serveur Web opérationnel
  
• Définir : sf2.local.dev comme domaine de l'appli
  
• Installation : via composer  
  

php composer.phar create-project symfony/framework-standard-edition alg_sf 2.6

php app/check.php

• dev
  
• test
  
• prod
  
• ...

• le choix du front controller détermine l'environnement
  
• app.php, app_dev.php, app_test.php
• AppKernel défini les bundles chargé par environnement
  
• cf. AppKernel.php et registerContainerConfiguration()
• les éléments de configuration se font par environnement
• config_dev.php, routing_dev.php

• front controller : app_dev.php
  
• routage : demo/hello/toto
  
• controller : DemoController + HelloAction
• template : hello.html.twig
  
  = un bundle : AcmeBundle

• Controller
  
• Resources
  
• Command
  
• DependancyInjection
  
• EventListener
  
• Form
  
• Twig
  
• ...
  

• appartiennent à un Bundle
  
• points d'entrée de votre application
  
• ne devraient pas avoir de code métier
• contiennent des "action" regroupées par fonctionnalités
• doivent construire la Response

• éviter la dépendance entre les classes
  
• automatiser l'instanciation d'objets
  
• mettre à disposition des fonctionnalités métiers
  
• rendre votre code testable

• gestion des assets
  
• cache
  
• liste des services
  
• table de routage
  
• scafolding
  
• ...

1. création en cmd
   
2. création de la route
3. paramètres des urls
4. accès aux services
   

php app/console generate:bundle 

ALG/DemoBundle

puis modifier le routing.yml pour changer le prefix : /alg

videz votre cache ;-)

    "require": {
        "php": ">=5.4.0",
        "rebolon/pager-bundle": "dev-master"
    } 

php app/console container:debug 

• on part d'un composant existant
  
• on le rend disponible via un bundle 

• Logs
  
• Web Debug profiler
  

• Une debug bar en bas de page
  
• Résumé d'informations pour la page
• mémoire
• temps d'éxécution
• version de php
• ...
• Un profiler : http://host/app_dev.php/_profiler
  

• unitaires (PHPUnit par défaut, Atoum envisageable)
  
• fonctionnels (Behat)
  

• au niveau application
  
• au niveau des bundles
  

• config.yml
  
• config_[env].yml
  
• parameters.yml

• syntaxe YAML
  
• possibilité d'inclure d'autres fichiers via "imports"
  
• peut utiliser des paramètres via %nomDuParametre%
  

• /app/config/routing.yml
  
• /app/config/routing_[env].yml

class DemoController extends Controller
{
    /**
     * @Route("/{name}", name="_demo", requirements={"id" = "*"}, defaults={"name" = "world"})
     * @Method({"GET", "POST"})
     */
    public function indexAction($name)
    {
        ....

• EventDispatcher
  
• StopWatch
  
• Process
  
• Finder
  
• Console
• Form

$process = new Process('ls -lsa');
$process->setTimeout(3600);
$process->run();
if (!$process->isSuccessful()) {
    throw new \RuntimeException($process->getErrorOutput());
}

print $process->getOutput();

$finder = new Finder();
$finder->files()->in('src/Symfony/*/*/Resources')
    ->name('smiley*')->size('< 100K')->date('since 1 hour ago');

foreach ($finder->files() as $file) {
    print $file->getFilename()."\n"; // SplFileInfo $file
}

// vous avez besoin d'une classeclass MyShellCommand extends Command

// et de 2 méthodes
protected function configure() // pour setter les parametres, et le help
protected function execute(InputInterface $input, OutputInterface $output)

• Créez vos entités
  
• Créez le builder createFormBuilder proposé par la classe Controller
• Définissez vos types avec le builder : add('property', 'typeField')
• Générez la vue via la méthode createView de votre formBuilder
• Reliez votre formulaire à la saisie utilisateur via bind du formBuilder
• Validez la saisie avec la méthode isValid du formBuilder