La console Symfony2. J’ai écrit un article sur comment écrire ses propres commandes, mais rien sur comment bien se servir de celles qui existent déjà ! Le but de cet article est donc remédier à cela, en faisant un tour d’horizon des commandes disponibles de base, et de ce qu’elles permettent de faire.
Commencez par lancer une terminal, et placez-vous à la racine d’un projet Symfony2.
<br />
php app/console<br />
S’il y a une chose à retenir de cet article, c’est cette commande. Elle liste toutes les commandes consoles disponibles, ce qui permet de ne pas avoir à retenir la syntaxe de toutes celles dont je vais vous parler par la suite. Si vous retenez cette commande et que vous savez ce qu’il est possible de faire, vous pouvez ensuite retrouver la commande correspondante dans la liste.
Autre information qui va vous servir, si une commande est bien écrite, normalement le modifieur –help permet d’accéder aux informations d’aide, ce qui permet de se rappeller de comment on utilise une commande.
exemple:
<br />
php app/console doctrine:generate:entity --help<br />
<br />
php app/console generate:bundle<br />
C’est probablement la première commande que vous avez utilisée ! Tapez là, et laissez vous guider pour créer le bundle dans lequel vous allez écrire le code de votre projet. Utilisez les modifieurs décrits dans l’aide si vous voulez gagner un peu de temps.
<br />
php app/console doctrine:database:create<br />
php app/console doctrine:database:drop<br />
Ces 2 commandes créent et suppriment la base de données utilisée par l’application. Les informations de configuration sur la base de données sont précisées dans le fichier app/config/config.yml (dans la section Doctrine/dbal si vous utilisez Doctrine).
En s’en servant bien, elles peuvent un peu accélérer le développement et réduire le temps passé dans la documentation.
<br />
php app/console doctrine:generate:entity<br />
Editeur en ligne de commande pour créer une entité et ses attributs : tapez cette commande et laissez vous guider. Très pratique pour éviter de retenir la syntaxe des annotations ou de la configuration en yml, mais également très limité. Pour faire des choses à peine avancées (ajouter des contraintes sur un attribut par exemple), vous devrez mettre les mains dans le cambouis (ce qui ne vous empeche pas de générer votre entité de manière basique par cette méthode, puis faire les modifications qui restent par vous même).
<br />
php app/console doctrine:generate:entities NomDuBundle<br />
A partir des entités, finalise leur conception en génèrant les accesseurs (méthodes get/set). Par la suite, ces méthodes sont utilisées par le repository par défaut de l’entité (entre autres).
<br />
php app/console generate:doctrine:form NomDuBundle:Entité<br />
Génère le code d’un formulaire par défaut associé à l’entité fournie en paramètre. Il ne faut pas qu’il y ait de formulaire déjà existant pour cette entité, mais ça permet de gagner un peu de temps.
<br />
php app/console generate:doctrine:crud NomDuBundle:Entité<br />
Génère quelques pages basiques de CRUD (Create, Read, Update, Delete) pour l’entité présentée. Cela crée les controlleurs, les routes et les template. C’est pas mal pour apprendre un peu comment marche Symfony, mais en pratique sert vraiment très peu.
Des commandes qui vont vous permettre d’éviter d’aller fouiller dans les fichiers de configuration…
<br />
php app/console router:debug<br />
php app/console router:debug NomDUneRoute<br />
Permet de lister toutes les routes accessibles depuis l’application. C’est particulièrement utile lorsque l’on installe un nouveau bundle et que l’on veut surveiller quelles sont les routes qui ont été ajoutées. Egalement très utile lorsque l’on a plus en tête toutes les routes qui ont été crées lors du développement.
Si vous précisez en argument une route, il vous fournit les informations de configuration associées à la route en question (url associée, controlleur utilisé, etc.)
<br />
php app/console container:debug<br />
php app/console container:debug NomDUnService<br />
De la même manière que précédemment, permet de connaitre les services déclarés dans l’application, et d’avoir des informations sur un service en particulier. Les services servent pas mal une fois qu’on commence à connaitre un peu comment fonctionne le framework, donc si vous ne vous en servez pas aujourd’hui, cela vous servira sans doute demain.
Ne les oubliez pas ! Vous utilisez sans doute déjà la première, en cas de souci pensez à la seconde.
<br />
php app/console assets:install web<br />
Permet de copier les ressource publiques de tous les bundles installés (situées dans NomDuBundle/Resources/public) dans le répertoire web, où elles seront accessibles publiquement. En français, ça veut dire rendre accessible à tous les ressources de développement que vous utilisez. Si votre bundle utilisedes fichiers javascript, css ou des images, il est en général nécessaire d’utiliser cette commande pour les dupliquer dans une répertoire accessible publiquement (le répertoire web, le plus souvent).
<br />
php app/console cache:clear<br />
php app/console cache:clear --env=prod<br />
La première commande vide le cache, la seconde vide spécifiquement le cache de l’environnement de production.
Sur le serveur de production, cette commande est indispensable lors d’un déploiement: cela permet d’éviter que des modifications ne soient pas prises en compte à cause d’infos présentes dans le cache.
En développement, ca peut être une piste si ce que vous essayez de faire n’est pas pris en compte alors que tout indique que cela devrait.
Il en existe d’autres, mais celles ci-dessus servent assez souvent. Lorsque vous installez un bundle (que vous avez par exemple trouvé sur KnpBundles ou au hasard de vos errances sur Github), il n’est pas rare que ce dernier ajoute de nouvelles commandes, renseignez vous sur ce qu’elles permettent de faire : celà peut vous faire gagner beaucoup de temps. Et si ce que votre bundle peut être automatisé, n’hésitez pas à écrire une commande pour le faire !