Development

Documentation/fr_FR/book/trunk/cli (diff)

You must first sign up to be able to contribute.

Changes from Version 1 of Documentation/fr_FR/book/trunk/cli

Show
Ignore:
Author:
clochix (IP: 213.41.240.148)
Timestamp:
12/16/06 20:48:43 (11 years ago)
Comment:

translation creation

Legend:

Unmodified
Added
Removed
Modified
  • Documentation/fr_FR/book/trunk/cli

    v0 v1  
     1{{{ 
     2#!html 
     3<div style="border: solid 2px #f80;padding:10px;margin:5px;background-color: #fdb"> 
     4}}} 
     5Cette partie de la documentation est en cours de traduction. Cela signifie qu'elle est traduite de manière soit incomplète, soit inexacte. En attendant que cette traduction soit terminée, vous pouvez consulter la [http://www.symfony-project.com/book/trunk/about version en anglais] pour des informations plus fiables. 
     6{{{ 
     7#!html 
     8</div> 
     9}}} 
     10 
     11= l'interface en ligne de commande = 
     12 
     13== Introduction == 
     14 
     15L'interface en ligne de commande de symfony (CLI) permet d'exécuter de nombreuses tâches utiles lors du développement et de la maintenance d'une application web. 
     16 
     17== Pake == 
     18 
     19Pour les tâches courantes, Symfony utilise un Pake, un utilitaire PHP similaire à Rake en Ruby, et équivalent à la commande `make`. Il permet d'automatiser des tâches d'administration. Pake utilise un fichier de configuration, `pakefile.php`. Dans Symfony, Pake est appelé en tapant simplement `symfony` en ligne de commande. 
     20 
     21Il est à noter que l'interface en ligne de commande ne fonctionnera qu'appelée depuis le répertoire racine du projet racine. 
     22 
     23== Les commandes de base == 
     24 
     25{{{ 
     26    $ symfony -V 
     27}}} 
     28Retourne la version de symfony 
     29 
     30{{{ 
     31    $ symfony 
     32}}} 
     33Retourne la liste de toutes les tâche disponibles. 
     34 
     35La commande `symfony` prend en paramètre un nom de tâche, celle-ci pouvant nécessiter des options supplémentaires. Le modèle de syntaxe est  
     36{{{ 
     37    $ symfony [options] <TACHE> [paramètres] 
     38}}} 
     39 
     40Certaines tâches peuvent également être appelées via un raccourcis. Par exemple 
     41{{{ 
     42    $ symfony cc 
     43    // a le même effet que 
     44    $ symfony clear-cache 
     45}}} 
     46 
     47En cas d'erreur à l'exécution de la têche, vous pouvez utiliser l'option `-t` pour obtenir plus de détails et la pile des appels. 
     48 
     49== Les tâches == 
     50 
     51=== Générer la structure du projet === 
     52 
     53{{{ 
     54    $ symfony init-project <PROJECT_NAME> 
     55}}} 
     56Initialise un nouveau projet symfony (raccourcis: `new`) 
     57 
     58{{{           
     59    $ symfony init-app <APPLICATION_NAME> 
     60}}} 
     61Initialise une nouvelle application (raccourcis: `app`)  
     62 
     63{{{ 
     64    $ symfony init-module <APPLICATION_NAME> <MODULE_NAME> 
     65}}} 
     66Initialise un nouveau module (raccourcis: `module`) 
     67 
     68{{{ 
     69    $ symfony init-batch <SKELETON_NAME> [...] 
     70}}} 
     71Initialise un nouveau traitement batch (raccourcis: `batch`). Il faut choisir le squelette à utiliser et suivre les instructions. 
     72 
     73{{{ 
     74    $ symfony init-controller <APPLICATION_NAME> <ENVIRONMENT_NAME> [<SCRIPT_NAME>] [true|false] 
     75}}} 
     76Initialise un nouveau contrôleur (raccourcis: `controller`). Le nom du script par défaut doit respecter les conventions de nommage de symfony. 
     77 
     78Vous trouverez plus de détail sur ces commandes dans le chapitre sur la création de projets. 
     79 
     80=== Générer le modèle === 
     81 
     82{{{ 
     83    $ symfony propel-build-model 
     84}}} 
     85Crée les classes Propel à partir des fichiers schema (YAML ou XML) du répertoire `config/`. 
     86 
     87Les paramètres de connection utilisés par les commandes suivantes sont extraits du fichier de configuration `config/propel.ini`. 
     88     
     89{{{ 
     90    $ symfony propel-build-sql 
     91}}} 
     92Génère dans le fichier `data/schema.sql` les instructions SQL pour créer les tables décrites dans `schema.yml`. 
     93 
     94{{{ 
     95    $ symfony propel-build-db 
     96}}} 
     97Crée une nouvelle base de données à partir des informations de connection. 
     98 
     99{{{ 
     100    $ symfony propel-insert-sql 
     101}}}     
     102Exécute les instructions du fichier `data/schema.sql` pour créer les tables dans la base. 
     103 
     104{{{     
     105    $ symfony propel-build-all 
     106}}} 
     107Exécute successivement `propel-build-model`, `propel-build-sql` et `propel-insert-sql`. 
     108 
     109{{{ 
     110    $ symfony propel-load-data  <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>] 
     111}}}     
     112Charge les données dans les tables. Si aucun fichier ou répertoire n'est indiqué, les données seront chargées à partir des fichiers contenus dans `data/fixtures/`. L'environnement par défaut est `dev`. 
     113Le chemin du répertoire contenant les données à charger est relatif au répertoire `data` du projet, par exemple `fixtures` (par defaut) ou `testdata` ou juste un fichier : `fixtures/file.yml`.     
     114 
     115{{{ 
     116    $ symfony propel-build-all-load  <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>] 
     117}}} 
     118 
     119Exécute successivement `propel-build-all` puis `propel-load-data`. Les arguments sont les mêmes que pour `propel-load-data`. 
     120 
     121{{{ 
     122    $ symfony propel-build-schema 
     123}}} 
     124Crée un fichier `schema.yml` à partir d'une base de données existante. 
     125 
     126{{{ 
     127    $ symfony propel-build-schema xml 
     128}}} 
     129Crée un fichier `schema.xml` à partir d'une base de données existante. 
     130 
     131Vous trouverez plus d'information sur ces commandes dans le chapitre sur le modèle de données. 
     132 
     133 
     134=== Les outils de développement === 
     135 
     136{{{ 
     137    $ symfony clear-cache [<APPLICATION_NAME>] [template|config] 
     138}}} 
     139Efface toutes des informations du cache (raccourcis: `cc`). Plus de détails dans le chapitre sur le cache. 
     140 
     141{{{ 
     142    $ symfony clear-controllers 
     143}}}     
     144Efface tous les contrôleurs à part ceux utilisés dans l'environnement de production. Une commande utile par exemple avant un déploiement en production. 
     145 
     146{{{ 
     147    $ symfony fix-perms 
     148}}}     
     149Fixes directories permissions, to change to `777` the directories that need to be writable. The permission can be broken if you use a checkout from a SVN repository. 
     150 
     151{{{ 
     152    $ symfony test <APPLICATION_NAME> 
     153}}} 
     154Launches the test suite for an application (find more in the [unit test chapter](test_unit_testing.txt)).    
     155 
     156{{{ 
     157    $ symfony freeze 
     158    $ symfony unfreeze 
     159}}} 
     160Copies all the necessary symfony libraries into the `data/`, `lib/` and `web/sf/` directories of your project. Your project then becomes a kind of sandbox, i.e. a standalone application with no dependence and ready to be transferred to production via FTP. Works fine with PEAR installations as well as symbolic links. Unfreeze your project with the `unfreeze` task. 
     161 
     162{{{ 
     163    $ symfony sync <ENVIRONMENT_NAME> [go] 
     164}}}     
     165Synchronises the current project with another machine (find more in the [deployment chapter](deployment.txt)).    
     166 
     167=== Project administration === 
     168 
     169{{{ 
     170    $ symfony disable <APPLICATION_NAME> <ENVIRONMENT_NAME> 
     171}}} 
     172Forwards the user to the unavailable module and action in your `settings.yml` file and acts in the same way as if you had set the unavaiable setting in your `settings.yml` file. The advantage over the setting is that you can disable a single application for a single environment, and not only the whole project. 
     173 
     174{{{ 
     175    $ symfony enable <APPLICATION_NAME> <ENVIRONMENT_NAME> 
     176}}} 
     177Enables the application and clears the cache.  
     178 
     179{{{ 
     180    $ symfony purge-logs 
     181}}} 
     182Clears the logs files in the log directory in applications and environments where the `logging.yml` specifies `purge: on` (which is the default value). 
     183 
     184{{{ 
     185    $ symfony rotate-log <APPLICATION_NAME> <ENVIRONMENT_NAME> 
     186}}}     
     187Forces a rotation of a log file if `rotate` is enabled for the log file in `logging.yml`. The rotation parameters are the `period` (the number of days a single log file lasts) and the `history` (the number of backup log files kept). Here is an example of `logging.yml` withrotation configutation: 
     188{{{ 
     189    prod: 
     190      rotate:  on 
     191      period:  7       ## Log files are rotated every 7 days by default 
     192      history: 10      ## A maximum history of 10 log files is kepts    
     193}}} 
     194 
     195=== Génération de l'administration et des échafaudages === 
     196 
     197{{{ 
     198    $ symfony propel-generate-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME> 
     199    $ symfony propel-init-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME> 
     200}}}     
     201Generates a new Propel CRUD module based on a class from the model. The `generate` version copies the code from the framework to a new module, the `init` verson creates an empty module that inherits from the one in the framework. In this case, the generated code is visible only in the `cache/` folder (the generated actions and templates inherit from the framework). 
     202 
     203{{{ 
     204    $ symfony propel-init-admin <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME> 
     205}}}     
     206Initializes a new Propel admin module based on a class from the model 
     207 
     208Find more about these commands in the [scaffolding](scaffolding.txt) and [generator chapter](generator.txt). 
     209 
     210=== Gestion des Plugin === 
     211 
     212{{{ 
     213    $ symfony plugin-install [local|global] <CHANNEL_NAME>/<PLUGIN_NAME> 
     214}}}     
     215Installe un nouveau plugin. 
     216 
     217{{{     
     218    $ symfony plugin-upgrade [local|global] <CHANNEL_NAME>/<PLUGIN_NAME> 
     219}}} 
     220Met à jour un plugin existant. 
     221 
     222{{{ 
     223    $ symfony plugin-upgrade-all 
     224}}} 
     225Met à jour tous les plugins installés. 
     226 
     227{{{ 
     228    $ symfony plugin-uninstall [local|global] <CHANNEL_NAME>/<PLUGIN_NAME> 
     229}}}     
     230Supprime un plugin. 
     231 
     232La création, l'installation et la gestion des plugins sont décrits dans le chapitre sur les plugins. 
     233 
     234== La complétion automatique == 
     235 
     236Le wiki de symfony propose des fichiers fournis par des utilisateurs pour permettre la complétion automatique des commandes symfony dans certains interpréteurs de commandes: 
     237 
     238* [Bash completion](http://www.symfony-project.com/trac/wiki/BashCompletion) 
     239* [Zsh completion](http://www.symfony-project.com/trac/wiki/ZshCompletion)  
     240 
     241[1]: http://www.pake-project.org/    "Pake" 
     242 
     243[2]: http://rake.rubyforge.org/      "Rake" 
     244 
     245[3]: http://nanoserv.si.kz/          "Nanoserv"