• comment gérer plusieurs langues pour l'interface de vos modules d'administration en indiquant la langue dans l'URL
• et comment basculer en un clic d'une langue à une autre.

Basculer rapidement entre les langues.

Cet article est écrit pour Symfony 1.4 avec l'admin-generator Doctrine. Nous utiliseront également le plugin sfLanguageSwitchPlugin.

La première étape importante est d'activer i18n dans le fichier settings.yml de l'application :

all:
  .settings:
    # Enable internationalization
    i18n:            true
    default_culture: fr

Le paramètre default_culture ne semble pas avoir d'incidence.

Dans les applications développées sous Symfony, la langue d'une page peut être indiquée dans l’URL via l’attribut :sf_culture. Une route localisée ressemble à cela :

map:
  url:   /:sf_culture/map/:id
  requirements: { sf_culture: (?:en|es|fr) }
  param: { module: map, action: view }

Le paramètre requirements décrit un pattern à respecter pour le champ :sf_culture. Le simple ajout du paramètre :sf_culture dans l'URL modifie automatiquement la langue de l'utilisateur. Il n'y a pas besoin de passer ce paramètre pour générer l'URL avec les url_for(...) et autres link_to(...).

Pour prendre en compte ce paramètre dans les modules d’admin, j'ai créé des classes routing spécifiques. Deux fichiers dans le répertoire lib du projet ou de l'application (au choix) :

La classe sfI18NDoctrineRoute ajoute le paramètre :sf_culture aux routes.

/lib/routing/sfI18NDoctrineRoute.class.php

class sfI18NDoctrineRoute extends sfDoctrineRoute
{
  /**
   * @see sfRoute
   */
  public function __construct($pattern, array $defaults = array(), array $requirements = array(), array $options = array())
  {
    // Add the culture prefix to admin routes
    $pattern = '/:sf_culture' . $pattern;
    parent::__construct($pattern, $defaults, $requirements, $options);
  }
}

/lib/routing/sfI18NDoctrineRouteCollection.class.php

class sfI18NDoctrineRouteCollection extends sfObjectRouteCollection
{
  protected $routeClass = 'sfI18NDoctrineRoute';
}

Maintenant que vos classes sont crées, il faut modifier vos routes. Cela donne par exemple :

my_class:
  class: sfI18NDoctrineRouteCollection
  options:
    model:                MyClass
    module:               my_class
    prefix_path:          /my_class
    column:               id
    with_wildcard_routes: true

Essayer maintenant d'afficher votre module en modifiant le paramètre de langue :

http://localhost/app/fr/my_class

http://localhost/app/hu/my_class

Notez bien qu'il n'est ici pas nécessaire d'ajouter les fichiers XLIFF de langue dans le répertoire i18n de l'application. Les fichiers du plugin Doctrine sont directement utilisés.

Si vous souhaitez afficher une barre de choix de la langue, rien de plus simple grâce au plugin sfLanguageSwitchPlugin qui vous fourni un composant dédié.

Téléchargez sfLanguageSwitchPlugin et installez-le comme décrit dans la notice.

/apps/backend/config/settings.yml

all:
  .settings:
    enabled_modules:    [sfLanguageSwitch]
    i18n:                     true

/apps/backend/config/app.yml

all:
  # sfLanguageSwitchPlugin
  sfLanguageSwitch:
    flagPath: /sfLanguageSwitch/images/flag
    availableLanguages:
      en: { title: English }
      ar: { title: العربية}
      bg: { title: български език }
      ca: { title: Català }
      cs: { title: Česky }
      de: { title: Deutch }
      es: { title: Español }
      fi: { title: Suomen kieli }
      fr: { title: Français }
      hr: { title: Hrvatski }
      hu: { title: Magyar }
      id: { title: Bahasa Indonesia }
      it: { title: Italiano }
      lt: { title: Lietuvių kalba }
      lv: { title: Latviešu valoda }
      nl: { title: Nederlands }
      no: { title: Norsk }
      pl: { title: Polski }
      pt: { title: Português }
      ro: { title: Română }
      ru: { title: русский язык }
      sk: { title: Slovenčina }
      sl: { title: Slovenščina }
      sv: { title: Svenska }
      tr: { title: Türkçe }

(Wikipedia : Liste des codes langue)

Ajoutez maintenant le composant à votre layout :

/apps/backend/templates/layout.php

  <body>
    <?php include_component('sfLanguageSwitch', 'get'); ?>
    <?php echo $sf_content ?>
  </body>

Pour afficher sous forme de liste, juste un petit bout de code CSS :

/web/css/main.css

#lang li { display: inline; }

Si vous avez des remarques ou suggestions, n'hésitez pas ! Les commentaires sont là pour ça.

A quoi sert le paramètre with_show dans le fichier generator.yml ?

Aussi surprenante soit-elle, la réponse usuelle à cette question est :

Par défaut, à rien...

Alors comment afficher les détails d'un objet dans une page d'administration sans que celles-ci soient modifiables ? il est bien nécessaire d'activer l'action show. Les plugins sfDoctrineAdminGeneratorWithShowPlugin et sfPropelAdminGeneratorWithShowPlugin ont été créés pour compenser ce manque. Malheureusement ils ne fonctionnent que pour Symfony 1.2 et 1.3.

Paralysé par cette absence d'action show sous Symfony 1.4, je me suis lancé dans la correction du plugin sfDoctrineAdminGeneratorWithShowPlugin pour le rendre compatible.

Télécharger sfDoctrineAdminGeneratorWithShowPlugin pour Symfony 1.4

Pour installer le plugin, décompressez l'archive dans le répertoire plugin/ de votre projet Symfony.

Activez le plugin en modifiant le fichier config/ProjectConfiguration.class.php

$this->enablePlugins('sfDoctrinePlugin','sfDoctrineAdminGeneratorWithShowPlugin');

Générez le module d'administration :

./symfony doctrine:generate-admin --theme=adminWithShow application ClasseExemple

Activez l'action vue dans le fichier application/modules/classe_exemple/config/generator.yml

    with_show: true

Cela donne par exemple :

generator:
  class: sfDoctrineGenerator
  param:
    model_class:           ClasseExemple
    theme:                 adminWithShow
    non_verbose_templates: true
    with_show:             true
    singular:              ~
    plural:                ~
    route_prefix:          classe_exemple
    with_doctrine_route:   true

    config:
      actions: ~
      fields:  ~
      list:    ~
      filter:  ~
      form:    ~
      edit:    ~
      new:     ~
      show:    ~

Maintenant que l'action show est ajoutée, vous pouvez personnaliser à souhait votre module d'administration en modifiant le fichier generator.yml et/ou les templates. Toute la documentation utile est sur le site du framework.

• Modélisation des tables et des relations spécifiquement pour MySQL,
• Génération des scripts SQL et de la base de données MySQL,
• Création des diagrammes à partir d'une base MySQL existante ou d'un script SQL.

Diagramme sous MySQL Workbench

Mais pour un projet contenant de nombreuses tables, il est parfois nécessaire d'effectuer des traitements automatiques sur celles-ci. MySQL Workbench est un logiciel "programmable", c'est-à-dire qu'il est possible de développer des script/plugins pour automatiser certaines tâches telles que :

• génération de code (comme le schema.yml de Doctrine),
• création de documentation,
• modifications du schéma ...

Le langage de programmation est LUA, celui-ci a une syntaxe proche de python, quelques exemples de code sont disponibles sur le wiki de MySQL.

Cet article a été écrit en utilisant MySQL Workbench 5.2 OSS.

MySQL Workbench propose une console pour la saisie de commandes simples. Pour la l'afficher depuis le menu :
View>Advenced>GRT Shell ou au clavier CTRL+F3.

Console d'exécution de commande LUA

Vous pouvez essayer avec la commande suivante pour afficher le contenu du catalogue :

print(grtV.getGlobal("/wb/doc/physicalModels/0/catalog"))

Maintenant que nous savons exécuter des commandes simples, nous allons apprendre à créer un script LUA. Pour cela, il faut afficher l'explorateur de scripts en cliquant sur l'onglet GRT Shell dans la colonne de droite. Si cet onglet n'apparaît pas, cliquez sur l'icône noire Show GRT Schell IDE.

Cliquer sur l'onglet "GRT Shell" puis sur l'icône "New" pour créer un nouveau script.

Cliquez sur l'icône New à gauche puis choisissez le type de fichier LUA Script File. Sous Windows, ceux-ci sont enregistré par défaut dans votre répertoire %APPDATA%\Roaming\MySQL\Workbench\scripts\

Essayez de coller ce qui suit dans l'éditeur de code qui apparait.

-- Affichage de toutes les tables du catalogue
catalog = grtV.getGlobal("/wb/doc/physicalModels/0/catalog")
for i=1, grtV.getn(catalog.schemata) do
  print("Schema: " .. catalog.schemata[i].name .. "\n")
  for j=1, grtV.getn(catalog.schemata[i].tables) do
    print("  " .. catalog.schemata[i].tables[j].name ..
	  " (" .. grtV.getn(catalog.schemata[i].tables[j].columns) .. " attributs)\n")
  end
end

Enfin cliquez sur le bouton Execute et constatez le résultat. Vous pouvez modifier le code à votre convenance.

La fenêtre GRT Tree vous permet d'explorer l'arborescence des données de votre fichier MySQL Workbench pour vous aider au développement.

Pour créer un plugin sous MySQL Workbench sous Windows Vista ou Seven, il est nécessaire d'exécuter ce logiciel en tant qu'administrateur pour qu'il ait les droits en écriture sur le répertoire %PROGRAMS%\MySQL\MySQL Workbench 5.1 OSS\modules.

Un plugin se crée de la même manière qu'un script LUA, mais celui-doit contenir des fonctions supplémentaires décrivant sont fonctionnement au logiciel. Faites donc de même en choisissant LUA GRT Module File.

Créer un plugin sous MySQL Workbench

En choisissant l'un des deux templates, les fonctions de description du module sont pré-écrites. Votre plugin final sera architecturé comme décrit dans le schéma ci-dessous.

Architecture d'un plugin MySQL Workbench

C'est à vous de jouer maintenant. Vous pouvez vous inspirer des quelques plugins présents par défaut dans MySQL Workbench.

• Lua 5.1 Reference Manual
  Référence complète du langage LUA
• MySQL Workbench Plugins
  Création et installation de plugins