Symfony Framework: formulários, validação e sessão

Conhecendo melhor - Apresentação

Boas-vindas à Alura! Sou Vinicius Dias, guiarei vocês neste treinamento em que conheceremos mais sobre o framework Symfony.

Neste curso, aprenderemos sobre o Symfony Flex e como ele já tem nos ajudado, mesmo que não soubéssemos. Também vamos explorar a debug toolbar (a barra inferior que o Symfony disponibiliza no navegador) e descobrir o que cada um de seus elementos significa, aprendendo a interpretá-los e atentando às suas utilidades no desenvolvimento de aplicações.

Estudaremos um novo método para nos referir a rotas — em vez de utilizar a URL completa, daremos nomes a elas. Na sequência, começaremos a adicionar funcionalidades, como a remoção das séries cadastradas. Complementarmente, vamos aprimorar as mensagens exibidas ao usuário quando ações são realizadas com sucesso no sistema, utilizando sessões e flash messages, por exemplo.

Também estudaremos novas formas de lidar com formulários, trabalhando com validação de dados tanto no front-end quanto no back-end. O intuito é efetuar esses processos automaticamente, de modo que o Symfony entregue os resultados prontos para nós.

Espero que você aproveite bastante este treinamento. Caso surjam dúvidas, não hesite em abrir um tópico no fórum! Sempre que possível, respondo às questões pessoalmente, mas temos uma enorme comunidade de alunos, moderadores e instrutores preparados para te ajudar. Também não deixe de entrar no servidor do Discord da Alura, onde a interação é mais direta.

No próximo vídeo, começaremos a entender o que é Symfony Flex.

Conhecendo melhor - Symfony Flex

No treinamento anterior, escrevemos bastante código e finalizamos o curso com nosso projeto funcionando. Agora, vamos pausar o desenvolvimento do código e nos aprofundar no funcionamento do framework.

Instalando o Symfony

Como comentamos anteriormente, há duas maneiras de instalar o Symfony. A primeira é uma forma reduzida, usada normalmente para criar APIs, microsserviços ou componentes que são comandos da linha de comando (em vez de uma aplicação Web). A segunda forma é a que fizemos: criando uma aplicaçõs full-stack.

Na prática, a diferença está na quantidade de componentes. A instalação reduzida vem com menos componentes do Symfony — o framework em si, o componente de rotas e algumas funcionalidades de log, basicamente. Se precisarmos do Doctrine para acessar o banco de dados, ou do Twig para trabalhar com views, ou do Monolog para obter logs mais complexos, temos que instalá-los.

A instalação completa já vem com todos esses componentes instalados, inclusive alguns que nem utilizaremos neste curso (porém, já estão prontos e configurados para uso).

Por isso, na pasta "config > packages" do nosso projeto, temos tantos elementos, como um pacote de cache (cache.yaml), o Doctrine e o Doctrine Migrations (doctrine.yaml e doctrine_migrations.yaml), componentes de envio de e-mail (mailer.yaml) e que lidam com mensagens (messenger.yaml), bem como o Monolog (monolog.yaml), entre outros.

Symfony Flex

Vamos imaginar que fizemos a instalação reduzida. Para instalar o Doctrine, por exemplo, não precisaríamos executar composer require doctrine/doctrine na linha de comando e depois instalar alguma configuração que una o Doctrine ao Symfony. Diferentemente disso, poderíamos apenas rodar composer require orm.

O orm não é o nome de nenhum pacote conhecido pelo Composer, então de onde ele vem? É neste momento que conhecemos o Symfony Flex, um plugin do Composer, incluso na instalação do Symfony (também na forma reduzida).

O Symfony Flex adiciona alguns "super poderes", algumas funcionalidades ao Composer, como apelidos para pacotes. O orm é um apelido para o componente que liga o Doctrine ao Symfony. Outros exemplos de apelidos são view e log, que instalam o Twig e o Monolog, respectivamente. Em outras palavras, se esquecermos qual é o componente, não tem problema. Basta usar esses apelidos. Sendo assim, a instalação de pacotes que não vieram por padrão fica mais fácil.

Além disso, esse plugin executa alguns comandos. Por exemplo, quando instalamos o Doctrine, ele já traz os arquivos de configuração, como o doctrine.yaml que estudamos anteriormente.

O Symfony Flex também configura o bundle. Na pasta "config", ao abrir o arquivo bundles.php, notaremos que já temos diversos bundles instalados, pois realizamos a instalação completa. Contudo, se tivéssemos feito a instalação mínima, esse arquivo estaria quase vazio, provavelmente apenas com o FrameworkBundle (linha 4):

Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true]

Quando executássemos o comando composer require orm, além de instalar o Doctrine, o Symfony Flex também adicionaria o DoctrineBundle (linha 5):

Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true]

Entendendo bundles do Doctrine

Um bundle é como um módulo, qualquer pedaço de código que será executado pelo framework e que pode conter configurações, controllers ou views, entre outros.

A título de exemplo, podemos acessar nossa aplicação no navegador (http://localhost:8123) sem o /series ao final do endereço e teremos a página de boas-vindas do Symfony 6.1.1. Essa view é criada pelo FrameworkBundle. Ou seja, já temos elementos que são trazidos por um bundle do Symfony.

Para facilitar, neste curso chamaremos os bundles de módulos.

Resumidamente, o FrameworkBundle vem instalado por padrão e podemos ter diversos outros módulos, como o DoctrineBundle, o TwigBundle, o SecurityBundle, o MonologBundle e o MakerBundle.

No curso anterior, criamos uma entidade diretamente da linha de comando: escrevemos o nome da propriedade, a definimos como uma string e foram gerados uma entidade e um repositório. Esse processo foi realizado pelo MakerBundle, um módulo do Symfony que nos ajuda a desenvolver código. Ele está ativo somente no ambiente de desenvolvimento, como indicado pelo trecho ['dev => true'] da linha 14:

Symfony\Bundle\MakerBundle\MakerBundle::class => ['dev' => true]

O Doctrine (linha 5), por outro lado, está ativo em todos os ambientes:

Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true]

E o WebProfiler (linha 9) está ativo nos ambientes de dev e de test:

Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true),

Se tivéssemos um bundle de otimização de queires, poderíamos ativá-lo somente em ambiente de produção com ['prod' => true], por exemplo. Dessa forma, conseguimos configurar bundles para funcionarem em determinados ambientes.

Recapitulando

O Symfony (mesmo em sua instalação mais simples) conta com um plugin que traz algumas funcionalidades extras ao Composer. Algumas delas são: ter apelidos para pacotes que o Symfony já conhece e inserir código no nosso projeto. Quando instalamos um pacote que o Symfony Flex conhece, ele pode criar arquivos de configuração e adicionar bundles, por exemplo.

Os bundles são como módulos que podem ter configurações, controllers, views, entre outros. Vale lembrar que o FrameworkBundle contém a configuração principal para o Symfony começar a funcionar.

Dessa forma, temos uma visão geral do framework para fazer tudo funcionar adequadamente. Se algum dia quisermos instalar um bundle que é não suportado oficialmente pelo Symfony e precisarmos manipular configurações do bundle, já temos uma ideia geral de como tudo funciona, por isso, é importante entendermos como essas ferramentas atuam.

A classe Kernel

Por fim, vamos atentar a um arquivo que veio por padrão na nossa instalação, o Kernel.php (traduzido como "núcleo"). Podemos escrever código nesse núcleo do nosso framework para configurar a instalação. Além disso, ele estende um BaseKernel (núcleo de base), que vem de um componente chamado HttpKernel (núcleo HTTP).

A classe Kernel fará com que tudo relativo ao Symfony funcione. Ela será responsável por pegar requisições, devolver respostas, emitir eventos do Symfony, chamar o controller, decidir qual rotas utilizar, entre outras funções. O Kernel também tem a lista de bundles. Ele utiliza o arquivo bundles.php para carregar todos os bundles e, a partir disso, fazer com que tudo funcione devidamente.

No próximo vídeo, conheceremos a debug bar, um componente padrão do Symfony que aparece na parte inferior do navegador.

Conhecendo melhor - Debug toolbar

No vídeo anterior, entendemos o que é o Symfony Flex e o que são os bundles do Symfony. Agora, exploraremos a debug toolbar, a barra disponibilizada pelo framework na parte inferior do navegador, que nos traz diversas informações sobre a instalação do Symfony e sobre a requisição atual.

Para visualizá-la, vamos acessar nossa aplicação sem o /series ao final do endereço (http://localhost:8123), o que nos levará à página de boas-vindas do Symfony 6.1.1. Da esquerda para a direita, na debug toolbar, temos o status da resposta (no caso, 404, de "Não encontrado", com o fundo vermelho), o tempo de processamento e a quantidade de memória alocada, entre outras informações.

Em vez de fazer o debug da rota atual (que sabemos que não existe), vamos acessar http://localhost:8123/series. Note que a debug toolbar continua aparecendo, mesmo que não tenhamos inserido nenhum código para exibi-la, porque, no TwigBundle, temos uma configuração para mostrar essa barra. Além disso, o bundle da toolbar conversa com o bundle do Twig de modo que, se estamos usando o Twig, temos a debug toolbar configurada.

Isso não quer dizer que não podemos usar a debug toolbar sem o Twig! Podemos utilizá-la inclusive em projetos que não são Symfony, basta adicionar algumas configurações.

Dados da requisição

Na debug toolbar, o primeiro item à esquerda é o status da resposta. No caso, temos status 200, com o fundo verde. Vamos clicar sobre esse elemento para trazer os dados da requisição em uma nova aba, no Symfony Profiler.

Na lateral esquerda, há um menu com a lista de painéis à disposição. De início, vamos continuar no painel "Request/Response", a primeira opção. Nessa página, é possível checar qual método de que controller foi executado (SeriesController :: seriesList). Em seguida, temos algumas abas pelas quais podemos alternar: "Request", "Response", "Cookies", "Session", "Flashes" e "Server Parameters". Por ora, continuaremos na aba "Request".

No tópico "GET Parameters", temos a lista de parâmetros. No nosso caso, não há nenhum. Então, a título de testes, vamos passar um parâmetro chamado teste:

http://localhost:8123/series?teste=valor

Ao acessar o Symfony Profiler novamente, agora teremos um parâmetro GET cuja chave é teste e o valor é valor. O mesmo serviria para parâmetros POST e arquivos enviados, respectivamente nos tópicos "POST Parameters" e "Uploaded Files".

Na sequência, temos o tópico "Request Attributes" (atributos da requisição), que não são parâmetros enviados pelo usuário, mas atributos das nossas configurações. Por exemplo, o controller executado, detalhes de segurança, o nome da rota, entre outras informações.

A seguir, há o tópico "Request headers" (cabeçalhos da requisição), onde podemos verificar detalhes do cabeçalho. Por fim, no tópico "Request Content", temos o conteúdo da requisição. No caso, não temos nada também.

Dados da resposta, cookies e parâmetros do servidor

Assim como avaliamos dados da requisição, podemos avaliar dados da resposta. Voltando ao topo da página, vamos alternar da aba "Request" para "Response". No nosso caso, além do corpo da resposta (que não precisamos da debug toolbar para visualizar), podemos verificar os cabeçalhos.

Na aba "Cookies", temos dados de cookies transferidos. No caso, temos cookies da nossa própria máquina, cookies do PhpStorm, entre outros.

Na aba "Server Parameters", temos os parâmetros do servidor, como variáveis de ambientes. Por exemplo, temos a variável DATABASE_URL, em que armazenamos a configuração do banco de dados. Tudo que está contido na variável$_SERVER pode ser encontrado nessa página.

Performance

Na debug toolbar, à direita do status da resposta, a próxima seção são informações de performance. Vamos clicar sobre os milissegundos para verificar mais dados, no Symfony Profiler.

No menu à esquerda, vamos acessar o painel "Performance" (a segunda opção). Nessa página, podemos verificar o tempo total de execução da requisição e o tempo de inicialização do Symfony. No meu caso, dos 88 milissegundos totais, 35 milissegundos são referentes ao Symfony — ele é bem rápido!

Além disso, também temos o pico de uso de memória que todo o código precisou. No meu caso, 22 MB. Como estamos no ambiente de desenvolvimento, poderíamos melhorar algumas configurações, mas, por enquanto, 22 MB está bom.

Na sequência, temos uma timeline (linha do tempo), exibindo a ordem dos eventos. Primeiramente, há uma legenda de cores:

cinza escuro: default
cinza claro: section
azul claro: event_listener
verde claro: template
vermelho: doctrine

Por exemplo, no topo à esquerda, em cinza claro, temos os dados chegando ao kernel (kernel_request 3.8ms / 22 MB). Logo abaixo, em azul claro, temos as rotas sendo configuradas (RouterListener 1.9 ms / 22MB). Mais abaixo, no centro da timeline, em cinza claro, temos o controller (controller 12 ms / 22MB). Por fim, na parte inferior direita, em azul claro, temos a exibição da debug toolbar (WebDebugToolbarListener 2.9 ms / 22MB).

Vale ressaltar que, clicando nas legendas, é possível filtrar alguns resultados.

No treinamento de XDebug, aprendemos sobre profiling. Podemos unir nossos conhecimentos de profiling com XDebug ou Blackfire, por exemplo, com informações trazidas pela debug toolbar!

Os logs

Na debug toolbar, à direita dos dados de perfomance, a próxima seção são informações relativas aos logs — no caso, temos dois logs sendo exibidos. Vamos analisá-los no Symfony Profiler. No menu à esquerda, acessaremos o painel "Logs".

Nessa página, podemos alternar entre as abas "All messages" (todas as mensagens), "Errors" (erros) e "Deprecations" (descontinuações). Além disso, é possível filtrar os resultados por nível — veremos essa opção mais mais adiante.

Acessando a aba "Deprecations", teremos duas informações:

se instalarmos a extensão "intl", nossa perfomance melhoraria
a forma de realizar as queries será alterada em uma versão futura do Doctrine (já comentamos sobre esse assunto no treinamento de Doctrine)

Não precisamos nos preocupar com essa segunda informação, pois, quando o Doctrine 3 for lançado, o Symfony já atualizará o que for necessário.

Para checar logs de erros, podemos acessar a aba "Errors" (no caso, não temos erros). Para checar todos os logs, inclusive os de debug, podemos abrir a aba "All messages".

Ao clicar no botão "Level" (à direita da aba "Deprecations"), é possível filtrar por níveis de log. Entre as opções, temos: "Debug", "Info", "Notice", "Warning", "Error", "Critical", "Alert" e "Emergency".

Detalhes de cache e de segurança

Voltando à debug toolbar, a próxima seção são detalhes de cache. No menu à esquerda do Symfony Profiler, acessaremos o painel "Cache".

Nessa página, constatamos que já existem alguns detalhes de cache configurados (mesmo que não tenhamos feito nada nesse sentido). Sob o tópico "Pools", clicando na opção "cache.annotations", por exemplo, saberemos que há cache de annotations sendo consumidos. Ou seja, o Symfony vem configurado para "cachear" as configurações de rotas feitas por attributes.

Na debug toolbar, a próxima seção são os detalhes de segurança. Como não temos a autenticação configurada ainda, ao posicionar o mouse sobre essa seção, saberemos que não estamos autenticados ("Authenticated: No").

Twig

A próxima seção da debug toolbar são detalhes sobre o Twig. No Symfony Profiler, no menu à esquerda, vamos acessar o painel "Twig".

Nessa página, sob o tópico "Twig Metrics", teremos informações como quanto tempo o Twig levou para renderizar o template e quantas chamadas de templates foram realizadas.

No tópico "Rendered Templates", temos mais detalhes, por causa do WebProfiler. Já no tópico "Rendering Call Graph", há o gráfico de execução.

Doctrine e migrations

A próxima seção da debug toolbar são detalhes do Doctrine. Posicionando o mouse sobre ela, saberemos quantas queries foram utilizadas, em quantos statements diferentes, quanto tempo esse processo levou, se o cache de segundo nível do Doctrine está habilitado e assim por diante.

No Symfony Profiler, no menu à esquerda, vamos acessar o painel "Doctrine". Nessa página, conseguimos visualizar a lista de queries (no caso, temos apenas uma):

SELECT t0.id AS id_1, t0.name AS name_2 FROM series t0

Clicando na opção "View formatted query", podemos visualizá-la de maneira formatada:

SELECT
    t0.id AS id_1,
    t0.name AS name_2
FROM
    series t0

Essa funcionalidade é bastante útil para queries longas e mais difíceis de interpretar. Também temos as opções "View runnable query" e "Explain query", com as quais poderíamos verificar os parâmetros e a performance.

Na sequência, temos informações de database connections (conexões) e entity managers. Além disso, constatamos que o second level cache não está habilitado — comentamos sobre esse assunto no treinamento de Doctrine, as configurações apareceriam nessa página. Por fim, temos o tópico de mapeamento de entidades.

No painel à esquerda, acessando o painel "Migrations", temos informações sobre as migrations que foram executadas, bem como quaisquer outras que estiverem faltando.

Configurações do Symfony

Por fim, no canto direito da debug toolbar, temos as configurações do Symfony. Essa seção não diz respeito à requisição atual, mas ao framework. No Symfony Profiler, vamos acessar o painel "Configuration".

Nessa página, saberemos que estamos usando uma versão estável, que o OPcache está desabilitado (o que não faz mal, pois estamos em ambiente de desenvolvimento), bem como a versão do PHP, a timezone configurada, a arquitetura do sistema e uma lista dos bundles habilitados. Podemos, inclusive, clicar sobre o nome de um dos arquivos para abri-lo.

Considerações finais

Em suma, a debug toolbar traz diversas informações interessantes para analisarmos. Ela será uma ferramenta incrível em cenários de erro, visto que podemos examinar esses problemas a fundo por meio dela. Entre outras opções, também podemos avaliar as queries executadas para melhorar a performance.

Vale relembrar que a debug toolbar é fornecida pelo pacote do Symfony Profiler, do bundle WebProfiler.

No próximo vídeo, vamos explorar o nome da nossa rota, entender por que ela precisa de um nome e para que podemos usá-lo.

Sobre o curso Symfony Framework: formulários, validação e sessão

O curso Symfony Framework: formulários, validação e sessão possui 152 minutos de vídeos, em um total de 51 atividades. Gostou? Conheça nossos outros cursos de PHP em Programação, ou leia nossos artigos de Programação.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

Conhecendo melhor
Excluindo uma série
Sessões
Formulários
Validação e mais form