Ajoutons un generator.yml global à une application

Toujours Symfony, toujours… Comme dit dans la précédente publication, je travaille en ce moment sur plusieurs applications web. Chacun de ces applications me (nous) ont fait faire du symfony propel:init-admin de manière industrielle.

Pour tous ces init-admin, un fichier de configuration global unique de type generator.yml pour l’application que l’on puisse surcharger avec les fichiers generator.yml des modules est un plus. Cela permet par exemple de faire en sorte que la forme de tous les champs “created_at” de nos tables soit stockée à un unique endroit.

Nous allons donc intégrer un fichier globalgenerator.yml dans les fichiers de configuration de symfony, qui sera chargé avant le generator.yml.

Cela se fera en deux étapes :

• 1° étape, surcharger la classe sfGeneratorConfigHandler par une classe monGeneratorConfigHandler
• 2° étape, modifier la classe monGeneratorConfigHandler pour prendre en compte un nouveau fichier de configuration

1° étape, surcharger la classe sfGeneratorConfigHandler par une classe monGeneratorConfigHandler

Tout d’abord, il faut savoir que les fichiers de configuration sont lus par des Handlers, qui sont des classes PHP situées dans vendor/symfony/lib/config en partant du vendor. Chaque fichier de configuration a son propre Handlers, les liens entre les fichiers de configuration et leurs Handlers étant fait dans le fichier config_handlers.yml situé dans vendor/symfony/lib/config/config.

L’idée va être dans un premier temps de surcharger, et le Handler du fichier generator.yml, le bien nommé sfGeneratorConfigHandler, et le config_handlers.yml.

On commence par copier le fichier sfGeneratorConfigHandler.class.php (situé dans vendor/symfony/lib/config) dans le répertoire lib de votre projet (ou à toute autre endroit où vous êtes sur qu’il sera chargé par Symfony).

Renommez ensuite ce fichier en, par exemple monGeneratorConfigHandler.class.php et éditez le pour que l’entête du fichier ressemble à cela :

<?php

class monGeneratorConfigHandler extends sfYamlConfigHandler
{

Note : pour les puristes on pourrait faire en sorte que la classe monGeneratorConfigHandler étende la classe sfGeneratorConfigHandler.

Bon, après, on va faire en sorte que ce soit ce Handler qui soit appelé pour traiter les fichiers generator.yml. Pour cela, on crée un fichier config_handlers.yml dans le dossier config de l’application concernée (soit apps/monApplication/config) et on le remplit avec les lignes suivantes :

modules/*/config/generator.yml:
  class:    monGeneratorConfigHandler

Voilà, désormais, lorsque vous chargez un module avec un generator, c’est notre Handler qui est appelé. Nous allons maintenant éditer ce Handler pour qu’il puisse prendre en compte un fichier de configuration supplémentaire.

2° étape, modifier la classe monGeneratorConfigHandler pour prendre en compte un nouveau fichier de configuration

On va faire en sorte que le Handler prenne en compte le fichier globalgenerator.yml situé dans le dossier config de notre application (si ce fichier existe).

EDIT Note : n’appelez pas le fichier global generator.yml. En effet, placer un fichier generator.yml dans le dossier config de l’application fait crasher la dite application.

Pour cela, on rajoute quelques lignes à la méthode execute de notre classe monGeneratorConfigHandler, ainsi cela :

  ...
  public function execute($configFiles)
  {
    // parse the yaml
    $config = self::getConfiguration($configFiles);
    if (!$config)
    ...

devient cela :

  ...
  public function execute($configFiles)
  {

    $advancedConfigFiles = $configFiles;
    if (file_exists(sfConfig::get('sf_app_config_dir').'/globalgenerator.yml')) {
      $advancedConfigFiles = array_merge(
             array(sfConfig::get('sf_app_config_dir').'/globalgenerator.yml'),
             $configFiles);
    }
    // parse the yaml
    $config = self::getConfiguration($advancedConfigFiles);
    if (!$config)
    ...

Note : la méthode sfConfig::get(‘sf_app_config_dir’) nous permet de récupérer le chemin du dossier config de l’application. D’autres variables peuvent être récupérées par cette manière. On peut notamment les voir dans le menu config/settings de la barre symfony apparaissant dans le navigateur web lorsque l’on charge une page de l’application.

Voilà, désormais, si le fichier globalgenerator.yml existe dans le dossier config de l’application, le Handler ira d’abord le rechercher puis le surchargera avec le generator.yml du module.

Conclusion

Nous avons donc vu comment créer un fichier de configuration global pour tous les generators de notre application. On peut bien entendu penser à surcharger de cette manière d’autres fichiers de configuration (par exemple view.yml)