{ Category Archives }

symfony

Utilizando o rsync do symfony com parâmetros personalizados

Essa é uma dica legal que descobri a um tempo. Para aqueles que quiserem utilizar outras funçoes que o rsync oferece, segue abaixo um trecho de código.

Editando o arquivo config/properties.ini:


[producao]
  host=servidor
  port=porta
  user=usuario
  dir=/diretorio
  parameters="-azC —copy-links —exclude-from=config/rsync_exclude.txt —force —delete"
 

Através do “parameters” podemos passar os parâmetros manualmente.. Nesse caso adicionei o —copy-links

Agora é mole

$ symfony sync producao go

Valeu!

2008 07 22

producao
symfony

Comments (0)

Permalink

Utilizando um CSS específico para cada módulo do symfony

Essa é uma dica simples. Se você tem alguns módulos e quer ter um CSS para cada módulo, aqui vai uma linha que pode ser bastante útil.


  <?php use_stylesheet($sf_context->getModuleName()) ?>  
 

ciao!

2008 07 17

css
php
symfony

Comments (0)

Permalink

Trabalhando com Symfony 1.1 e Doctrine

Quer experimentar o symfony 1.1? Primeiramente vamos ter que configurar um novo projeto e instalar o sfDoctrine para o symfony 1.1. Execute os comandos abaixo e continue lendo:

$ mkdir symfony1.1Doctrine
$ cd symfony1.1Doctrine
$ /path/to/symfony generate:project symfony1.1Doctrine
$ svn co http://svn.symfony-project.com/plugins/sfDoctrinePlugin/trunk plugins/sfDoctrinePlugin
$ php symfony cc

Agora, digite o comando abaixo para listar tudo que o `sfDoctrinePlugin` oferece. Você vai perceber que o comando vai listar os mesmos comandos do `sfPropelPlugin` e muitos outros.

$ php symfony list doctrine
Available tasks for the “doctrine” namespace:
:build-all Generates Doctrine model, SQL and initializes the database (doctrine-build-all)
:build-all-load Generates Doctrine model, SQL, initializes database, and load data (doctrine-build-all-load)
:build-all-reload Generates Doctrine model, SQL, initializes database, and load data (doctrine-build-all-reload)
:build-all-reload-test-all Generates Doctrine model, SQL, initializes database, load data and run all test suites (doctrine-build-all-reload-test-all)
:build-db Creates database for current model (doctrine-build-db)
:build-forms Creates form classes for the current model (doctrine-build-forms)
:build-model Creates classes for the current model (doctrine-build-model)
:build-schema Creates a schema.xml from an existing database (doctrine-build-schema)
:build-sql Creates SQL for the current model (doctrine-build-sql)
:data-dump Dumps data to the fixtures directory (doctrine-dump-data)
:data-load Loads data from fixtures directory (doctrine-load-data)
:dql Execute a DQL query and view the results (doctrine-dql)
:drop-db Drops database for current model (doctrine-drop-db)
:generate-crud Generates a Doctrine CRUD module (doctrine-generate-crud)
:generate-migration Generate migration class (doctrine-generate-migration)
:generate-migrations-db Generate migration classes from existing database connections (doctrine-generate-migrations-db, doctrine-gen-migrations-from-db)
:generate-migrations-models Generate migration classes from an existing set of models (doctrine-generate-migrations-models, doctrine-gen-migrations-from-models)
:init-admin Initializes a Doctrine admin module (doctrine-init-admin)
:insert-sql Inserts SQL for current model (doctrine-insert-sql)
:migrate Migrates database to current/specified version (doctrine-migrate)
:rebuild-db Creates database for current model (doctrine-rebuild-db)

O `sfDoctrinePlugin` atualmente necessita de pelo menos uma aplicação configurada, então, vamos instanciar a aplicação `frontend`.

$ php symfony generate:app frontend

Agora vamos configurar nosso banco de dados em `config/databases.yml`. Abra o arquivo no seu editor predileto e utilize o YAML abaixo. Para esse teste, estamos simplesmente utilizando um banco de dados SQLite. O Doctrine é capaz de criar o banco de dados em `config/doctrine.db`.


    all:
      doctrine:
        class:    sfDoctrineDatabase
        param:
          dsn:    sqlite:///<?php echo dirname(__FILE__); ?>/doctrine.db
   

Agora que nós temos nosso banco de dados configurado, vamos definir nosso schema em `config/doctrine/schema.yml`. Nesse exemplo nós estamos configurando o modelo `BlogPost` que `hasMany` (possui diversas) , `Tags`.


    —-
    BlogPost:
      actAs:
        Sluggable:
          fields: [title]
        Timestampable:
      columns:
        title: string(255)
        body: clob
        author: string(255)
      relations:
        Tags:
          class: Tag
          refClass: BlogPostTag
          foreignAlias: BlogPosts
   
    BlogPostTag:
      columns:
        blog_post_id:
          type: integer
          primary: true
        tag_id:
          type: integer
          primary: true
   
    Tag:
      actAs: [Timestampable]
      columns:
        name: string(255)
   

Agora que nos temos nosso schema definido, vamos criar uma massa de teste em `data/fixtures/data.yml`. Abra o arquivo, e cole o YAML abaixo.


    —-
    BlogPost:
      BlogPost_1:
        title:  symfony + Doctrine
        body:   symfony and Doctrine are great!
        author: Jonathan H. Wage
        Tags:   [symfony, doctrine, php]
   
    Tag:
      symfony:
        name: symfony
      doctrine:
        name: doctrine
      php:
        name: php
   

Ok, vamos para parte legal. Nós temos nosso schema, e temos também nossa massa, então vamos rodar uma única fez o comando do Doctrine abaixo para criar nosso banco de dados, gerar os modelos, criar as tabelas e carregar a massa de teste.

$ php symfony doctrine-build-all-reload frontend
>> doctrine Are you sure you wish to drop your databases? (y/n)
y
>> doctrine Successfully dropped database f…1.1Doctrine/config/doctrine.db”
>> doctrine Successfully created database f…1.1Doctrine/config/doctrine.db”
>> doctrine Generated models successfully
>> doctrine Created tables successfully
>> doctrine Data was successfully loaded

Agora nosso banco de dados SQLite `doctrine.db` foi criado, todas as tabelas do nosso schema foram criadas e populadas. Agora vamos começar a brincar com os dados e ver como nós podemos utilizar o Doctrine Query Language para trazer as informações do banco.

$ php symfony doctrine:dql frontend “FROM BlogPost p, p.Tags t”
>> doctrine executing: “FROM BlogPost p, p.Tags t” ()
>> doctrine –
>> doctrine id: 1
>> doctrine title: symfony + Doctrine
>> doctrine body: symfony and Doctrine are great!
>> doctrine author: Jonathan H. Wage
>> doctrine slug: symfony-doctrine
>> doctrine created_at: 2008-06-16 12:28:57
>> doctrine updated_at: 2008-06-16 12:28:57
>> doctrine Tags:
>> doctrine –
>> doctrine id: 1
>> doctrine name: symfony
>> doctrine created_at: 2008-06-16 12:28:57
>> doctrine updated_at: 2008-06-16 12:28:57
>> doctrine –
>> doctrine id: 2
>> doctrine name: doctrine
>> doctrine created_at: 2008-06-16 12:28:57
>> doctrine updated_at: 2008-06-16 12:28:57
>> doctrine –
>> doctrine id: 3
>> doctrine name: php
>> doctrine created_at: 2008-06-16 12:28:57
>> doctrine updated_at: 2008-06-16 12:28:57

Agora, vamos explicar um pouco os resultados obtidos. Como você pode ver, nos modelos nós temos as colunas created_at, updated_at and slug que não foram definidas no schema. Essas colunas são adicionadas pelo behavior anexado ao schema dentro da configuração actAs. As colunas `created_at` e `updated_at` são automaticamente atualizadas `onInsert` e `onUpdate`, e a coluna do slug é uma string criada baseada na coluna name para ser utilizada na url(url amigável). O Doctrine tem alguns behaviors que são incluídos no core como `Sluggable` e `Timestampable`, mas o sistema de behavior é feito para permitir que qualquer pessoa escreva novos behaviors para os modelos e serem reutilizados.

Agora que nós temos nossa base configurada e populada, vamos fazer alguns testes utilizando o admin generator para manipular os posts e tags do blog.

$ php symfony doctrine:init-admin frontend blog_posts BlogPost
$ php symfony doctrine:init-admin frontend tags Tag

Nota
> Os templates do admin generator para `sfDoctrinePlugin` ainda não foram totalmente atualizados para o symfony 1.1, então vamos precisar ativar a opção `compat_10` em `apps/frontend/config/settings.yml`. Eles vão ser atualizados antes do lançamento da versão estável do symfony 1.1.

Agora vamos abrir nosso browser e verificar a aplicação `frontend` e os módulos `blog_posts` e `tags`. Eles devem ser localizados numas urls parecida com essas


    http://localhost/symfony1.1Doctrine/web/frontend_dev.php/blog_posts
    http://localhost/symfony1.1Doctrine/web/frontend_dev.php/tags
   

Agora, com um pouco de configuração no admin generator do blog_post, nós podemos controlar o relacionamento entre blog_post e tags marcando checkboxes quando editando um post. Abra o arquivo `apps/frontend/modules/blog_posts/config/generator.yml` e troque o conteúdo pelo YAML abaixo:


    generator:
      class:              sfDoctrineAdminGenerator
      param:
        model_class:      BlogPost
        theme:            default
        list:
          display:        [=title, author]
          object_actions:
            _edit:        -
            _delete:      -
        edit:
          display:        [author, title, body, Tags]
          fields:
            author:
              type:       input_tag
            title:
              type:       input_tag
            body:
              type:       textarea_tag
              params:     size=50×10
            Tags:
              type:       doctrine_admin_check_list
              params:     through_class=BlogPostTag

   

Agora atualize (f5) seu browser para listar os posts do blog. Você vai ver tudo de uma maneira mais limpa. Edite um post clicando no ícone ou no título. Veja abaixo como você pode marcar as tags associadas ao post.

99% das ferramentas que você vê funcionando no Propel, você pode ver também no Doctrine. Então, é fácil entender e aplicar. O sfDoctrinePlugin implementa todas as funcionalidades que o sfPropelPlugin e algumas mais. Nos links abaixo você pode obter mais informação sobre o que o Doctrine suporta.

  • Behaviors – Easily create reusable behaviors for your Doctrine models.
  • Migrations – Deploy database schema changes to your production environment through a programmatic interface.
  • Doctrine Query Language – Build your database queries through a fluent OO interface
  • Validators – Turn on column validators for both database and code level validation.
  • Hierarchical Data – Turn your models in to nested sets easily with the flip of a switch.
  • Caching – Tune performance by caching your DQL query parsing and the result sets of queries.

Se esse pequeno tutorial despertou seu interesse no Doctrine, você pode encontrar mais informações do Doctrine abaixo e aprender um pouco mais sobre ele:

2008 07 15

doctrine
php
symfony

Comments (1)

Permalink

Gerando feeds rss com sfFeed2Plugin

Vou mostrar nesse post uma maneira que utilizo para gerar RSS de notícias publicadas.

Primeiramente, precisamos ter instalado o plugin sfFeed2Plugin

symfony plugin-install http://plugins.symfony-project.com/sfFeed2Plugin

Considere um schema.yml parecido com esse


propel:
  artigo:
    _attributes: { Artigo }
    id:
    titulo:     varchar(200)
    data:      date
    resumo:    varchar(200)
    texto:     longvarchar
    …
 

Estou usando também uma rota para os links de noticias. O apps/APLICACAO/config/routings.yml precisa ser configurado para isso. Essa rota será utilizada no link para o artigo.


noticiaver:
  url: /noticia/:id
  param: { module: noticias , action: ver }
 

Dentro do módulo noticias, vamos adicionar no apps/APLICACAO/modules/noticias/actions/actions.class.php


public function executeRss() {
      $feed = new sfAtom1Feed();

      $feed->initialize(array(
        ‘title’       => ‘RSS – Notícias’,
        ‘link’        => ‘http://www.link-do-titulo-do-rss.com.br/’
      ));

      // selecionando os artigos de 5 em 5
      $c = new Criteria;
      $c->addDescendingOrderByColumn(ArtigoPeer::DATA);
      $c->setLimit(5);
      $artigos = ArtigoPeer::doSelect($c);

      foreach ($artigos as $artigo)
      {
        $item = new sfFeedItem();
        $item->initialize(array(
          ‘title’       => $artigo->getTitulo(),
          ‘link’        => ‘@noticiaver?id=’.$artigo->getId(),        
          ‘pubDate’     => $artigo->getData("U"),
          ‘uniqueId’    => $artigo->getId(),
          ‘description’ => $artigo->getResumo(),
        ));

        $feed->addItem($item);
      }
      $this->feed = $feed;
      $this->setLayout(false);
  }
 

No template apps/APLICACAO/modules/noticias/templates/rssSuccess.php precisamos ter somente


<?php
decorate_with(false);
echo $feed->asXml();
 

Pronto. Você terá o RSS das notícias em um endereço parecido com esse, www.seusite.com.br/noticias/rss.

2008 07 08

RSS
php
symfony

Comments (2)

Permalink

Instalando plugins no symfony 1.1

No symfony 1.1, o sistema de plugins foi totalmente reescrito. Isto vai permitir melhoras no modo de trabalho e facilitar o uso no seu projeto.

Instalando um plugin

Para instalar plugins de um channel padrão (o oficial do symfony), não é mais necessário usar a URL toda. Basta:

$ php symfony plugin:install sfGuardPlugin

Isto irá instalar o plugin sfGuardPlugin. Entretanto, há mais opções disponíveis:

$ php symfony plugin:install —stability=beta sfGuardPlugin

Ele irá instalar a versão beta do plugin no seu projeto, o que é útil se você quiser testar uma versão mais recente, mas não é recomendável pois é uma versão non-stable (instável).

Você pode também especificar qual versão do plugin quer instalar:

$ php symfony plugin:install —release=1.0.0 sfGuardPlugin

Ele irá instalar a versão 1.0.0 do plugin.

Vários plugins são dependentes de outros para funcionar completamente. No symfony 1.0, você tinha que instalar uma série de plugins antes de poder instalar o plugin de sua escolha. No symfony 1.1, basta você digitar o comando a seguir, que irá instalar o plugin e suas dependências:

$ php symfony plugin-install install-deps sfGuardPlugin

Outra melhoria, graças à utilização de canais PEAR é a capacidade de utilização de diversos canais (channels) diferentes.
Por padrão, o symfony usa o channel oficial (plugins.symfony-project.org) que vai pelo nome de symfony-plugins (não precisa especificar na instalação do plugin). Para usar outros, primeiro adicione um novo:

$ php symfony plugin:add-channel custom-channel.example.com

Agora você pode instalar plugins vindo deste canal especificando na instalação:

$ php symfony plugin:install —channel=custom-channel.example.com sfGuardPlugin

Para saber mais parâmetros utilize o help:

$ php symfony help plugin:install

Também é possível fazer uma referência direta ao plugin que quer instalar, tanto usando a URL completa como um caminho local:

$ php symfony plugin:install http://www.example.com/sfGuardPlugin-1.0.0.tgz

ou

$ php symfony plugin:install /home/stefan/plugins/sfGuardPlugin-1.0.0.tgz

Desinstalando um plugin

Para desinstalar um plugin do seu projeto continua fácil. Um simples comando fará o truque:

$ php symfony plugin:uninstall sfGuardPlugin

Para desinstalar um plugin vindo de outro canal (channel), você precisa especificá-lo:

$ php symfony plugin:uninstall —channel=custom-channel.example.com sfGuardPlugin

Para saber qual canal o plugin está instalado, use o plugin:list.

Atualizando um plugin

Também é muito simples. Basta o comando a seguir, e seu plugin estará com a última versão:

$ php symfony plugin:upgrade sfGuardPlugin

Os parâmetros —stability, —release e —channel, também está disponível para esta tarefa e é aplicada do mesmo modo.

Listando os plugins instalados

A tarefa mais fácil de todas é listar os plugins instalados. Para isso, basta o comando:

$ php symfony plugin:list

Este comando não tem parâmetros.

Como você pode ver, a reescrita do sistema de plugins está mais poderosa e permite um gerenciamento mais fácil dos plugins.

—

Tutorial em inglês

Até mais.

2008 07 04

php
plugins
symfony

Comments (0)

Permalink

Enviando uma newsletter com Swift e Symfony

Olá! Nesse post vou mostrar uma maneira que utilizei para disparar uma newsletter com o Symfony utilizando o Swift . Atualmente esse processo funciona comigo para uma listagem de aprox. 10.000 emails.

Primeiramente, é preciso ter o Swift instalado. Eu utilizei o plugin sfSwiftPlugin

symfony plugin-install http://plugins.symfony-project.com/sfSwiftPlugin

Acesse a página do plugin para fazer os ajustes necessários

Com base num schema.yml:


propel:
  newsletter:
    _attributes:  { phpName: Newsletter }
    id:
    nome:         varchar(200)
    email:        varchar(200)
    ativo:        boolean
    created_at:
 

Geramos os modelos:

$ symfony propel-build-all

Vamos criar um batch que irá enviar nossa newsletter. Esse comando gera o arquivo `batch/newsletter.php`

$ symfony init-batch default newsletter frontend

Vamos editar o `batch/newsletter.php`


<?php

define(‘SF_ROOT_DIR’,    realpath(dirname(file).‘/..’));
define(‘SF_APP’,         ‘frontend’);
define(‘SF_ENVIRONMENT’, ‘prod’); // eu uso em prod.. por default vem dev
define(‘SF_DEBUG’,       1);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.‘apps’.DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.‘config’.DIRECTORY_SEPARATOR.‘config.php’);

// initialize database manager
$databaseManager = new sfDatabaseManager();
$databaseManager->initialize();

// batch process here

$body = "Conteúdo do email…";

$smtp = new Swift_Connection_SMTP("mail.servidor.com", 25);
$smtp->setUsername("email@servidor.com");
$smtp->setpassword("senha");
$smtp->setTimeout(60);
$swift = new Swift($smtp);

$message = new Swift_Message("Título da Newsletter", $body , "text/html" , "utf-8");        
$message->setReturnPath("bounces@servidor.com"); // o return-path é bom para pegar os bounces

// criamos a lista de emails que receberão a newsletter
$recipients = new Swift_RecipientList();

// selecionando todos os assinantes ativos
$c = new Criteria();
$c->add(NewsletterPeer::ATIVO , true);
$assinantes = NewsletterPeer::doSelect($c);

// preenchendo a lista de recipientes
foreach($assinantes as $assinante) {
    $recipients->addTo($assinante->getEmail());
}

// esse plugin do Swift é muito util
$swift->attachPlugin(new Swift_Plugin_AntiFlood(200), "anti-flood");

$batch = new Swift_BatchMailer($swift);
$batch->setMaxTries(2); // nmro max de tentativas
$batch->setMaxSuccessiveFailures(2); // nmro max de falhas

$batch->send($message, $recipients, new Swift_Address("email_from@servidor.com" , "Título Newsletter"));  

$swift->disconnect();

Para fazer o envio execute o arquivo dentro da pasta `batch/`

$ php newsletter.php

Se você for fazer um disparo que leve muito tempo, é aconselhável colocar o script para ser executado em background com batch ou at

$ at -f php newsletter.php now

Em um post futuro eu mostro como fazer tudo isso sem utilizar linha de comando, ou seja executar uma action via web para executar o script e/ou colocar em background at.

2008 07 02

php
swift
symfony

Comments (0)

Permalink

As 20 funções mais utilizadas no Symfony

Um site japonês elaborou uma estatística interessante sobre as funções mais utilizadas no código fonte dos frameworks para PHP.

No caso do Symfony, as 20 funções PHP mais utilizadas são:

  • array (3.534 vezes)
  • isset (1.083 vezes)
  • sprintf (729 vezes)
  • count (515 vezes)
  • substr (372 vezes)
  • strlen (256 vezes)
  • is_null (230 vezes)
  • is_array (229 vezes)
  • dirname (218 vezes)
  • empty (213 vezes)
  • strpos (204 vezes)
  • unset (201 vezes)
  • array_merge (198 vezes)
  • in_array (164 vezes)
  • str_replace (156 vezes)
  • strtolower (155 vezes)
  • preg_match (150 vezes)
  • date (134 vezes)
  • implode (133 vezes)
  • preg_replace (124 vezes)

No caso do CakePHP as 5 mais utilizadas são:

  • array (16.645 vezes)
  • in_array (1.519 vezes)
  • isset (1.151 vezes)
  • empty (889 vezes)
  • is_array (486 vezes)

A cinco mais utilizadas pelo Zend Framework são:

  • array (8.686 vezes)
  • isset (1.528 vezes)
  • couny (1.407 vezes)
  • dirname (999 vezes)
  • is_array (789 vezes)

Esses resultados devem ter vindo a partir de alguns grep`s nas pastas core dos frameworks…

Tendo em vista os resultados, se nas próximas versões do PHP tivermos rendimentos nas funções array() e isset(), consequentemente a performance desses frameworks e aplicações tendem a melhorar.

Ref: http://www.symfony.es/2008/06/18/las-20-funciones-php-mas-utilizadas-por-symfony

2008 06 27

php
symfony

Comments (0)

Permalink

Gerenciando aplicações em produção (Profiling production)

Neste post irei mostrar como fazer para ter um feedback automático das aplicações quando elas já estiverem em produção. A intenção é detectar anormalidades na execução de um script e/ou saber um pouco mais do andamento da aplicação. Neste caso é estabelecido um tempo máximo para a execução de uma action, caso ela demore mais que esse tempo, um email é enviado para o administrador e um arquivo de log específico é criado.

Para executar essa tarefa vamos utilizar os filters do symfony.
Por padrão o tempo de execução é de 200ms, mas isso pode ser configurado no arquivo app.yml

Vamos criar o arquivo app.yml:


all:
  log_slow_requests:
    status: on
    tempo: 200
 

Vamos criar o arquivo logSlowRequestsFilter.php na pasta lib/:


<?php
class myFilter extends sfFilter
{
  public function execute ($filterChain)
  {
    $timer = sfTimerManager::getTimer(‘slow_request’);
    $filterChain->execute();

    // pegamos o tempo de execucao
    $elapsedTimeMs = $timer->getElapsedTime() * 1000;

    if (($elapsedTimeMs >= sfConfig::get(‘app_log_slow_requests_tempo’, 200)) && (sfConfig::get(‘app_log_slow_requests_status’) == "on")) {
        $logfile = sfConfig::get(‘sf_log_dir’) . ‘/slow_requests.log’;
   
        // vamos logar a URL e o tempo de execucao
        $text = sprintf("[%s Tempo: %.2f ms] %s – %s", date(‘Y-m-d H:m’) , $elapsedTimeMs, sfRouting::getInstance()->getCurrentInternalUri(true), sfRouting::getInstance()->getCurrentInternalUri());
   
        // escrevendo no log
        file_put_contents($logfile, $text . "\n", FILE_APPEND);

        // essa é uma classe de email personalizada.. use seu metodo para o envio do email
        Email::enviar("[slowRequest] Cliente" , "Um script demorou mais que o tempo de execucao estipulado. <br/ >O log foi gravado." , "to@email.com");
        // cuidado ao utilizar a linha acima porque pode sobrecarregar o servidor
    }
    else
    {
      $filterChain->execute();
    }
  }
}
 

Vamos adicionar o novo filtro no myapp/config/filters.yml:


rendering: ~
web_debug: ~
security:  ~

slow_requests:
  class: myFilter

cache:     ~
common:    ~
flash:     ~
execution: ~
 

Limpe o cache!

$ symfony cc

Pronto! O arquivo `log/slow_requests.log` será atualizado sempre que um script passar do tempo estipulado. Faça uns testes diminuindo o valor no yml (200).

Você terá um arquivo mais ou menos assim…

$ more log/slow_requests.log
[2008-06-20 Tempo: 292.67 ms] @default_index – modulo/index
$

Atualmente estou com a linha que envia email comentada e um script na crontab que faz o envio do log para meu email toda semana.. Isso foi bom para reduziu um pouco a carga no servidor..

Esse é o meu script..

$ more slow_request.sh
#!/bin/bash
mail -s “[Cliente] slow_request.log” to@email.com < ../../log/slow_requests.log
$

Saiba como utilizar a crontab…

Adaptado de http://groups.google.com/group/symfony-users/browse_thread/thread/535b264eb31cf4ac

2008 06 20

log
php
producao
symfony
yml

Comments (0)

Permalink

Symfony 1.1 Command Line Interface (CLI)

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 mostra algumas dessas tarefas com detalhes, enquanto este cookbook descreve todas elas com uma breve descrição.

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 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.

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

Estrutura da tarefa generate

$ 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

Gerando os Models

$ 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

Manipulando o Schema

$ 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

Manipulando dados

$ 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

Ferramentas de desenvolvimento

$ 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 )

$ 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 )

Testes

$ 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

Administração de projetos

$ 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)

Geração de Esqueleto e Admin

$ 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

Manipulando plugins

$ 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

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:

Traduzido por Pedro Casado

2008 06 19

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.

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.

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’))

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).

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 150×150px 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.

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

2008 06 16

ajax
schema
symfony

Comments (1)

Permalink

« Older posts
Newer posts »