Development

sfBookPT-brProjCreation

You must first sign up to be able to contribute.

Version 22 (modified by hpoyatos, 11 years ago)
--

Criação de Projeto e o comando "symfony"

Resumo

Este capítulo descreve a estrutura lógica do projeto Symfony, e detalhes do uso do comando "symfony" para iniciar uma estrutura de projeto

Introdução

No symfony, um projeto é um conjunto de serviços e operações disponíveis através de um dado domínio, compartilhando um mesmo modelo de objetos.

Dentro de um projeto, as operações são agrupadas de maneira lógica dentro dos aplicativos; um aplicativo normalmente pode rodar independentemente de outros aplicativos em um mesmo projeto.

Na maioria dos casos, um projeto deve conter duas aplicações, um de front-office, e a outra de back-office, compartilhando o mesmo banco de dados. Mas você pode ter também um projeto contendo vários mini-sites, cada site servindo para uma aplicação diferente. Note que os links entre aplicações deve ser em um formato de caminho absoluto.

Cada aplicação é um conjunto de um ou mais módulos, cada módulo possuindo um funcionalidade em particular. Um módulo normalmente representa um página ou um grupo de páginas com um próposito similar. Exemplos: "home", artigos, ajuda, carrinhos de compra, financeiros, etc.

Módulos possuem ações. Elas representam as várias ações que podem ser realizadas por um módulo. Por exemplo, um módulo de carrinho de compras pode ter ações como inserir, mostrar e atualizar. Lidar com ações é quase como lidar com as páginas de uma aplicação web clássica.

Se isso representar muitos passos para um projeto iniciante, é muito fácil agrupar todas as ações em um único módulo, então a estrutura de arquivos pode ser mantida simples. Quando a aplicação se tornar mais complexa, você terá tempo para organizar ações em módulos lógicos.

Um aplicação pode rodar em vários ambientes para usar, por exemplo, diferentes configurações ou banco de dados. Por padrão, toda nova aplicação pode rodar em três ambientes (desenvolvimento, teste e produção). Um aplicação pode ter quantos ambientes precisar. A diferença entre os ambientes é sua configuração.

Por exemplo, o ambiente de testes pode logar alertas e erros, enquanto o ambiente de produção loga apenas erros. A aceleração de cache é sempre desativada em um ambiente de desenvolvimento mas ativa nos ambientes de teste e produção. O ambiente de desenvolvimento e testes pode possuir dados de teste, armazenados em um banco de dados distinto do banco de dados produção. Todos os ambientes podem viver juntos em uma mesma máquina, embora o servidor de produção geralmente contenha apenas um ambiente de produção.

http://www.symfony-project.com/images/bubble.gif Nota: Se você usa o symfony como um sandbox, você não precisa configurar o projeto nem uma aplicação, já que o sandbox já possui um projeto 'sf_sandbox' e uma aplicação 'frontend'. Você tampouco precisa configurar o servidor web, já que sua aplicação está no diretório raiz "web/ ".

Pake

Symfony utiliza um ferramenta dedicada chamada Pake to administrar projetos, aplicações e módulos. Pake é uma ferramenta php similar ao comando Rake, um espécie de "make" feito em Ruby. Ele automatiza algumas tarefas de administração de acordo com um arquivo de configuração específico chamado pakefile.php. Mas uma vez que você use a ferramenta pake através do comando symfony em linha de comando, tudo se torna mais simples do que parece.

Para ter a lista completa das operações administrativas disponíveis, simplesmente digite em seu diretório de projeto:

$ symfony -T

A descrição das tarefas CLI usadas durante o estágio inicial do projeto será disposta. Uma referência completa das tarefas pode ser encontrada no capítulo CLI.

Setup do Projeto

Primeiramente, você deve criar o diretório que conterá todos os arquivos de projeto:

$ mkdir /home/steve/myproject

Então, para iniciar o projeto e gerar os arquivos básicos e diretórios necessários do runtime, digite:

$ cd /home/steve/myproject
$ symfony init-project myproject

Esta é uma reprodução da estrutura de arquivos criada:

apps/
batch/
cache/
config/
data/
doc/
lib/
log/
test/
web/

http://www.symfony-project.com/images/bubble.gif Nota: Se você possuir necessidades específicas para seu projeto, symfony permite customizar qualquer arquivo desta estrutura. Todos os caminhos dos scripts do symfony utilizam um conjunto de parâmetros especiais definidos em um arquivo chamado constants.php, que pode ser customizado como descrito no capítulo de estrutura de arquivos.

O comando symfony deve sempre ser executado do diretório raiz do projeto (myproject/ no caso do exemplo acima), porque todas as tarefas realizadas por esse comando devem ser de um projeto específico. Se ele for executado de um dos subdiretórios do projeto, o comando retornará um erro.

Setup da Aplicação

O projeto ainda não está pronto para ser visto; ele necessidade de pelo menos uma aplicação. Para iniciar isso, use o comando de init-app do comando symfony e informe o nome da aplicação como um argumento:

$ symfony init-app myapp

Este comando criará um diretório myapp na pasta apps/ do do seu projeto, com uma configuração padrão e um conjunto de diretório prontos para hospedar arquivos do seu website:

apps/
  myapp/
    config/
    i18n/
    lib/
    modules/
    templates/

Alguns arquivos php que correspondem ao controlador frontal serão criados para cada ambiente padrão em seus diretórios raiz:

web/
  index.php
  myapp_dev.php

index.php é o controlador frontal de produção de uma nova aplicação. Por ter sido criado como sendo a primeira aplicação de um projeto, Symfony criou um arquivo chamado index.php ao invés de myapp.php (se você inserir agora uma nova aplicação chamada mynewapp, o novo controlador funciona será chamado de mynewapp.php). Para rodar uma aplicação em ambiente de desenvolvimento, use o controlador frontal myapp_dev.php.

http://www.symfony-project.com/images/bubble.gif Nota: Se você ler atentamente à introdução, pode estar se perguntando onde o arquivo myapp_test.php está localizado. Pra dizer a verdade, o ambiente de testes é usado na unidade de testes realizando testes de componentes das aplicações, não necessitando de um controlador frontal. Leia ao capítulo de unidade de testes para aprender mais a respeito.

De agora por diante, o diretório /home/steve/myproject/ será considerado a raiz de seu projeto. O caminho raiz é armazenado em uma constante chamada SF_ROOT_DIR, definida no arquivo index.php, e nós faremos uso deste nome ao invés de usar o caminho real, evitando confusões com leitores que não se chamem Steve.

Setup do Servidor Web

Para possibilitar o acesso e testes da nova aplicação, o servidor web deve ser configurado. Eis aqui um exemplo para Apache, onde o novo VirtualHost é adicionado do arquivo httpd.conf:

<Directory "/$data_dir/symfony/web/sf">
  AllowOverride All
  Allow from All
</Directory>
<VirtualHost *:80>
  ServerName myapp.example.com
  DocumentRoot "/home/steve/myproject/web"
  DirectoryIndex index.php
  Alias /sf /$data_dir/symfony/web/sf

  <Directory "/home/steve/myproject/web">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

http://www.symfony-project.com/images/bubble.gif Nota: Na configuração acima, As variáveis $data_dir devem ser substituídas pelo diretório de dados de seu PEAR. Por exemplo, para *nix, você deverá digitar:

    Alias /sf /usr/local/lib/php/data/symfony/web/sf

Você pode obter mais informações sobre diretórios PEAR no capítulo de instalação.

Reinicie o Apache, e é isso: Sua mais nova aplicação pode agora ser chamada e visualizada através de um navegador padrão utilizando a url:

http://myapp.example.com/index.php/

ou, em modo debug:

http://myapp.example.com/myapp_dev.php/

http://www.symfony-project.com/images/bubble.gif Nota: Symfony utiliza o módulo mod_rewrite para disponibilizar urls customizáveis. Se sua versão do apache não estiver compilada com mod_rewrite, verifique se você não possui o DSO mod_rewrite instalado nas seguintes linhas do seu httpd.conf:

    AddModule mod_rewrite.c
    LoadModule rewrite_module modules/mod_rewrite.so

Você aprenderá mais sobre urls customizáveis no capítulo de roteamento.

Symfony é compatível com outras configurações de servidores. Você pode, para exemplo, acessar uma aplicação symfony utilizando um alias ao invés de um virtual host. Para descobrir mais a respeito de configuração de servidores web, consulte o capítulo relacionado.

Setup do Módulo

Sua nova aplicação não é muito impressionante; precisa desesperadamente de funcionalidades. Se você quer funcionalidades, você precisa de um módulo para colocar isso dentro. Uma vez mais, o comando symfony será usado para isso, com um parâmetro chamado init-module, o nome da aplicação e do novo módulo:

$ symfony init-module myapp mymodule

A árvore estrutural criada será:

modules/
  mymodule/
    actions/
    config/
    lib/
    templates/
    validate/

O novo módulo está pronta para ser usado:

http://myapp.example.com/index.php/mymodule

Uma vez que você precisa de um início para o módulo funcionar imediatamente, edite o arquivo myapp/modules/mymodule/templates/indexSuccess.php e digite nele:

Hello, world !

Salve, atualize a página em seu navegador e "voilà"!

Versões de código fonte

Estamos a configuração da aplicação em ordem, é recomentado começar o processo de controle de versões do código fonte. Symfony tem suporte nativo ao CVS, embora o uso do Subversion seja mais recomendado. Os exemplos a seguir mostrando comandos para Subversion, e tomando o presuposto que você já possui um servidor Subversion instalado e que você deseje criar um novo repositório para este projeto. Para usuários Windows, recomendamos um cliente Subversion chamado TortoiseSVN. Para maiores informações à respeito de controle de versões e dos comandos mostrados aqui, por favor consulta a documentação do Subversion.

O exemplo abaixo assume que $SVNREP_DIR foi definido com um variável de ambiente. Se você não quiser definí-la, deverá então substituir o localização atual para o repositório no luigar de $SVNREP_DIR.

Então vamos criar um novo repositório para o projeto myproject:

$ svnadmin create $SVNREP_DIR/myproject

Então a base estrutural (layout) do repositório deve ser criada com os diretórios de trunk, tags e branches, usando este comando bem comprido:

$ svn mkdir -m "layout creation" file:///$SVNREP_DIR/myproject/trunk file:///$SVNREP_DIR/myproject/tags file:///$SVNREP_DIR/myproject/branches

Está será sua primeira revisão. Agora você terá que importar todos os arquivos de seu projeto, exceto os arquivos temporários de cache e log:

$ cd /home/steve/myproject
$ rm -rf cache/*
$ rm -rf log/*
$ svn import -m "initial import" . file:///$SVNREP_DIR/myproject/trunk

Verifique os arquivos 'commitados' e digite

$ svn ls file:///$SVNREP_DIR/myproject/trunk/

Parece bom. Agora o repositório SVN possui uma versão de referência (e de histórico) para todos os arquivos de seu projeto. Isso significa que os arquivos localizados atualmente no diretório /home/steve/myproject precisam ser referenciados no repositório. Para fazer isso, primeiro renomeie o diretório myproject - você irá apagá-lo assim que tudo estiver funcionando bem - e realizar o checkout do repositório dentro do novo diretório:

$ cd /home/steve
$ mv myproject myproject.origin
$ svn co file:///$SVNREP_DIR/myproject/trunk myproject
$ ls myproject

E é isso. Agora você pode trabalhar nos arquivos localizados em /home/steve/myproject/ e "comittar" suas modificações para o repositório. Não se esqueça de realizar alguma limpeza, apagando o diretório myproject.origin, que é de agora por diante inútil.

Há mais alguma coisa a se configurar. Se você "commitar" seu diretório de trabalho para o repositório, você pode acabar copiando alguns arquivos indesejáveis, como alguns localizados nos diretórios de cache e log do seu projeto. Então você precisa montar uma ignore list para o svn usar neste projeto. Você deve também configurar acesso total para o diretórios de cache/ e log/ novamente - SVN não armazena permissões de acesso:

$ cd /home/steve/myproject
$ svn propedit svn:ignore .
$ chmod 777 cache
$ chmod 777 log

O editor de textos padrão configurado no SVN deverá abrir. Se isso não acontecer, faça com que o subversion use seu editor preferido digitando:

$ export SVN_EDITOR=<name of editor>
$ svn propedit svn:ignore .

Agora simplesmente insira os subdiretórios de myprojet que o SVN deverá ignorar no momento do commit:

cache
log

Salve e saia. Terminamos !