日本Symfonyユーザー会

Le fichier de configuration factories.yml

Les factories sont des objets du noyau nécessaires pour le framework au cours de la vie de toutes les requêtes. Ils sont configurés dans le fichier de configuration factories.yml et toujours accessible via l'objet sfContext :

// Récupère le factory de l'utilisateur
sfContext::getInstance()->getUser();

Le fichier principal de configuration factories.yml pour une application se trouve dans le répertoire apps/APP_NAME/config/.

Comme indiqué dans l'introduction, le fichier factories.yml est sensible à l'environnement, bénéficie du mécanisme de configuration en cascade et peut inclure des constantes.

Le fichier de configuration factories.yml contient une liste de factory nommés :

---
FACTORY_1:
  # definition de factory 1

FACTORY_2:
  # definition de factory 2

# ...

Les noms de factory supportés sont : controller, logger, i18n, request, response, routing, storage, user, view_cache, et view_cache_manager.

Lorsque le sfContext initialise les factories, il lit le fichier factories.yml pour le nom de la classe du factory (class) et les paramètres (param) utilisés pour configurer l'objet factory :

---
FACTORY_NAME:
  class: CLASS_NAME
  param: { ARRAY OF PARAMETERS }

Être en mesure de personnaliser les factories signifie que vous pouvez utiliser une classe personnalisée pour les objets du noyau de symfony à la place de celui par défaut. Vous pouvez également modifier le comportement par défaut de ces classes en personnalisant les paramètres qui lui sont envoyés.

Si la classe du factory ne peut pas être chargées automatiquement, un chemin du fichier peut être défini et sera automatiquement inclus avant la création du factory :

---
FACTORY_NAME:
  class: CLASS_NAME
  file:  ABSOLUTE_PATH_TO_FILE

Le fichier de configuration factories.yml est mis en cache dans un fichier PHP. Le processus est automatiquement géré par la classe ~sfFactoryConfigHandler~.

Factories

mailer
request
response
user
storage
view_cache_manager
- cache_key_use_vary_headers
- cache_key_use_host_name
view_cache
i18n
routing
logger
- level
- loggers
controller

`mailer`

Accesseur de sfContext : $context->getMailer()

Configuration par défaut :

---
mailer:
  class: sfMailer
  param:
    logging:           %SF_LOGGING_ENABLED%
    charset:           %SF_CHARSET%
    delivery_strategy: realtime
    transport:
      class: Swift_SmtpTransport
      param:
        host:       localhost
        port:       25
        encryption:
        username:
        password:

Configuration par défaut pour l'environnement test :

---
mailer:
  param:
    delivery_strategy: none

Configuration par défaut pour l'environnement dev :

---
mailer:
  param:
    delivery_strategy: none

~`charset`~

L'option charset définit le jeu de caractères à utiliser pour les messages électroniques. Par défaut, il utilise le paramètre charset de settings.yml.

~`delivery_strategy`~

L'option delivery_strategy définit comment les messages e-mail sont livrés par le mailer. Quatre stratégies sont disponibles par défaut, ce qui devrait convenir à tous les besoins communs :

realtime : Les messages sont envoyés en temps réel.
single_address : Les messages sont envoyés à une seule adresse.
spool : Les messages sont stockés dans une file d'attente.
none : Les messages sont tout simplement ignorés.

~`delivery_address`~

L'option delivery_address définit le bénéficiaire de tous les messages lorsque le delivery_strategy est à single_address.

~`spool_class`~

L'option spool_class définit la classe de spool à utiliser lorsque le delivery_strategy est à spool :

~Swift_FileSpool~ : Les messages sont stockés sur le système de fichiers.
~Swift_DoctrineSpool~ : Les messages sont stockés dans un modèle de Doctrine.
~Swift_PropelSpool~ : Les messages sont stockés dans un modèle de Propel.

Lorsque le spool est instancié, l'option ~spool_arguments~ est utilisée comme les arguments du constructeur.

~`spool_arguments`~

L'option spool_arguments définit les arguments du constructeur du spool. Voici les options disponibles pour les classes intégrées des files d'attente :

Swift_FileSpool :
- Le chemin absolu du répertoire de file d'attente (les messages sont stockés dans ce répertoire)
Swift_DoctrineSpool :
- Le modéle de Doctrine à utiliser pour stocker les messages (MailMessage par défaut)
- Le nom de la colonne à utiliser pour le stockage de messages (message par défaut)
- La méthode à appeler pour récupérer les messages à envoyer (facultatif).
Swift_PropelSpool :
- Le modèle de Propel à utiliser pour stocker les messages (MailMessage par défaut)
- Le nom de la colonne à utiliser pour le stockage de messages (message par défaut)
- La méthode à appeler pour récupérer les messages à envoyer (facultatif). Il reçoit le Criteria courant comme un argument.

La configuration ci-dessous montre une configuration typique pour un spool de Doctrine :

---
# configuration in factories.yml
mailer:
  class: sfMailer
  param:
    delivery_strategy: spool
    spool_class:       Swift_DoctrineSpool
    spool_arguments:   [ MailMessage, message, getSpooledMessages ]

~`transport`~

L'option transport définit le transport à utiliser pour envoyer effectivement des messages électroniques.

Le paramètre class peut être n'importe quelle classe qui implémente Swift_Transport, et trois sont fournis par défaut :

~Swift_SmtpTransport~ : Utilise un serveur SMTP pour envoyer des messages.
~Swift_SendmailTransport~ : Utilise sendmail pour envoyer des messages.
~Swift_MailTransport~ : Utilise la fonction native PHP mail() pour envoyer des messages.
~Swift_NullTransport~: Désactive complètement le transport (utile avec la stratégie none pour contourner la connexion au serveur de messagerie).

Vous pouvez configurer le transport en définissant le paramètre param. La section "Transport Types" de la documentation officielle de Swift Mailer décrit tout ce que vous devez savoir sur les classes intégrées dans les transports et leurs différents paramètres.

`request`

Accesseur de sfContext : $context->getRequest()

Configuration par défaut :

---
request:
  class: sfWebRequest
  param:
    logging:           %SF_LOGGING_ENABLED%
    path_info_array:   SERVER
    path_info_key:     PATH_INFO
    relative_url_root:
    formats:
      txt:  text/plain
      js:   [application/javascript, application/x-javascript, text/javascript]
      css:  text/css
      json: [application/json, application/x-json]
      xml:  [text/xml, application/xml, application/x-xml]
      rdf:  application/rdf+xml
      atom: application/atom+xml

~`path_info_array`~

L'option path_info_array définit le tableau global PHP qui sera utilisée pour récupérer des informations. Sur certaines configurations, vous voudrez changer la valeur par défaut SERVER par ENV.

~`path_info_key`~

L'option path_info_key définit la clé sous laquelle l'information PATH_INFO peut être trouvée.

Si vous utilisez ~IIS~ avec un module de réécriture comme IIFR ou ISAPI, vous devez changer cette valeur par HTTP_X_REWRITE_URL.

~`formats`~

L'option formats définit un tableau des extensions de fichiers et leur Content-Type correspondant. Il est utilisé par le framework pour gérer automatiquement le Content-Type de la réponse, basée sur l'extension de l'URI de la requête.

~`relative_url_root`~

L'option relative_url_root d2finit la partie de l'URL avant que le contrôleur frontal. La plupart du temps, il est automatiquement détecté par le framework et n'a pas besoin d'être changée.

`response`

Accesseur de sfContext : $context->getResponse()

Configuration par défaut :

---
response:
  class: sfWebResponse
  param:
    logging:           %SF_LOGGING_ENABLED%
    charset:           %SF_CHARSET%
    send_http_headers: true

Configuration par défaut pour l'environnement test :

---
response:
  class: sfWebResponse
  param:
    send_http_headers: false

~`send_http_headers`~

L'option send_http_headers spécifie si la réponse devrait envoyer des entêtes de réponse HTTP ainsi que le contenu des réponses. Ce réglage est surtout utile pour les tests, les entêtes sont envoyées avec la fonction PHP header() qui envoie des avertissements si vous essayez d'envoyer des entêtes, après des sorties.

~`charset`~

L'option charset définit le jeu de caractères à utiliser pour la réponse. Par défaut, il utilise le paramètre charset de settings.yml, qui est ce que vous voulez la plupart du temps.

~`http_protocol`~

L'option http_protocol définit la version du protocole HTTP à utiliser pour la réponse. Par défaut, il vérifie la valeur de $_SERVER['SERVER_PROTOCOL'] si elle est disponible ou par défaut à HTTP/1.0.

`user`

Accesseur de sfContext : $context->getUser()

Configuration par défaut :

---
user:
  class: myUser
  param:
    timeout:         1800
    logging:         %SF_LOGGING_ENABLED%
    use_flash:       true
    default_culture: %SF_DEFAULT_CULTURE%

Par défaut, la classe myUser hérite de sfBasicSecurityUser, qui peut être configurée dans le fichier de configuration security.yml.

~`timeout`~

L'option timeout définit le timeout pour l'authentification des utilisateurs. Il n'est pas lié au timeout de la session. Le réglage par défaut dés-authentifie automatiquement un utilisateur au bout de 30 minutes d'inactivité.

Ce paramètre n'est utilisé que par les classes d'utilisateurs qui héritent de la classe de base sfBasicSecurityUser, ce qui est le cas de la classe générée myUser.

Pour éviter un comportement inattendu, la classe utilisateur force automatiquement la durée de vie maximale pour le ramasse-miettes de session (session.gc_maxlifetime) à une valeur plus grande que le timeout.

~`use_flash`~

L'option use_flash active ou désactive le composant flash.

~`default_culture`~

L'option default_culture définit la culture à utiliser par défaut pour un utilisateur qui arrive sur le site pour la première fois. Par défaut, il utilise le paramètre default_culture de settings.yml, qui est votre choix la plupart du temps.

Si vous changer le paramètre ~default_culture~ dans factories.yml ou dans settings.yml, vous devez effacer les cookies dans votre navigateur pour vérifier le résultat.

`storage`

Le factory storage est utilisé par le factory user pour maintenir les données utilisateur entre les requêtes HTTP.

Accesseur de sfContext : $context->getStorage()

Configuration par défaut :

---
storage:
  class: sfSessionStorage
  param:
    session_name: symfony

Configuration par défaut pour l'environnement test :

---
storage:
  class: sfSessionTestStorage
  param:
    session_path: %SF_TEST_CACHE_DIR%/sessions

~`auto_start`~

L'option auto_start active ou désactive la fonctionnalité de PHP d'auto-démarrage de session (via la fonction session_start()).

~`session_name`~

L'option session_name définit le nom du cookie utilisé par symfony pour stocker la session utilisateur. Par défaut, le nom est symfony, ce qui signifie que toutes vos applications stockeront dans le même cookie (ainsi que l'authentification et les autorisations correspondantes).

Les paramètres de `session_set_cookie_params()`

Le factory storage appelle la fonction session_set_cookie_params() avec la valeur des options suivantes :

~session_cookie_lifetime~ : durée de vie du cookie de session, défini en secondes.
~session_cookie_path~ : Chemin sur le domaine où le cookie va fonctionner. Utilisez un simple slash (/) pour tous les chemins sur le domaine.
~session_cookie_domain~ : domaine de cookie, par exemple www.php.net. Pour faire des cookies visible sur tous les sous-domaines alors le domaine doit être préfixé avec un point comme .php.net.
~session_cookie_secure~ : Si c'est à true alors le cookie ne sera envoyée que sur des connexions sécurisées.
~session_cookie_httponly~ : Si c'est à true alors PHP tentera d'envoyer le flag httponly lors du paramétrage du cookie de session.

La description de chaque option provient de la description de la fonction session_set_cookie_params() sur le site de PHP

~`session_cache_limiter`~

Si l'option session_cache_limiter est mise, la fonction PHP session_cache_limiter() est appelée et la valeur de l'option est passée en argument.

Options de la base de données spécifiques de stockage

Lorsque vous utilisez un stockage qui hérite de la classe sfDatabaseSessionStorage, plusieurs options supplémentaires sont disponibles :

~database~ : Le nom de la base de données (obligatoire)
~db_table~ : Le nom de la table (obligatoire)
~db_id_col~ : Le nom de la colonne de la clé primaire (sess_id par défaut)
~db_data_col~ : Le nom de la colonne donnée (sess_data par défaut)
~db_time_col~ : Le nom de la colonne temps (sess_time par défaut)

`view_cache_manager`

Accesseur de sfContext : $context->getViewCacheManager()

Configuration par défaut :

---
view_cache_manager:
  class: sfViewCacheManager
  param:
    cache_key_use_vary_headers: true
    cache_key_use_host_name:    true

Ce factory est créé si le paramètre cache est à true.

La plupart de la configuration de ce factory se fait via le factory view_cache, qui définit l'objet du cache sous-jacent utilisé par le gestionnaire de cache la vue.

~`cache_key_use_vary_headers`~

L'option cache_key_use_vary_headers précise si les clés du cache doivent être inclus dans la partie des entêtes qui varient. En pratique, cela veut dire que le cache de la page doit être dépendant de l'entête HTTP, comme spécifié dans le paramètre du cache vary (valeur par défaut : true).

~`cache_key_use_host_name`~

L'option cache_key_use_host_name précise si les clés du cache doivent être inclus dans la partie du nom de l'hôte. En pratique, cela veut dire que le cache doit être dépendant du nom de l'hôte (valeur par défaut : true).

`view_cache`

Accesseur de sfContext : aucun (utilisé directement par le factory view_cache_manager)

Configuration par défaut :

---
view_cache:
  class: sfFileCache
  param:
    automatic_cleaning_factor: 0
    cache_dir:                 %SF_TEMPLATE_CACHE_DIR%
    lifetime:                  86400
    prefix:                    %SF_APP_DIR%/template

Ce factory est uniquement défini si le paramètre cache est à true.

Le factory view_cache définit une classe de cache qui doit hériter de sfCache (Voir la section Cache pour plus d'information).

`i18n`

Accesseur de sfContext : $context->getI18N()

Configuration par défaut :

---
i18n:
  class: sfI18N
  param:
    source:               XLIFF
    debug:                false
    untranslated_prefix:  "[T]"
    untranslated_suffix:  "[/T]"
    cache:
      class: sfFileCache
      param:
        automatic_cleaning_factor: 0
        cache_dir:                 %SF_I18N_CACHE_DIR%
        lifetime:                  31556926
        prefix:                    %SF_APP_DIR%/i18n

Ce factory est uniquement défini si le paramètre i18n est à true.

~`source`~

L'option source définit le type de conteneur pour les traductions.

Conteneurs intégrés : XLIFF, SQLite, MySQL, et gettext.

~`debug`~

L'option debug définit le mode de débogage. S'il est défini à true, les messages non-traduits sont décorées avec un préfixe et un suffixe (voir ci-dessous).

~`untranslated_prefix`~

Le untranslated_prefix définit un préfixe à utiliser pour les messages non-traduits.

~`untranslated_suffix`~

Le untranslated_suffix définit un suffixe à utiliser pour les messages non-traduits.

~`cache`~

L'option cache définit un factory de cache anonyme pour être utilisé pour la mise en cache des données i18n (voir la section cache pour plus d'informations).

`routing`

Accesseur de sfContext : $context->getRouting()

Configuration par défaut :

---
routing:
  class: sfPatternRouting
  param:
    load_configuration:               true
    suffix:                           ''
    default_module:                   default
    default_action:                   index
    debug:                            %SF_DEBUG%
    logging:                          %SF_LOGGING_ENABLED%
    generate_shortest_url:            false
    extra_parameters_as_query_string: false
    cache:

~`variable_prefixes`~

Par défaut : :

L'option variable_prefixes définit la liste des caractêres qui débutent le nom d'une variable dans un modèle de route.

~`segment_separators`~

Par défaut : / et .

L'option segment_separators définit la liste des séparateurs de segment de la route. La plupart du temps, vous ne voulez pas réécrire cette option pour l'ensemble du routage, mais pour des routes spécifiques.

~`generate_shortest_url`~

Par défaut : true pour les nouveaux projets, false pour les projets mis à niveau

Si elle est à true, l'option generate_shortest_url dira au système de routage de générer la route la plus courte possible. Réglez-le à false si vous voulez que vos routes soient compatibles avec symfony 1.0 et 1.1.

~`extra_parameters_as_query_string`~

Par défaut : true pour les nouveaux projets, false pour les projets mis à niveau

Lorsque certains paramètres ne sont pas utilisés dans la génération d'une route, l'extra_parameters_as_query_string permet à ces paramètres supplémentaires d'être convertie en une chaîne de caractêre d'une query. Réglez-le à false pour revenir sur le comportement de symfony 1.0 ou 1.1. Dans ces versions, les paramètres supplémentaires étaient tout simplement ignorés par le système de routage.

~`cache`~

Par défaut : none

L'option cache L'option cache définit un factory de cache anonyme qui est utilisé pour la mise en cache de la configuration du routage et des données (voir la section cache pour plus d'informations).

~`suffix`~

Par défaut : none

La valeur par défaut du suffixe à utiliser pour toutes les routes. Cette option est obsolète et n'est plus utile.

~`load_configuration`~

Par défaut : true

L'option load_configuration définit si les fichiers routing.yml doivent être automatiquement chargés et analysés. Réglez le à false si vous souhaitez utiliser le système de routage de symfony à l'extérieur d'un projet symfony.

~`lazy_routes_deserialize`~

Par défaut : false

Si le paramètre lazy_routes_deserialize est à true, il permet une relecture paresseuse du cache de routage. Il peut améliorer les performances de vos applications si vous avez un grand nombre de route et si la plupart des routes correspondent aux premières. Il est fortement conseillé de tester le paramètre avant de le déployer en production, car il peut nuire sur les performances dans certaines circonstances.

~`lookup_cache_dedicated_keys`~

Par défaut : false

Le paramètre lookup_cache_dedicated_keys détermine comment le cache de routage est construit. Lorsqu'il est positionné à false, le cache est stocké comme une grande valeur. Lorsqu'il est positionné à true chaque route a son propre stockage de cache. Ce paramètre est un paramètre d'optimisation de performance.

En règle générale, la valeur false est mieux lorsque vous utilisez une classe de cache basée sur un fichier (sfFileCache par exemple), et la valeur true est mieux lorsque vous utilisez une classe de cache basée sur la mémoire (sfAPCCache par exemple).

`logger`

Accesseur de sfContext : $context->getLogger()

Configuration par défaut :

---
logger:
  class: sfAggregateLogger
  param:
    level: debug
    loggers:
      sf_web_debug:
        class: sfWebDebugLogger
        param:
          level: debug
          condition:       %SF_WEB_DEBUG%
          xdebug_logging:  false
          web_debug_class: sfWebDebug
      sf_file_debug:
        class: sfFileLogger
        param:
          level: debug
          file: %SF_LOG_DIR%/%SF_APP%_%SF_ENVIRONMENT%.log

Configuration par défaut pour l'environnement de prod :

---
logger:
  class:   sfNoLogger
  param:
    level:   err
    loggers:

Si vous n'utilisez pas le sfAggregateLogger, n'oubliez pas de spécifier la valeur null pour le paramètre loggers.

Ce factory est toujours défini, mais la journalisation se produit que si le paramètre logging_enabled est à true.

~`level`~

L'option level définit le niveau du journal.

Valeurs possibles : EMERG, ALERT, CRIT, ERR, WARNING, NOTICE, INFO, ou DEBUG.

~`loggers`~

L'option loggers définit la liste des journaux à utiliser. La liste est un tableau de factory de journaux anonymes.

Les classes de journaux intégrées : sfConsoleLogger, sfFileLogger, sfNoLogger, sfStreamLogger, et sfVarLogger.

`controller`

Accesseur de sfContext : $context->getController()

Configuration par défaut :

---
controller:
  class: sfFrontWebController

Les factories de cache anonyme

Plusieurs factories (view_cache, i18n, et routing) peuvent profiter d'un objet du cache s'il est défini dans leur configuration. La configuration de l'objet du cache est similaire pour toutes les factories. La clé de cache définit un factory de cache anonyme. Comme tout factory, il prend une class et une entrée param. L'entrée param peut prendre n'importe quelle option disponible pour la classe du cache.

L'option prefix est la plus importante car elle permet de partager ou de séparer un cache entre différents environnements/applications/projets.

Les classes de cache intégrées : sfAPCCache, sfEAcceleratorCache, sfFileCache, sfMemcacheCache, sfNoCache, sfSQLiteCache, et sfXCacheCache.

更新：2010/03/30 22:44
作成：2009/11/17 16:22

この文書の執筆・編集

リポジトリ：http://github.com/symfony/symfony1-docs
ページ：http://github.com/symfony/symfony1-docs/blob/master/reference/fr/05-factories.markdown
コミット履歴：http://github.com/symfony/symfony1-docs/commits/master/reference/fr/05-factories.markdown

インデックス

Document Index

Le fichier de configuration factories.yml

日本語ドキュメント

Japanese Documents

2011/01/18 Chapter 17 - Extending Symfony
2011/01/18 The generator.yml Configuration File
2011/01/18 Les tâches
2011/01/18 Emails
2010/11/26 blogチュートリアル(8) ビューの作成

リリース情報
Release Information

2.2 : 2.2.1(2013/04/06)
2.1 : 2.1.10(2013/05/06)
2.0 : 2.0.23(2013/03/20)
Symfony2日本語ドキュメント
1.4 : 1.4.20(2012/11/25)
Changelog

日本Symfonyユーザー会

Le fichier de configuration factories.yml

Factories

mailer

~charset~

~delivery_strategy~

~delivery_address~

~spool_class~

~spool_arguments~

~transport~

request

~path_info_array~

~path_info_key~

~formats~

~relative_url_root~

response

~send_http_headers~

~charset~

~http_protocol~

user

~timeout~

~use_flash~

~default_culture~

storage

~auto_start~

~session_name~

Les paramètres de session_set_cookie_params()

~session_cache_limiter~

Options de la base de données spécifiques de stockage

view_cache_manager

~cache_key_use_vary_headers~

~cache_key_use_host_name~

view_cache

i18n

~source~

~debug~

~untranslated_prefix~

~untranslated_suffix~

~cache~

routing

~variable_prefixes~

~segment_separators~

~generate_shortest_url~

~extra_parameters_as_query_string~

~cache~

~suffix~

~load_configuration~

~lazy_routes_deserialize~

~lookup_cache_dedicated_keys~

logger

~level~

~loggers~

controller

Les factories de cache anonyme

この文書の執筆・編集

インデックス

Document Index

関連ページリスト

Related Pages

日本語ドキュメント

Japanese Documents

リリース情報 Release Information

`mailer`

~`charset`~

~`delivery_strategy`~

~`delivery_address`~

~`spool_class`~

~`spool_arguments`~

~`transport`~

`request`

~`path_info_array`~

~`path_info_key`~

~`formats`~

~`relative_url_root`~

`response`

~`send_http_headers`~

~`charset`~

~`http_protocol`~

`user`

~`timeout`~

~`use_flash`~

~`default_culture`~

`storage`

~`auto_start`~

~`session_name`~

Les paramètres de `session_set_cookie_params()`

~`session_cache_limiter`~

`view_cache_manager`

~`cache_key_use_vary_headers`~

~`cache_key_use_host_name`~

`view_cache`

`i18n`

~`source`~

~`debug`~

~`untranslated_prefix`~

~`untranslated_suffix`~

~`cache`~

`routing`

~`variable_prefixes`~

~`segment_separators`~

~`generate_shortest_url`~

~`extra_parameters_as_query_string`~

~`cache`~

~`suffix`~

~`load_configuration`~

~`lazy_routes_deserialize`~

~`lookup_cache_dedicated_keys`~

`logger`

~`level`~

~`loggers`~

`controller`

リリース情報
Release Information