Troisième partie de cette série,
la création du plugin et l’organisation de ses fichiers
pour créer le plugins, se placer dans le dossier dossier racine Symfony et saisir la commande :
$symfony generate:plugin sfIcalCreatorPlugin
Et valider. Le squelette du plugin est alors créé dans plugins/sfIcalCreatorPlugin.
Contenu du répertoire du plugin :
config lib LICENSE package.xml.tmpl README test
Comme dans l’organisation générale de Symfony, config/ contiendra les fichiers de configuration du plugin, dont le fichier décrivant le modèle de l’application.
lib/ contiendra les classes et test/ les scripts de test unitaire.
Une fois le squelette du plugin créé, il faut configurer l’application courante pour l’utiliser. Se placer dans le dossier racine Symfony et éditer le fichier config/ProjectConfiguration.class.php.
le mien ressemble a ça :
<?php
require_once '/usr/lib/symfony-1.4.1/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
$this->enablePlugins('sfDoctrinePlugin');
}
}
Ajoutons une référence au nouveau plugin :
<?php
require_once '/usr/lib/symfony-1.4.1/lib/autoload/sfCoreAutoload.class.php';
sfCoreAutoload::register();
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
$this->enablePlugins('sfDoctrinePlugin');
$this->enablePlugins('sfIcalCreatorPlugin');
}
}
Et voila! Désormais, les fichiers de schémas disponibles dans le plugin seront accessibles au projet,
ce qui permettra de crée les classes concrètes du plugin pour l’utiliser dans le projet Symfony.
L’avantage du plugin, c’est de pouvoir créer un composant échangeable standard, intégrable dans des applications diverses. Mais si chaque projet modifie le plugin pour ses propres besoins, comment s’y retrouver?
Les développeurs de Symfony ont mis en place le mécanisme suivant pour les classes métiers distribuées avec des plugins :
- le plugin contient des classes dont les noms sont formés comme suit : Plugin[nom modèle]. ex: PluginPerson.
Ces classes sont déclarées abstraites, et ne peuvent être utilisées directement par le projet. Elles contiennent le code métier spécifique livré avec le plugin.
Ces classes héritent d’une autre famille de classe, dont le nom est formé comme suit : Base[nom modele]. ex. BasePerson.
Ces classes ne sont pas livrées avec le plugin, mais seront générées automatiquement par Doctrine. Une troisième famille de classe sera également générée par Doctrine, dans le dossier lib/ du projet courant. Ces classes porteront les noms de modèles, hériteront des classes Plugins[nom modèle] , et pourront (enfin!) être étendues et utilisées par le projet courant.
Dans le prochain billet, je présenterais la configuration de la base de données Sqlite3 et la génération d’un premier modèle via Doctrine.