Symfony configuration

généralités La configuration de symfony est stockée dans des fichiers .yml (YAML) par défaut Un fichier de configuration peut se trouver au niveau du projet de l’application ou du module Possibilité de centralisé un ensemble de configuration dans de des environnements Les valeurs définies dans les fichiers de configuration sont accessibles via PHP Le code PHP est possible dans les fichiers .yml

La configuration dans symfony Puissant : Presque tous les aspects pouvant être gérés par les fichiers de configurations le sont. Simple : Beaucoup d’aspect configurables ne sont pas mentionnés dans une application standard, puisqu’ils ont rarement besoin d’être changés. Facile : Les fichiers de configuration sont faciles à lire, à modifier, et à créer par le développeur. Personnalisable: Le langage de configuration par défaut est YAML, mais peut être INI, XML, ou n’importe quel langage que le développeur préfère. Rapide : Les fichiers de configurations ne sont jamais interprétés par l’application mais par le système de configuration, qui les compile en morceaux rapide d’exécution de code pour le serveur PHP.

YAML http://www.yaml.org/ sérialisation de données langage simplifié de description de données en XML Efficace pour les représentation de liste et tableaux associatifs … L’indentation (2 espaces -> gare aux tabulations!!) fait partie du langage! # pour le commentaire

YAML - string Chaîne de caractères non standard sont à entourer par des simples quotes error1: Ce champ est obligatoire error2: ' Ce champ est obligatoire ‘ error3: 'Don''t leave this field blank' error4: ‘error : Don''t leave this field blank' Chaîne de caractères multiligne (sans line break) accomplishment: > Mark set a major league home run record in 1998. Chaîne de caractères multiligne (avec line break) stats: | 65 Home Runs 0.278 Batting Average

YAML – tableau Syntaxe courte pour les tableaux players: [ Mark McGwire, Sammy Sosa, Ken Griffey ] Syntaxe étendue pour les tableaux players: - Mark McGwire - Sammy Sosa - Ken Griffey

YAML – tableau associatif Syntaxe courte pour les tableaux associatifs mail: { webmaster: webmaster@example.com, contact: contact@example.com } Syntaxe étendues pour les tableaux associatifs mail: webmaster: webmaster@example.com contact: contact@example.com Syntaxe courte incorrecte mail: {webmaster:webmaster@example.com,contact:contact@example.com}

Ce tableau PHP $house = array( 'family' => array( 'name' => 'Doe', 'parents' => array('John', 'Jane'), 'children' => array('Paul', 'Mark', 'Simone') ), 'address' => array( 'number' => 34, 'street' => 'Main Street', 'city' => 'Nowheretown', 'zipcode' => '12345‘ ) );

S’écrit en yaml house: family: name: Doe parents: - John - Jane children: - Paul - Mark - Simone address: number: 34 street: Main Street city: Nowheretown zipcode: "12345"

Ca vient en l’utilisant don’t panic!! Ou encore … house: family: { name: Doe, parents: [John, Jane], children: [Paul, Mark, Simone] } address: { number: 34, street: Main Street, city: Nowheretown, zipcode: "12345" } Les catégories permettent de regrouper des paires clé: valeur all: .general: tax: 19.6 Ca vient en l’utilisant don’t panic!!

Vue globale configuration d’un projet symfony config.php: premier fichier exécuté par une requête ou une commande. Il contient le chemin des fichiers du framework (perosnnalisable). databases.yml: les paramètres de connexion à la base de données (serveur, login, password, nom de la base, …). Ils peuvent être modifiés au niveau application. properties.ini: paramètres utilisés par l’outil en ligne de commande rsync_exclude.txt: spécifie les répertoires devant êtres exclus des synchronisations entre serveurs schema.yml & propel.ini: fichiers de configurations d’accès aux données utilisés par Propel (la couche ORM de symfony). schema.yml contient une représentation du modèle de données relationnel du projet. propel.ini est automatiquement généré

Schéma de BDD blog config/schema.yml config/database.yml propel: blog_article: _attributes: { phpName: Article } id: title: varchar(255) content: longvarchar created_at: blog_comment: _attributes: { phpName: Comment } article_id: author: varchar(255) config/database.yml all: propel: class: sfPropelDatabase param: phptype: mysql host: localhost database: blog username: root password: encoding: utf8 « propel » dans nom de la connexion à la base de données Possibilité de connexion différentes par environnement

Syntaxe standard du schéma config/schema.yml conditionne le nom de l’objet php associé. Si aucun nom d’origine version camelCase propel: blog_article: _attributes: { phpName: Article } id: title: varchar(255) content: longvarchar created_at: blog_comment: _attributes: { phpName: Comment } article_id: author: varchar(255) reconnu comme clé primaire auto-incrémentée updated_at ou created_at automatiquement définis comme times tamp colonnes finissant par _id considérées comme clés étrangères table correspondante déterminée par la première partie du nom de la colonne attribut type : boolean, integer, float, date, varchar(size), longvarchar, etc … autres attributs (par défaut, obligatoire, etc…) écrire ces attributs comme un ensemble de clé:valeur

La classe!! crééer les classes du modèle de la couche ORM symfony propel-build-model Classes de base générées dans lib/model/om/ BaseArticle.php BaseArticlePeer.php BaseComment.php BaseCommentPeer.php Classes réelles générées dans lib/model Article.php ArticlePeer.php Comment.php CommentPeer.php

More exciting than YAML DBDesigner Création de schéma de BDD en mode graphique Possibilité de convertir le schéma visuel en schema.yml  Application non maintenue, qui ne compile pas sous linux  http://www.strangebuzz.com/index.php/2008/09/08/36-new-symfony-11-plugin-tutorial-sfdb4topropelplugin http://mazenod.fr/blog/un-petit-batch-pour-symfony.html http://mazenod.fr/blog/commencer-un-projet-symfony.html http://mazenod.fr/blog/dbdesigner-out-of-memory.html http://mazenod.fr/blog/utiliser-dbdesigner-avec-l-i18n-de-symfony.html

Vue globale configuration d’une application symfony app.yml: variables globales définissant la logique applicative spécifique à une application, n’ayant pas besoin d’être stockées dans une base de données. Il est vide par défaut. config.php: démarre en incluant le fichier config.php du projet. factories.yml: permet d’utiliser le framework avec des classes personnalisées filters.yml: Les filtres sont des portions de code exécutés à chaque requête. Définitions de la séquence de filtres. Peut être modifié au niveau module logging.yml: définit le niveau de détails devant être enregistré dans les logs routing.yml: Les règles de routage, permettant de transformer les urls illisibles et « unbookmarkable » en de belles urls

Vue globale configuration d’une application settings.yml: paramètres principaux d’une application symfony, activation de l’internationalisation, langage par défaut, timeout d’une requête, le cache actif ... En changeant une seule ligne dans ce fichier, vous pouvez interrompre view.yml: structure de la vue par défaut (nom du layout, titre, tags meta, css & js par défaut …). Peut être modifié au niveau module i18n.yml: paramètres généraux de traduction, comme la culture par défaut pour les traductions, traductions fichiers ou base de données et leurs formats. i18n/: dictionnaires basiques, donnant une traduction pour chaque phrases. Utilisées dans le template de l’application de sorte que les pages affichent le texte traduit lorsque l’utilisateur change de langue.

Vue globale configuration d’une application Fichiers de conf du framework, redéfinissables autoload.yml: paramètres de la fonctionnalité d’auto chargement. constants.php: structure de fichier par défaut de l’application bootstrap_compile.yml: liste des classes à inclure lors du démarrage de l’application core_compile.yml: liste des classes à inclure pour traiter une requête Ces classes sont en fait concaténées dans un fichier PHP optimisé sans commentaires (accélère l’exécution) config_handlers.yml: permet d’ajouter ou de modifier les gestionnaires utilisés pour traiter chaque fichier de configuration php.yml: vérifie les variables du php.ini sont correctement définies et permet de les modifier, si nécessaire

Vue globale configuration d’un module generator.yml: pour les modules générés à partir de la table d’une base de données (scaffoldings and administrations), définit comment l’interface affiche les lignes et les champs, et quelles interactions sont proposées à l’utilisateur (filtres, ordonnancement, boutons, …) module.yml: contient des paramètres personnalisés spécifique à un module (équivalent à app. yml, mais au niveau d’un module) et aux actions. security.yml: définit la restriction d’accès aux actions. Permet de spécifier qu’une page peut être vue seulement par les utilisateurs enregistrés ou par un sous-ensemble d’utilisateur enregistrés avec des droits spéciaux. view.yml: contient la configuration pour les vues pour une ou toutes les actions du module. Il modifie le fichier view.yml de l’application Data validation files: situés dans le répertoire validate/ au lieu de config/, les fichiers YAML de validation de données, sont utilisés pour contrôler les données entrées dans les formulaire. Ils ont pour nom le nom de l’action

Les environnements – en bref partagent le même code PHP Peuvent avoir des configurations différentes symfony fournit trois environnements par défaut: Production (prod) http://localhost/app_prod.php/ ou http://localhost/app.php enregistre les erreurs test (test) http://localhost/app_test.php/ enregistre les alertes et les erreurs développement (dev) http://localhost/app_dev.php/ l’accélération du cache est désactivé La debug barre est activée

Conifguration des environnements # Production environment settings prod: ... # Development environment settings dev: ... # Test environment settings test: ... # Custom environment settings myenv: ... # Settings for all environments all: ...

Configuration en cascade La même configuration peut être définie plusieurs fois myapp/config/view.yml default: https_metas: content-type: text/html myapp/modules/rss/config/view.yml content-type: text/xml

Accéder à la configuration à partir du code PHP La classe sfConfig permet d’accéder à la configuration parameter = sfConfig::get('param_name', $default_value); sfConfig::set('param_name', $value); Apps/myapp/config/app.yml all: version: 1.5 Sera accessible comme suit echo sfConfig::get('app_version');

Accéder à la configuration à partir du code PHP II Certaines variables de configuration symfony sont accessible via PHP settings.yml all: .settings: available: on path_info_array: SERVER Accessibles comme suit sfConfig::set('sf_available’, false); sfConfig::get('sf_path_info_array’); N.B. : les catégories n’apparaissent pas dans le chemin de la variable

Accéder dynamiquement à la configuration dans le code PHP autoload.yml autoload: symfony: name: symfony path: %SF_SYMFONY_LIB_DIR% recursive: on exclude: [vendor] Pour une variable de app.yml %APP_LOCATION_OF_VARIABLE% ou <?php echo sfConfig::get(‘app_location_of_variable'). ''\n'' ?>