Symfony configuration. généralités La configuration de symfony est stockée dans des fichiers.yml...

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"

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é: valeurall:

.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

propel: blog_article: _attributes: { phpName: Article } id: title: varchar(255) content: longvarchar created_at: blog_comment: _attributes: { phpName:

Comment } id: article_id: author: varchar(255) content: longvarchar created_at:

config/schema.yml

config/database.yml

all: propel: class: sfPropelDatabase param: phptype: mysql host: localhost database: blog username: root password: encoding: utf8

blog

•« propel » dans nom de la connexion à la base de données

•Possibilité de connexion différentes par environnement

Syntaxe standard du schéma

propel: blog_article: _attributes: { phpName: Article } id: title: varchar(255) content: longvarchar created_at: blog_comment: _attributes: { phpName:

Comment } id: article_id: author: varchar(255) content: longvarchar created_at:

config/schema.yml

reconnu comme clé primaire auto-incrémentée

conditionne le nom de l’objet php associé. Si aucun nom d’origine version camelCase

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

updated_at ou created_at automatiquement définis comme times tamp

•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 default: https_metas: 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.ymlall:

version: 1.5

• Sera accessible comme suitecho 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 suitsfConfig::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'' ?>