Interface de Linha de Comando (CLI)

Visão Geral

Muitas das tarefas que um desenvolvedor executa durante a construção e manutenção de uma aplicação web podem ser controladas pela Interface de Linha de Comando do symfony (CLI). O Capítulo 16 descreve algumas destas tarefas detalhadamente, enquanto este capítulo lista todas com uma breve descrição.

Essência da CLI

O script symfony é um script PHP localizado no raiz de um projeto. O comando symfony espera tarefas, e algumas tarefas requerem parâmetros adicionais. Para chamá-lo, utilize a seguinte sintaxe:

    $ cd myproject
    $ php symfony <TASK> [parameters]

Nota: A CLI do symfony funciona somente se executada no root de um projeto symfony

O sandbox do symfony contém executáveis para as plataformas Windows e *nix que permitem uma chamada mais rápida:

    $ ./symfony <TASK> [parameters]      #  *nix
    $ symfony <TASK> [parameters]        #  Windows

Os exemplos deste capítulo utilizarão o executável php, mas você pode omití-lo caso seu projeto possuir os próprios executáveis.

Para listar todas as tarefas possíveis, chame:

    $ php symfony

Para exibir a versão do pacote symfony instalado, digite:

    $ php symfony -V

Algumas tarefas possuem um atalho, rápido para escrever, que tem o mesmo efeito.

    $ php symfony cc
    // faz o mesmo que 
    $ php symfony clear-cache

Quando acontecer uma exceção, você pode desejar obter o stack trace e uma explicação detalhada. Adicione a opção -t antes do nome de tarefa para obter o trace.

Nota: For the records, o symfony utiliza uma ferramenta dedicada chamada Pake para administrar as tarefas comuns. Pake é uma ferramenta php semelhante ao comando Rake, uma tradução Ruby do comando make. O pake foi construído pelo time do symfony. Ele automatiza algumas tarefas de administração de acordo com um arquivo de configuração específico chamado pakefile.php. Mas desde que você somente usa a ferramenta pake digitando symfony em uma linha de comando, não há necessidade de aprender o que o pake faz e como trabalha.

Tarefas da CLI

Geração da estrutura

    $ php symfony init-project <PROJECT_NAME>

Inicializa uma novo projeto symfony (atalho: new).

    $ php symfony init-app <APPLICATION_NAME>

Inicializa uma nova aplicação symfony (atalho: app).

    $ php symfony init-module <APPLICATION_NAME> <MODULE_NAME>

Inicializa um novo módulo symfony (atalho: module).

    $ php symfony init-batch <SKELETON_NAME> [...]

Inicializa uma novo arquivo batch (atalho: batch). Você deve selecionar um esquelo batch para iniciar, e então seguir os prompts.

    $ php symfony init-controller <APPLICATION_NAME> <ENVIRONMENT_NAME> [<SCRIPT_NAME>] [true|false]

Inicializa um novo controller (atalho: controller). O nome do script default segue a convenção do symfony

Encontre mais sobre estes comandos no Capítulo 16.

Geração do modelo

    $ php symfony propel-build-model

Gera as classes Propel para o modelo atual, baseado nos arquivos schema (YAML ou XML) do seu diretório config/

As configurações de conexão usadas pelos seguintes comandos são pegas do arquivo de configuração config/propel.ini.

    $ php symfony propel-build-sql

Gera o código SQL para criar as tabelas descritas no schema.yml, em um arquivo data/schema.sql.

    $ php symfony propel-build-db

Cria um banco de dados vazio baseado nas configurações de conexão.

    $ php symfony propel-insert-sql

Insere o código SQL do data/schema.sql no banco de dados.

    $ php symfony propel-build-all

Executa propel-build-model, propel-build-sql e então propel-insert-sql, todos em um comando.

Encontre mais sobre estes comandos no Capítulo 8.

Gerenciamento do schema

    $ php symfony propel-build-schema [xml]

Cria um schema.yml a partir de um banco de dados existente. Se for adicionado o parâmetro xml, a tarefa cria uma schema.xml ao invés da versão YAML.

    $ php symfony propel-convert-xml-schema

Cria versões YAML dos schemas XML encontrados.

    $ php symfony propel-convert-yml-schema

Cria versões XML dos schemas YAML encontrados.

Gerenciamento dos dados

    $ php symfony propel-load-data  <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>]

Carrega todos os dados do diretório default data/fixtures a menos que outro seja especificado. O ambiente default é dev. O diretório fixtures deve ser especificado relativo ao diretório data do projeto, por exemplo fixtures (default) ou testdata ou especifique um único arquivo fixtures/file.yml.

    $ php symfony propel-build-all-load  <APPLICATION_NAME> [<ENVIRONMENT_NAME>] [<FIXTURES_DIR_OR_FILE>]

Executa propel-build-all e então propel-load-data. Aceita os mesmos argumentos que o propel-load-data.

    $ php symfony propel-dump-data  <APPLICATION_NAME> <FIXTURES_DIR_OR_FILE> [<ENVIRONMENT_NAME>]

Descarrega os dados do banco de dados para um arquivo no diretório fixtures, no formato YAML.

Ferramentas para desenvolvimento

    $ php symfony clear-cache [<APPLICATION_NAME>] [template|config]

Limpa informações do cache (atalho: cc) (encontre mais no Capítulo 12).

    $ php symfony clear-controllers

Limpa do diretório web todos os controllers diferentes dos que executam em ambiente de produção. Muito útil antes de transferir para um servidor de produção.

    $ php symfony fix-perms

Corrige as permissões dos diretórios, para alterar para 777 os diretórios que precisam ser graváveis. A permissão pode ser quebrada se você utiliza um checkout de um repositório SVN.

    $ php symfony freeze
    $ php symfony unfreeze

Copia todas as bibliotecas do symfony necessárias nos diretórios data/, lib/ e web/sf/ do seu projeto. Seu projeto então torna-se um tipo de sandbox, ex: uma aplicação standalone sem dependência e pronta para
ser transferida para produção via FTP. Trabalho bem com instalações PEAR assim como links simbólicos. "Descongele" o seu projeto com a tarefa unfreeze.

    $ php symfony sync <ENVIRONMENT_NAME> [go]

Sincroniza o projeto atual com outra máquina (encontre mais no Capítulo 16).

Testes

    $ php symfony test-unit <UNIT_TEST>

Lança um unit test localizado no diretório test/unit/. O parâmetro poder o nome de um único arquivo para unit test (omitindo o sufixo Test.php), um grupo de arquivos unit test, ou um caminho de arquivo com wildcards. Se não for informado o nome do unit test, todos os unit tests serão executados.

    $ php symfony test-unit

Lança todos os unit tests em modo harness.

    $ php symfony test-functional <APPLICATION_NAME> <TEST>

Lança um functional test para uma determinada aplicação. O parâmetro TEST pode ser o nome de um único functional test (omitindo o sufixo Test.php), um grupo de arquivos unit test ou um caminho de arquivo com wildcards.

    $ php symfony test-functional <APPLICATION_NAME>

Lança todos os functional tests de uma aplicação no modo harness.

    $ php symfony test-all 

Lança todos os unit e functional tests em modo harness.

Encontre mais sobre testes no Capítulo 15.

Administração de projeto

    $ php symfony disable <APPLICATION_NAME> <ENVIRONMENT_NAME>

Direciona o usuário para o módulo e ação informados em unavailable no seu arquivo settings.yml e age da mesma maneira como se você ajustasse a configuração unavaiable em seu arquivo settings.yml. A vantagem sobre o ajuste é que você pode desabilitar uma única aplicação para um único ambiente, e não somente o projeto inteiro.

    $ php symfony enable <APPLICATION_NAME> <ENVIRONMENT_NAME>

Habilita a aplicação e limpa o cache.

    $ php symfony purge-logs

Limpa os arquivos de log, do diretório log, nas aplicações e ambientes onde o logging.yml especificar purge: on (que é o valor default).

    $ php symfony rotate-log <APPLICATION_NAME> <ENVIRONMENT_NAME>

Força um giro do arquivo de log se rotate está habilitado para o arquivo de log no logging.yml. Os parâmetros de giro são o period - período (o número de dias para finalizar um único arquivo de log) e o history - histórico (o número de backups dos arquivos de log para manter). Aqui está um exemplo de configuração com giro no logging.yml:

    prod:
      rotate:  on
      period:  7       ## Arquivos de log são girados a cada 7 dias por default
      history: 10      ## Um histórico máximo de 10 arquivos de log será mantido

Scaffolding e geração de módulo admin

    $ php symfony propel-generate-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>
    $ php symfony propel-init-crud <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>

Gera um novo módulo Propel CRUD baseado na classe do modelo. A versão generate copia o código do framework para um módulo novo, a versão init cria um módulo vazio que herda do framework. Neste caso, o código gerado é visível somente no diretório cache/ (as actions e templates gerados herdam do framework).

    $ php symfony propel-init-admin <APPLICATION_NAME> <MODULE_NAME> <CLASS_NAME>

Inicializa um novo módulo Propel admin com base na classe do modelo

Encontre mais sobre estes comandos no Capítulo 14.

Gerenciamento de Plugin

    $ php symfony plugin-install <CHANNEL_NAME>/<PLUGIN_NAME>

Instala um novo plugin. Para instalar um novo plugin da wiki do symfony, utilize http://plugins.symfony-project.com como nome do channel.

    $ php symfony plugin-upgrade <CHANNEL_NAME>/<PLUGIN_NAME>

Atualiza um plugin.

    $ php symfony plugin-upgrade-all

Atualiza todos os plugins previamente instalados.

    $ php symfony plugin-uninstall <CHANNEL_NAME>/<PLUGIN_NAME>

Desinstala um plugin.

Encontre mais sobre plugins no Capítulo 17.

Completamento automático

A wiki do symfony contém arquivos de configuração contribuídos por usuários para permitir completamento automático dos comandos symfony. Confira o que se ajusta à sua CLI:

• completamento Bash
• completamento Zsh