schema

Symfony 1.1 Command Line Interface (CLI)

h2. Visão geral

Muitas das tarefas(tasks) que os desenvolvedores executam ao desenvolver/manter aplicações podem ser tratadas com a CLI (Command Line Interface) do symfony. “Capítulo 16″:http://www.symfony-project.com/book/1_1/16-Application-Management-Tools mostra algumas dessas tarefas com detalhes, enquanto este cookbook descreve todas elas com uma breve descrição.

h2. CLI core

O `symfony` é um script PHP que ficam no diretório root de um projeto. O comando symfony é seguido de uma tarefa, e algumas dessas tarefas precisam de parâmetros adicionais. Para chamar o script, utilize a seguinte sintaxe:

$ cd myproject
$ php symfony [argumentos]

Uma tarefa pode ter também algumas opções:

$ php symfony [argumentos] –option1=value –option2

*Nota*: O comando symfony(CLI) só funciona quando rodado dentro do diretório root do projeto

O “symfony sandbox”:http://www.symfony-project.com/book/1_1/03-Running-Symfony#Installing%20the%20Sandbox contém executáveis para Windows e *nix que permitem uma maneira mais fácil de ser chamada:

$ ./symfony [parametros] # *nix
$ symfony [parametros] # Windows

Os exemplos desse capítulo irão utilizar o executável `php`, mas você pode omitir isso no seu projeto caso ele tenha os respectivos executáveis

Para listar todas as possíveis tarefas, digite:

$ php symfony

Para listar a versão do symfony instalada, digite:

$ php symfony -V

Algumas tarefas possuem atalhos, maneira mais rápida para chamar tarefas e que dão o mesmo efeito:

$ php symfony cc
// é o mesmo que
$ php symfony cache:clear

Quando ocorre um erro, você pode pegar o stack trace e informações detalhadas. Para isso, adicione a opção `-t` antes do nome da tarefa para obter o trace.

h2. CLI tasks

Cada tarefa possui uma descrição dizendo para que serve, todos os argumentos que ela recebe e todas as opções que ela aceita. Para obter essas informações você pode utilizar a tarefa `help`:

$ php symfony help cache:clear

h3. Estrutura da tarefa generate

p.

$ php symfony generate:project

Inicia um novo projeto

$ php symfony generate:app

Inicia uma nova aplicação

$ php symfony generate:module

Inicia um novo módulo

Saiba mais sobre esses comandos em “Capítulo 16″:http://www.symfony-project.com/book/1_1/16-Application-Management-Tools

h3. Gerando os Models

p.

$ php symfony configure:database mysql://localhost/db_name

Configura os dados do banco de dados tanto para `config/databases.yml` quanto para `config/propel.ini`.

$ php symfony propel:build-model

Gera as classes do Propel para o model baseado no(s) arquivo(s) schema (YAML ou XML) do diretório `config/`

As configurações de conexão utilizadas por esses comandos são tiradas do arquivo `config/propel.ini`

$ php symfony propel:build-sql

Gera o SQL para criar as tabelas descritas no `schema.yml` no arquivo `data/schema.sql`

$ php symfony propel:build-db

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

$ php symfony propel:insert-sql

Insere o SQL do arquivo `data/schema.sql` dentro do banco de dados

$ php symfony propel:build-forms

Gera os formulários baseado no model

$ php symfony propel:build-all

Executa `propel:build-model`, `propel:build-sql`, `propel:build-forms`, e `propel:insert-sql` em um único comando

Saiba mais sobre esses comandos em “Capítulo 8″:http://www.symfony-project.com/book/1_1/08-Inside-the-Model-Layer

h3. Manipulando o Schema

p.

$ php symfony propel:build-schema [--xml]

Cria o `schema.yml` de um banco de dados existente. Se o parâmetro `–xml` for adicionado, as tarefas serão criadas como XML no arquivo `schema.xml`

$ php symfony propel:schema-to-yml

Cria uma versão em YAML do schema em XML

$ php symfony propel:schema-to-xml

Cria uma versão em XML do schema em YAML

h3. Manipulando dados

p.

$ php symfony propel:data-load [--env=] [--dir=]

Carrega todos os dados do diretório padrão `data/fixtures/` caso nenhum seja especificado. O environment por padrão é `dev`. O diretório precisa ser especificado com um caminho relativo ao diretório de dados, por exemplo, `fixtures` (padrão) ou `testdata` ou especificando um arquivo `fixtures/arquivo.yml`

$ php symfony propel:build-all-load

Executa `propel:build-all` depois `propel:data-load`. Aceita os mesmos argumentos do `propel:data-load`

$ php symfony propel:data-dump [] [--env=]

Faz um backup do banco de dados em um arquivo no no formato YAML dentro do diretório de fixtures

h3. Ferramentas de desenvolvimento

p.

$ php symfony cache:clear [--app=] [--type=template|config|i18n|routing] [--env=]

Limpa as informações que estão no cache (atalho: `cc`) (saiba mais em “Capítulo 12″:http://www.symfony-project.com/book/1_1/12-Caching )

$ php symfony project:permissions

Corrige as permissões dos diretórios, colocando `777` nos que precisam ser escritos. A permissão pode ser quebrada se você estiver usando uma versão do repositório SVN

$ php symfony project:freeze
$ php symfony project:unfreeze

Copia todas as bibliotecas necessárias para as pastas `data/`, `lib/` e `web/sf` do seu projeto. Seu projeto então passa a ser um tipo de sandbox, por exemplo: uma aplicação, sem dependências e pronta para ser transferida para produção via FTP. Isso funciona tanto para instalações com PEAR quanto para links simbólicos. Remova todas essas bibliotecas (unfreeze) com a tarefa `project:unfreeze`

$ php symfony project:deploy [--go]

Sincroniza seu projeto atual com outra máquina (geralmente seu servidor) saiba mais em “Capítulo 16″:http://www.symfony-project.com/book/1_1/16-Application-Management-Tools#Deploying%20Applications )

h3. Testes

p.

$ php symfony test:unit

Executa uma “unit test” que fica localizada no diretório `test/unit`. O parâmetro pode ser o mesmo de um arquivo de uma simples unidade de teste (omitinho o sufixo `Test.php`), um grupo de arquivos de unidade de teste, ou um path. Se nenhum nome for dado ao teste, todas a unidades de teste serão executadas.

$ php symfony test:unit

Executa todos os testes de unidade no modo “harness”

$ php symfony test:functional

Executa um teste funcional para uma aplicação específica. O parâmetro `TEST` pode ser o nome de um único arquivo de teste funcional (omitindo o sufixo `Test.php`), um grupo de arquivos de unidade de teste, ou um simples path.

$ php symfony test:functional

Executa todos os testes funcionais de uma aplicação no modo “harness”

$ php symfony test:all

Executa todos os testes funcionais e de unidade no modo “harness”

Saiba mais sobre testes em “Capítulo 15″:http://www.symfony-project.com/book/1_1/15-Unit-and-Functional-Testing

h3. Administração de projetos

p.

$ php symfony project:disable

Encaminha o usuário para o módulo e ação não disponivel no seu `settings.yml` e faz do mesmo jeito se voce tem ligada a configuração de não disponivel no `settings.yml`. A vantagem dessa configuração é que você pode desabilitar uma simples aplicação para um único environment e não só o projeto inteiro.

$ php symfony project:enable

Habilita a aplicação e limpa o cache

$ php symfony log:clear

Limpa os arquivos de log que estão no diretório de log das aplicações e environments onde o `logging.yml` especifica `purge: on` (valor padrão)

$ php symfony log:rotate

Força a rotação de arquivos de log. As opções de rotação são `–period` (o número de dias para trocar de arquivo_ e `–history` (o número de arquivos de backups que serão mantidos)

h3. Geração de Esqueleto e Admin

p.

$ php symfony propel:generate-crud

Gera um novo módulo Propel CRUD baseado na classe do modelo. A versão normal copia o código do framework para um novo módulo; se você adicionar a opção `–generate-in-cache`, a tarefa cria um módulo vazio que herda do módulo da framework. Nesse caso, o código gerado é visível somente no diretório `cache/` (as ações e templates gerados herdam da framework)

$ php symfony propel:init-admin

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

Saiba mais sobre esses comandos em “Capítulo 14″:http://www.symfony-project.com/book/1_1/14-Generators

h2. Manipulando plugins

p.

$ php symfony plugin:install [/]

Instala um novo plugin. Para instalar um novo plugin vindo do wiki do symfony, o nome implicito do canal é `symfony`

$ php symfony plugin:upgrade [/]

Atualiza um plugin

$ php symfony plugin:upgrade-all

Atualiza todos os plugins previamente instalados

$ php symfony plugin:uninstall [/]

Desinstala um plugin

Saiba mais sobre plugins em “Capítulo 17″:http://www.symfony-project.com/book/1_1/17-Extending-Symfony

h2. Preenchimento automático

A wiki do symfony contém diversas contribuições dos usuários que mostram como executar os comandos do symfony com preenchimento automático. Veja qual se encaixa no seu CLI:

* “Bash completion”:http://www.symfony-project.com/trac/wiki/BashCompletion
* “Zsh completion”:http://www.symfony-project.com/trac/wiki/ZshCompletion

*Traduzido por Pedro Casado*

cli
criteria
php
schema
symfony

Comments (1)

Permalink

Como fazer um upload de arquivo no Symfony 1.1

Como falei no post anterior, o symfony-pt está ajudando na tradução do CookBook do symfony 1.1. Então, estarei postando todos os artigos traduzidos com os respectivo nome de quem os traduziu. Hoje, irei postar um artigo traduzido por mim, e é sobre como fazer um upload no symfony 1.1.

Vale lembrar que todos esses artigos estarão na documentação do symfony.

h2. Visão Geral

Muitas vezes backends e aplicações colaborativas exigem que os usuários façam upload de arquivos. Com algumas linhas de código, o symfony toma conta de tudo: renomeia o arquivo, move para o diretório de upload etc. E o usuário do admin generator também tem acesso ao novo helper que reduz a implementação para uma configuração simples.

h2. Upload de arquivo regular

O upload de um arquivo requer um form em um template, e uma action para lidar com ele. No template, use o helper ‘input_file_tag()’ no form declarando-o como ‘multipart=true’:

echo form_tag(‘media/upload’, ‘multipart=true’)
echo input_file_tag(‘file’)
echo submit_tag(‘Send’)

Irá gerar o código HTML:

<form method="post" enctype="multipart/form-data" action="media/upload">
<input name="file" id="file" type="file" />
<input name="commit" value="Send" type="submit" />
</form>

A action (‘media/upload’ no exemplo) move o arquivo para o diretório de upload:

public function executeUpload()    {
         $fileName = $this\->getRequest()\->getFileName(‘file’);
         $this–>getRequest()–>moveFile(‘file’, sfConfig::get(‘sf_upload_dir’) . ‘/’ . $fileName);
         $this->;redirect(‘media/show?filename=’.$fileName);
}

O parâmetro ‘sf_upload_dir’ detém o caminho absoluto no seu servidor, para onde o arquivo vai ser enviado. Para o projeto chamado ‘myproject’, normalmente é em ‘/home/production/myproject/web/upload/’. Você pode modificá-lo em ‘config/config.php’:

sfConfig::add(array(‘sf_upload_dir_name’  => $sf_upload_dir_name = ‘uploads’ , ‘sf_upload_dir’  => sfConfig::get(‘sf_root_dir’) . DIRECTORY_SEPARATOR . sfConfig::get(‘sf_web_dir_name’)  . DIRECTORY_SEPARATOR . $sf_upload_dir_name,));

*Nota*: Antes de mover um arquivo para o diretório de upload, você deve ‘limpar’ o nome do arquivo substituindo caracteres especiais para evitar problemas de arquivo do sistema. Além disso, você deve escapar o ‘$fileName’ antes de passá-lo como um pedido de parâmetro.
Para mostrar o arquivo enviado, use o parâmetro ‘sf_upload_dir_name’. Por exemplo, se o arquivo for uma imagem, o template ‘media/show’ ficará assim:


echo image_tag(‘/’.sfConfig::get(‘sf_upload_dir_name’) . ‘/’.$sf_params->get(‘filename’))

h2. Validação

Como inputs de texto normais, o file upload pode ser validado pelo symfony validator com o ‘sfFileValidator’. Mas lembre-se de colocar o parâmetro ‘file: true’ na declaração do validator abaixo de ‘names’. Por exemplo, o ‘validate/upload.yml’ do form anterior deve ser escrito assim:

   methods:
      post:               [file]
    names:
      file:
        required:         Yes
        required_msg:     Please upload a file
        validators:       myFileValidator
        file:             true
    myFileValidator:
      class:              sfFileValidator
      param:
        mime_types:
          – ‘image/jpeg’
          – ‘image/png’
          – ‘image/x-png’
          – ‘image/pjpeg’
        mime_types_error: Only PNG and JPEG images are allowed
        max_size:         512000
        max_size_error:   Max size is 512Kb

*Nota*: Devido a inconsistências entre o Internet Explorer e outros navegadores, você terá que usar mime-types específicos para o IE.
O ‘sfFileValidator’ pode validar o tipo de arquivo enviado (você pode especificar um array de mime-types) e seu tamanho (você pode especificar o tamanho mínimo e o máximo).

h2. Thumbnails

Se você fizer uploades de imagem, talvez você precise criar thumbnails para cada arquivo enviado. Nesse caso, o ‘sfThumbnail’ plugin pode lhe ser útil.
Primeiro, instale o plugin usando a linha de comando do symfony:

$ symfony plugin-install http://plugins.symfony-project.com/sfThumbnailPlugin
$ symfony cc

*Nota*: Se a biblioteca GD não está ativada, você terá que descomentar a linha relacionada em seu ‘php.ini’ e reiniciar seu servidor web para ativar as funções PHP.
Com o plugin instalado, você pode usá-lo através do objeto ‘sfThumbnail’. Por exemplo, para salvar um thumbnail com no máximo 150x150px ao mesmo tempo em que envia a imagem no exemplo acima, substitua a action ‘media/upload’ por:

public function executeUpload()    {
         $fileName = $this\->getRequest()\->getFileName(‘file’);
         $thumbnail = new sfThumbnail(150, 150);
         $thumbnail\->loadFile($this\->getRequest()\->getFilePath(‘file’));
         $thumbnail->save(sfConfig::get(‘sf_upload_dir’).‘/thumbnail/’ . $fileName, ‘image/png’);
         $this\->getRequest()\->moveFile(‘file’, sfConfig::get(‘sf_upload_dir’) . ‘/’ . $fileName);
         $this->redirect(‘media/show?filename=’.$fileName);
}

Não esqueça de criar o diretório ‘uploads/thumbnail’ antes de executar a action.

h2. Upload de arquivo no admin generator

Se o seu modelo de dados contém um campo para arquivos, e se sua administração é feita com o admin generator, você pode usar o helper ‘object_admin_input_file_tag()’. Ele faz tudo pra você com uma simples configuração.
Por exemplo, você tem a tabela ‘User’ com a coluna ‘photo’, o ‘generator.yml’ para o view do ‘edit’, pode ser configurado assim:

   edit:
      title:          User profile
      fields:
        photo:
          name:       User photo
          help:       max width 200px
          type:       admin_input_file_tag
          upload_dir: pictures/users
          params:     include_link=pictures/users include_remove=true
      display:        [name, email, photo]

O ‘upload_dir’ define o diretório de uploads (sob o diretório ‘uploads/’).
Se você incluir um parâmetro ‘include_link’, um link será adicionado ao arquivo enviado (isto é, se um arquivo de media for enviado). O texto do link é ‘[show file]‘ por padrão, a não ser que você especifique com o parâmetro ‘include_text’.

Se você incluir um ‘include_remove’, o helper mostrará um link para remover o arquivo quando clicado.

*Traduzido por Bernardo Dantas*

ajax
schema
symfony

Comments (1)

Permalink

No package found for database “” in generated-schema.xml

Tive esse erro hoje pela manhã. O problema é que eu tinha um config/schema.xml definido pelo symfony propel-build-schema e isso estava dando conflito com o schema.yml vazio.

A solução é remover o schema.yml.

  rm -f config/schema.yml

Isso resolve o problema do symfony propel-build-schema + propel-build-sql

http://osterman.com/wordpress/2007/08/17/symfony-no-package-found-for-database-in-generated-schemaxml

php
schema
symfony

Comments (0)

Permalink