Quem Somos

Nanderson Castro

Iniciei na programação, contando o inicio da jornada e estudos, lá em 2007 mas meu contato com o primeiro computador foi nos anos 2000 por meio do computador de um tio meu com Windows 98 na época.

Meu principal intuito ao entrar no mundo da programação não era de nenhuma maneira ensinar e sim criar minha loja virtual para vender produtos de um velho sonho que tinha, sonho esse que era ter uma loja de produtos de informática e games (Seguindo os passos de meu pai, comerciante). Sempre via essa tal extensão .php nas urls dos sites e fóruns, então resolvi que iria começar por aí, buscando saber o que era esse tal de PHP.

Alguém lembra das bancas de revistas, rsrsrs. Fui a uma banca de revistas e comprei um mini-livro, da antiga Digerati, sobre PHP, entretanto, estava me precipitando muito pois não conhecia nada de lógica e o livro tinha aspectos avançados da linguagem, eu noob, achando que tudo é a mesma coisa, penei para encontrar o material correto rsrsrs!

Lembro de ter deixado o livro de lado e partido para entender como de fato começar e depois de muito penar e pesquisar fui pro zero absoluto, estudando lógica de programação e o funcionamento da web, então, o dia do livro chegou, quando finalmente consegui entender a proposta dele além de continuar a buscar mais conhecimentos para evoluir e montar minha loja, que cá entre nós tecnicamente nunca chegou sendo criada por mim…

Acabei que, na época, montando a loja mas montei por meio de serviços de loja pronta na época, entretanto, continuava a estudar programação e Web, me apaixonando cada vez mais. PHP foi minha linguagem de escolha e a que me especializei e uso até hoje, inclusive, alcançando a tão sonhada certificação PHP em 2015.

No percurso e carreira, passando por empresas locais e trabalhos remotos encontrei o Laravel, na versão 3 ainda e de lá pra cá sempre tenho ele como uma ferramenta na minha bagagem de ferramentas, quando preciso entregar aplicações web de forma produtiva e robusta e com muito valor.

Não acredito em bala de prata, entendo que existem casos e casos e a ferramenta ideal para o trabalho do momento!

Mas o Laravel é um excelente framework do mercado e que vêm ganhando muita notoriedade e cada vez mais isso só se mantêm. Ele têm um foco muito grande em produtividade e você vai aprender isso na prática, aqui nesta jornada comigo.

Code Experts

A Code Experts é uma escola de cursos online com foco em prática onde abordamos os conceitos da programação web em projetos práticos e reais. A Code Experts, antes Code Experts Learning, começou como um braço de educação da Code Experts (Criação de Sistemas Web Sob Demanda).

Iniciamos na educação para suprir uma demanda faltante de cursos em nossa cidade, São Luis do Maranhão, e da vontade de transformar outras vidas por meio do ensino de programação, levando o conhecimento e simplificando o caminho para os devs iniciantes.

Dia após dia buscamos melhorar nossas metodológias de forma a gerar valor para nossos alunos, resultando em melhora de nossos materiais e na didática abordada!

O trabalho com educação foi tão grande que resolvemos fazer o merge e unificar tudo em educação, então a Code Experts Learning, de uma braço de educação, tornou-se o corpo todo! Tornou-se Code Experts - Cursos Online de Programação na Prática.

A loja virou a plataforma!

O conhecimento adquirido ao longo dos anos, que inicialmente seria para criar minha loja de produtos de informática e games, tornou-se para criação de nossa plataforma de cursos online lançada em 2016, especificamente Novembro de 2016 no dia 05 e de lá pra cá venho concentrando meus esforços para a cada dia melhorar a experiência dos nossos alunos dentro dela.

O trabalho apenas começou!

Hoje sou desde o zelador ao editor de vídeos, passando por escritor e professor mas busco sempre dá o meu melhor para entregar excelentes materiais para nossos alunos e não farei diferente aqui neste livro!

Conte comigo!

Te convido também a nos conhecer em codeexperts.com.br.

Para quem é este livro?

Bom, serei breve aqui.

Escrevi este livro para os programadores PHP e entusiastas que buscam melhorar sua produtividade na criação de Aplicações Web usando a linguagem, entregando softwares mais rápidos e com valor agregado. Nem sempre rápido quer dizer de má qualidade pois o Laravel te permite criar coisas com menos tempo e esforço mas com alto valor agregado e é por este caminho que irei te guiar nestas páginas.

É claro que se você apenas começou com PHP, recomendo fortemente a continuar estudando as bases da linguagem e busque materiais sobre Orientação a Objetos, pois estes conhecimentos irão te adicionar uma excelente base para entender todos os conceitos abordados, não somente no Laravel, mas em frameworks PHP modernos.

Se você está pronto para a jornada, então conte comigo e vamos lá!

Repositório com os códigos

O projeto está disponível de forma completa no github e você pode escolher seguir a jornada de duas formas:

• Baixando todo o código pra acompanhar junto com o livro;
• Ou apenas deixar o repositório pra buscas de códigos especifícos.

O repositório do projeto do livro está organizado por capítulos, sendo cada capítulo uma branch específica. Cada branch está incremental, tendo o código atual do capítulo junto dos códigos dos capítulos anteriores.

Acesse o repositório em bit.ly/laravel-12-ebook-app-code

A branch main será a branch com o app completo, caso queira navegar por capítulos utilize as branchs. Você pode inclusive, ver os commits de cada capítulo(branch) para ver as alterações especifícicas ou ver os commits da branch principal que terá o merge do app completo.

Caso queira contribuir

Hoje estou atuando como instrutor independente e inclusive este livro(ebook) vêm sendo escrito, revisado e atualizado de forma independente também. Posso ter deixado passar erros aqui e ali, pode existir também algum ponto em que você possa travar quer seja porque eu deixei algum código por adicionar quer seja por você se perder na jornada.

Para isso criei um tópico no nosso grupo principal no telegram para escutar você e prestar um suporte para te destravar na jornada!

Te convido a participar em t.me/CodeExpertsCursos ou podes buscar no seu telegram pelo @CodeExpertsCursos.

Te espero aqui no grupo também!

Att. Nanderson Castro (Code Experts)

Laravel

Laravel é um fullstack framework criado por Taylor Otwell. O Laravel foi criado em Junho de 2011 e de lá pra cá vem ganhando muita notoriedade por meio de suas features e facilidades, quando tratamos da criação de aplicações web em geral.

O Laravel foi fortemente inspirado pelo Rails, desde sua forma de trabalho e gerações, a sua estrutura. O Laravel hoje em sua versão 12 e conta com um ecossistema em constante crescimento, envolvendo diversos projetos, componenetes e ferramentas dentro do seu proprio ecossistema.

Conheceremos diversas funcionalidades do framework e veremos como ele traz essa simplicidade tão aclamada pela comunidade de desenvolvedores PHP.

Para conhecimento, o Laravel hoje possui plataformas para Deploy, Criação de Projetos com Foco em Saas, Ferramentas de Suporte ao Desenvolvimento e também projetos para painéis CMS além, claro, de todo o projeto em open-source que temos.

Laravel 12

Iniciar um projeto Laravel 12, hoje é recomendado fortemente o uso do Laravel CLI ou Installer. Por meio do installer você será guiado por um utilitário que te guia por escolhas com o fim de iniciar seu projeto com os recursos que você está acostumado. O Laravel traz algumas opções de inicialização de projeto, onde você pode iniciar usando ou não um Starter Kit.

Starter kits são opções que trazem para você um projeto para de fato iniciar app rapidamente, eles vêm com autenticação, registro, perfil e mais e têm o foco de te direcionar pro que de fato importa, sua regra criada dentro desse projeto pré-preparado.

O Laravel possui hoje apenas um StarterKit com 3 opções de stack (tecnologia de ferramentas que vai compor esse starter kit).

As stacks são:

• Livewire
• React com InertiaJS
• Vue com InertiaJS

Você pode optar por iniciar o projeto Laravel sem a escolha de uma stack listada acima, que a priore é que iremos fazer aqui nesta jornada!

Obtendo o Laravel

Dado a questão das stacks faladas anteriormente, vamos iniciar nosso projeto e entender o que precisamos para usar o installer em nossa máquina. Lembrando que para usar o installer vamos precisar do composer em nossa máquina.

Para isso instale o composer através do site getcomposer.org.

Se você chegou até aqui em busca do Laravel e entendeu nosso epílogo Pra Quem é Este Livro, você já deve ter o composer em sua máquina e lidar com ele não deve ser mais problema para você!

Requerimentos

Para termos sucesso na utilização do Laravel Installer com foco em iniciar um novo projeto, cheque se seu PHP respeita as seguintes configurações:

• PHP maior ou igual ao 8.2;
• Extensão BCMath;
• Extensão Ctype;
• Extensão JSON;
• Extensão Mbstring;
• Extensão OpenSSL;
• Extensão PDO;
• Extensão Tokenizer;
• Extensão XML;

Para verificar sua versão do PHP de forma rápida basta acessar seu terminal ou cmd(tenha certeza que o PHP está no PATH do seu Sistema) e execute o comando abaixo:

php -v

Para visualizar suas extensões execute em seu terminal o comand abaixo:

php -m

Laravel Installer (Windows)

Com o composer em sua máquina Windows, vamos instalar o nosso utilitário, o Laravel Installer.

Primeiramente abra seu prompt de comando, para isso basta utilizar a combinação de teclas CTRL + R e na janelinha que aparecer digitar: cmd.

Você também pode usar o Windows Terminal e ele pode ser obtido na loja de aplicativos da Microsoft no Windows 10.

Se você executou o CTRL+R e digitou o cmd, pressione ENTER para abrir o prompt.

Com o prompt aberto, digite e execute o comando abaixo, dando um ENTER após a digitação:

Com isso o composer vai baixar o pacote laravel/installer e jogar na pasta mencionada abaixo, dentro da pasta vendor/bin que está no caminho abaixo:

Veja o resultado da instalação abaixo:

Na época de atualização e escrita deste livro, a versão do Installer é a 5.14, que traz consigo as novidades, no wizard de instalação, com foco nas melhorias de ecossistema do Laravel 12

Feito isso, precisamos adicionar o caminho dos binários globais do composer no PATH do Windows. Primeiramente acesse o menu propriedades do Meu Computador, como mostrado abaixo:

Após isso, acesse o menu Configurações Avançadas do Sistema, no menu lateral direito da sua tela. Veja abaixo:

Na tela que aparecer, na parte inferior, acesse o menu Variáveis de Ambiente.

Na janela de Variáveis de Ambiente, na parte inferior, procure por Path e clique em editar, você pode editar o PATH apenas para o seu usuário, selecionando o Path da área acima ou o Path do sistema global selecionando o Path na área abaixo, eu editei somente a do meu usuário, no caso o Path da área acima.

Clicando duas vezes na variável Path ou selecionando e clicando em Editar… você verá uma janela como abaixo:

Na janelinha que aparecer, clique em novo e adicione o Path do composer conforme abaixo:

Veja uma imagem para facilitar:

Após isso, dê OK até sair de todas as janelas. Se seu prompt continuou aberto durante o processo, feche-o e abra novamente.

Para verificar se o laravel installer é reconhecido, execute em seu cmd o comando: laravel, dê ENTER e obtenha o resultado abaixo:

Agora estamos aptos a iniciar um projeto Laravel, por meio do Laravel Installer em nosso CMD ou Windows Terminal.

Laravel Installer (MacOS ou Linux / Unix Like)

Tendo a certeza que o Composer está em sua máquina, execute o comando abaixo em seu terminal:

Após a instalação do pacote precisamos linkar ele no PATH do nosso sistema. Se você usa o bash em seu terminal o arquivo que você pode utilizar para configurar o PATH será o .bash_profile, caso utilize o zsh o arquivo a ser alterado será o .zshrc. Ambos os arquivos encontram-se na pasta do seu usuário, em $HOME.

PS.: Pelo terminal você pode digitar cd ~ e dá um enter que cairá na pasta do seu usuário, pelo seu terminal.

Ao abrir o arquivo correspondente, adicione a seguinte linha ao final do arquivo:

MacOS: PATH="$HOME/.composer/vendor/bin:$PATH"

No Linux você terá duas possibilidades e pasta: $HOME/.config/composer/vendor/bin ou $HOME/.composer/vendor/bin

Após isso, reinicie seu terminal e execute o comando laravel.

Veja o resultado abaixo:

Lembrando que sua versão será 5.14 ou superior dado o momento em que estou atualizando/escrevendo este livro.

Iniciando Primeiro Projeto

Vamo enfim iniciar nosso novo projeto e que seguiremos na prática, através dele, aqui nesta jornada!

Iniciando projeto com Laravel Installer

Por meio do Laravel Installer vamos iniciar nosso projeto com o seguinte comando abaixo:

laravel new store_app

Lembre de entrar pelo seu terminal e escolhar sua pasta de escolha, nesta pasta será criada a pasta do projeto conforme o nome que você escolher.

Nesta versão do installer precisaremos escolher a stack conforme mencionei anteriormente mas pra fins de momento vamos optar pela opção none:

Perceba que a opção padrão é none, você pode deixar em branco e simplesmente dá ENTER ou digitar none e ENTER.

Com isso o instaldor baixará todo o projeto Laravel, instalará as dependências deste projeto automaticamente e jogará tudo dentro da pasta store_app.

A opção de escolhe none iniciará para nós um projeto sem um starter kit, estamos fazendo isso pelo nosso momento didático aqui no livro. Escolher um starter kit agora tornaria nossa jornada mais dificil pois requer conhecimentos extras que não abordaremos neste livro.

Durante o passo de instalação o Laravel Installer abrirá um opção para selecionarmos o banco de escolha, por padrão o drive do banco é SQlite mas vamos optar pelo MySQL, basta digitar como na imagem e dá ENTER. Veja abaixo:

Após a escolha acima ele pedirá pra você executar as migrações, então opte por SIM e certifique-se de seu banco está levantado, mais a frente falaremos sobre migrations(migrações).

Confirme também a opção de instalar os assets via NPM para o frontend.

Feito todo esse caminho seu projeto será criado e basta acessar a pasta criada para verificar seu primeiro projeto com Laravel, recém iniciado claro!

Conhecendo a estrutura do Laravel

Vamos conhecer as pastas e os arquivos que fazem parte da estrutura base do nosso projeto:

O Laravel possui algumas pastas base, como a pasta app, bootstrap, database, config, public, resources, storage, routes, tests e a vendor. Vamos ver o que cada pasta destas representa ou armazena em sua estrutura.

app

A pasta app conterá todo o conteúdo do nosso projeto como os models, controllers, serviços, providers, middlewares e outros. Concentraremos muito dos nossos esforços nesta pasta durante a criação e desenvolvimento de nosso projeto.

config

Os arquivos de configuração, do projeto laravel, encontram-se nesta pasta. Configurações de conexões com banco de dados, configurações para armazenamento de arquivos, configurações de autenticação, mailers, serviços, sessão e outros. Esta pasta contêm arquivos que armazenam os arrays de configuração para cada uma das áreas mencionadas.

resources

Nesta pasta temos algumas subpastas que são: views, js, & css. A priore esta pasta salva os assets frontend que podemos cosumir no projeto e também nossas views da camada de templates do projeto.

storage

Nesta pasta o Laravel salva arquivos de sessions, caches, logs e nós também podemos utilizar para armazenar arquivos mediante uploads em nosso projeto.

routes

Nesta pasta vamos encontrar os arquivos para o mapeamento das rotas de nosso projeto. Rotas estas que permitirão o nosso usuário acessar determinada url e ter o conteúdo processado e esperado.

Mais a frente vamos conhecer melhor essas rotas, no Laravel 12 por padrão teremos apenas os arquivos de rota para Web e Console, as rotas de API e Broadcast Channels são adicionadas mediante necessidade, isso vêm desde a versão 11.

tests

Nesta pasta teremos as classes para teste de nossa aplicação. Testes Unitários, Funcionais e outros.

database

Aqui teremos os arquivos de migração, na pasta migrations para nossas tabelas, vamos conhecer mais sobre migrações a frente. Temos, também, os arquivos para os seeds, na pasta seeders e também as factories, na pasta factories que também conheceremos mais a frente aqui.

bootstrap

Na pasta bootstrap teremos os arquivos responsáveis por inicializar os participantes do framework Laravel, encaminhando as requisições e indicando como as coisas devem ser executadas.

Nesta pasta, no arquivo app.php é onde configuraremos, conforma necessidade, quesões sobre Middlewares, Erro Handler e mais.

public

Esta é nossa pasta principal, a que fica exposta para a web e que contêm nosso front controller.

Por meio desta pasta é que recebemos nossas requisições, especificamente no index.php, e a partir daí que o laravel direciona as requisições e começa a executar o que é necessário para aquela demanda recebida pelo browser.

vendor

A vendor, como conhecemos, é onde ficam os pacotes de terceiros dentro de nossa aplicação. Pacotes estes, mapeados e instalados pelo composer.

Outros arquivos da raiz do projeto

Temos ainda alguns arquivos na raiz do nosso projeto, como o composer.json e o composer.lock onde estão definidas as nossas dependêncas e as versões baixadas respectivamente.

Temos também o package.json que contêm algumas definições de dependências do frontend.

Temos ainda também o server.php que nos permite emular o mod_rewrite do apache.

Temos também o phpunit.xml que contêm as configurações para a execução dos testes unitários, funcionais e etc em nossa aplicação.

A parte de asset bundler, para as builds do frontend, é gerenciada pelo ViteJS e seu arquivo de configurações é o vite.config.js.

Deixei por último o arquivo .env que contêm as variavéis de ambiente para cada configuração de nossa aplicação.

Neste arquivo encontramos os parâmetros para conexão com o banco, o aplication key: que é o hash único para nossa aplicação. Encontramos outras variáveis neste arquivo que são consumidas pelo app, vale dá uma conferida.

Este arquivo e essas configurações são providas pelo pacote DotEnv do Vance Lucas.

Basicamente esta é a estrutura do nosso projeto Laravel, e nela estaremos enquanto realizamos nossa jornada!

Laravel: Artisan CLI

O Laravel possui uma interface de comandos ou command line interface (CLI) chamada de artisan. Por meio dela podemos melhorar bastante nossa produtividade enquanto desenvolvemos, como por exemplo: Gerar models, controllers, gerenciar nossas filas e muito mais!

Para conhecer todos os comando disponíveis no Artisan, basta executar na raiz do seu projeto o seguinte comando:

php artisan

O resultado deste comando será a lista de comandos e subcomandos disponiveis neste executável de terminal, que é o Artisan.

Sempre que precisar lembrar dos parâmetros de um comando/subcomando específico, lembre sempre da opção --help, exemplo: php artisan make:model --help

Executando a Aplicação

Para concluirmos nosso primeiro capítulo, vamos iniciar nossa aplicação e testá-la em nosso browser. Para isso acesse o seu projeto via terminal ou cmd no Windows e na raiz, deste projeto, execute o comando abaixo:

php artisan serve

O comando acima disponibilizará sua aplicação, via browser, no seguinte link: http://127.0.0.1:8000. Veja o resultado ao acessarmos o projeto inicialmente:

Se tudo estiver corretamente configurado, teremos o resultado acima, a tela inicial do nosso projeto Laravel, e sua página inicial padrão.

A título de informação, ao iniciar seu server, você pode escolher uma porta e host diferentes com as opções --host e --port informando os valores que quer mudar, lembre sempre da opção --help para uma doc do comando em questão. Exemplo: php artisan serve --help

Conclusões

Neste capítulo concluimos as configurações iniciais para criarmos projetos com o Laravel , o que permitiu inclusive criarmos nosso projeto que será incrementado a cada capítulo deste livro.

Agora, continuando para o próximo capítulo vamos começar a entender a estrutura geral do framework por meio da criação do nosso Hello World no Laravel.

Vamos lá!

Hello World com Laravel

Este capítulo visa mostrar o Laravel de uma forma geral, o que definirá nosso fluxo de trabalho durante todo o desenvolvimento. Gosto muito de tomar uma abordagem prática, por isso, vamos trabalhar todos os conceitos envolvendo o framework em cima de um projeto prático e direto ao ponto.

O projeto escolhido e que nos traz todo o aparato para entedermos cada parte de um framework fullstack, será a criação de uma loja virtual, além do sistema de comentários.

Então vamos lá colocar a mão na massa e dar inicio, a nossa jornada de conhecimento mas antes não podemos deixar de fazer nosso famoso mantra, criar um Hello World com o framework!

MVC

Antes de continuarmos, é interessante sabermos um pouco do modelo base utilizado no organização da estrurua dentro do nosso projeto Laravel, esse modelo ou padrão é o famoso MVC, Model-View-Controller.

A maioria dos frameworks atuais utilizam este padrão para organizar seus componentes/participantes, além de ter um Front Controller que recebe as requisições recebidas por nossa aplicação e entrega/delega para quem responsável daquela requisição. Geralmente este Front Controller se encontra na pasta public(Diretério WEBROOT da aplicação), e é inicializado no arquivo index.php dos frameworks, como o é no Laravel.

O modelo MVC possui três camadas base, as que comentei acima, o Model, o Controller e a View. Vamos entender o que é cada parte:

Model

A camada do Model ou Modelo é a camada que normalmente conterá nossas regras de negócio, geralmente possuem as entidades que representam a conversa com o banco de dados mas podem conter classes com regras de negócio específicas e até podem conter classes que realizam algum determinado serviço.

Dentro do Laravel nossos models serão as classes que representam alguma tabela no banco de dados, com poderes de manipulação referentes a esse tratamento com o banco. Você pode encontrar, por default, as classes model dentro da pasta app/Models.

Controller

A camada do Controller ou Controlador é a camada mais fina, digamos assim, pois deve receber a requisição e já demandar para o model em questão, caso necessário, e dado o retorno do model, o controller pega este retorno e entrega para a view ou, como em muitos casos, só carrega uma view caso não necessitemos de operações na camada do Model.

A ideia pro controller é que ele seja o mais simples possivel, portanto, evite adicionar regras e complexidade em seus Controllers.

Dentro do Laravel estes controllers encontram-se na pasta app/Http/Controllers.

View

A camada de View ou visualização é a camada de interação do usuário, onde nossos templates vão existir, como as telas do nosso sistema e as páginas de nossos sites.

Nesta camada, também, não é recomendado colocar regra de negócios, como por exemplo: consultas ao banco ou coisas deste tipo. Esta camada é exclusivamente para exibição de resultados e input de dados, via formulários, além de interações Javascripts e outros processos já esperados para uma melhor experiência do usuário.

No Laravel, as views encontram-se na pasta resources/views/. As views do Laravel são compostas por um template engine, que falarei sobre ele mais a frente, chamado de Blade. O Blade visa simplificar a escrita de pontos dinâmicos em nossas views como o uso loops, condicionais, estrururas customizadas e muito mais.

Roteiro para nosso primeiro Hello World

Para criarmos nosso hello world, vamos seguir o roteiro abaixo:

• Criar um controller para execução, ao chamarmos nossa rota em questão;
• Criar uma view para envio da nossa string: Hello World a ser exibida como resultado do acesso;
• Criar nossa rota para chamada e acesso em nosso browser.

A priore passos bem simples e que vão nos dar um panorama inicial do framework para a partir daí, seguirmos com os conceitos individualmente.

Iniciando Hello World

Acesse o projeto iniciado no capítulo passado pelo seu terminal ou cmd no Windows. Na certeza de está na raiz do seu projeto execute o seguinte comando abaixo:

php artisan make:controller HelloWorldController

Ao executar o comando acima teremos o seguinte resultado, pro sucesso da criação do nosso primeiro controller, exibido em nosso terminal ou cmd: Controller <CAMINHO_ATE_O_CONTROLLER> created successfully.

Após isso teremos o nosso controller criado dentro da pasta do nosso projeto, especificamente em: app/Http/Controllers. E o arquivo criado será: HelloWorldController.php.

Não esqueça de acessar o projeto em seu editor ou IDE de código de sua preferência.

PS.: Recomendo aqui, caso não tenha um em questão, o Visual Studio Code. Para baixar, acesse code.visualstudio.com.

O código do nosso controller encontra-se abaixo, este código foi gerado junto com o arquivo:

 1 <?php
 2 
 3 namespace App\Http\Controllers;
 4 
 5 use Illuminate\Http\Request;
 6 
 7 class HelloWorldController extends Controller
 8 {
 9     //
10 }

O resultado acima é a classe do nosso controller, que estende do Controller base e já traz um import para nós, o nosso Request que também conheceremos ele no decorrer do nosso livro.

Vamos criar nosso primeiro método para execução. Abaixo segue o conteúdo do nosso primeiro método:

1 public function index()
2 {
3 	$helloWorld = 'Hello World';
4 
5 	return view('hello_world.index', compact('helloWorld'));
6 }

Do método acima temos um ponto bem interessante, o retorno da função helper chamada view que recebe como primeiro parâmetro a view desejada e o segundo parâmetro um array associativo com os valores a serem enviados para esta view.

Antes de entendermos como vamos criar a view, com base no primeiro parâmetro do helper view(), preciso te falar que a função compact é uma função do proprio PHP e que pega as variáveis informadas nesta função e joga dentro de um array associativo, respeitando o pensamento de: o nome da variável ser a chave associativa e o valor da variável será o valor desta chave no array criado.

Exemplo, o compact acima, informado no segundo parâmetro do helper view(), terá como resultado o seguinte array associativo:

1 [
2    'helloWorld' => 'Hello World'
3 ]

Agora, como podemos criar nossa view de forma que o primeiro parâmetro da função helper view seja satisfeito? Vamos entender!

Temos o seguinte valor: hello_world.index.

A última parte da string acima, apresentada pós . , será o nome da nossa view e deve respeitar o seguinte nome de arquivo, se depois do ponto tenho index precisarei criar uma view chamada index.blade.php lá na pasta de views.

Só que antes do ponto temos o valor hello_world, que neste caso será a pasta onde nosso index.blade.php estará ou será criado, então, no fim das contas precisaremos criar lá dentro da pasta resources/views uma pasta chamada hello_world e dentro desta pasta nosso arquivo index.blade.php chegando ao caminho completo e o arquivo: resources/views/hello_world/index.blade.php.

PS.: Se você quiser chamar uma view diretamente que esteja dentro da pasta de views, basta informar apenas o nome da view em questão. Se você tiver mais niveis, em questão de pastas, até chegar na view, é necessário informá-los até o arquivo da view em questão. Você não precisa informar o caminho base resources/views e nem a extensão do arquivos .blade.php, pois o Laravel já inclui automaticamente para você.

Com isso crie o arquivo index.blade.php e sua pasta hello_world dentro da pasta views. Com o seguinte conteúdo abaixo:

1 <h1>{{$helloWorld}}</h1>

Acima temos, dentro do elemento h1, o nosso primeiro contato com o template engine Blade. Usamos acima a notação de print, chamada de interpolação nos template engines, abre {{ fecha }}, dentro da nossa view e pegamos a nossa variável $helloWorld vinda lá do nosso controller e exibimos seu valor dentro da tag html do elemento h1.

Agora, que já seguimos os dois passos iniciais do nosso roteiro, precisamos permitir o acesso e execução deste método, método index do nosso controller HelloWorldController, por parte dos nossos usuários mediante a liberação de uma url para acesso.

Como faremos isso? Simples, no momento, vamos criar uma rota que apontará para o método do nosso controller!

Vamos lá que vou te mostrar!

Abra seu arquivo web.php que se encontra na pasta routes na raiz do projeto.

Teremos o seguinte conteúdo:

1 <?php
2 
3 use Illuminate\Support\Facades\Route;
4 
5 Route::get('/', function () {
6     return view('welcome');
7 });

Este arquivo web.php conterá todas as rotas da nossa aplicação, rotas estas que trabalham com a exibição de views dinâmicas em nosso projeto. Tudo que for UI ou User Interface(Interface do Usuário) terá suas rotas definidas neste arquivo.

De cara já vemos a primeira definição de rota, a rota principal / que exibe a view welcome.blade.php , que está lá dentro da pasta de views. Esta rota é a rota executado ao acessarmos a página principal de uma aplicação Laravel recém instalada e que futuramente será nossa rota de entrada do site/loja.

Agora vamos definir nossa rota de hello world.

Adicione o código abaixo, após a definição da rota principal que já existe:

1 Route::get('hello-world', [\App\Http\Controllers\HelloWorldController::class,'index'\
2 ]);

Acima temos nossa primeira rota definida, a rota escolhida foi hello-world que executará o método index do controller HelloWorldController, beleza, como isto está definido? Vamos lá!

O segundo parâmetro do método get, do Route , é o executavél para esta rota, que pode ser uma função anônima como vimos na definição da rota principal já existente ou um array que respeite Controller, Método.

Existe ainda uma outra forma, que é usando uma string no formato NamespaceAtéOController@Metodo. Basicamente ficando como abaixo:

Route::get('hello-world', '\\App\\Http\\Controllers\\HelloWorldController@index');

Ao acessarmos em nosso browser a url http://127.0.0.1:8000/hello-world, o Laravel vai buscar por nossa rota internamente em sua coleção de rotas e ao encontrar uma rota que faça o match com hello-world, executará o segundo parâmetro desta rota encontrada, que como comentado pode ser uma funcão anônima ou um método de um controller ou resumindo um Callable, como fizemos a definição.

Com nossa rota definda, chegamos ao passo 3 e final do nosso roteiro e já podemos iniciar nosso webserver, na raiz do projeto para o teste do nosso Hello World.

Execute o comand abaixo em seu terminal ou cmd:

1 php artisan serve

E acesse em seu browser http://127.0.0.1:8000/hello-world, onde teremos o resultado abaixo:

O Hello World em nossa tela!

Conclusões

Neste capítulo vimos diretamente o processo de expor uma rota para acesso via browser, a execução de nosso controller através do método index, bem como, a exibição do resultado em uma view.

É claro que cada etapa destas carece de um pouco mais de informações, e também, é claro que cada etapa destas contêm diversos detalhes que serão necessários, para termos um melhor proveito do framework.

A partir de agora iremos debsravar toda estas opções e outros pontos a mais que não foram diretamente mostrados aqui.

Este capítulo serviu para te mostrar um panorama geral que será utilizado no decorrer de sua caminhada com o framework durante o desenvolvimento de suas aplicações, então, vamos continuando que temos bastante coisa para aprender ainda!

Vamos continuar nossa jornada!

Rotas & Controllers

Rotas e Controllers são integrantes bem importantes em nossas aplicações Laravel. Neste capítulo vamos conhecer mais opções proporcionadas pelas rotas e como podemos trabalhar com controllers conhecendo um pouco além do que vimos no capítulo passado.

Vamos as rotas então!

Rotas

As rotas no Laravel nos ajudam a termos um maior controle no mapeamento dos acessos a nossa aplicação, claro que nós definimos nossas urls e expomos pro nosso usuário. Como temos que mapear nossas URLs dentro dos arquivos de rota, fica mais fácil termos controle do que será exposto e também fica mais fácil de customizar como queremos.

Dentro do Laravel temos os arquivos de rotas bem separados, que nos ajudam a organizar melhor tais rotas que dependendo da aplicação podem se tornar bem grande no quesito de definições escritas dentro do arquivo de rotas em questão.

O Laravel possui os seguintes arquivos de rotas: web.php, api.php( vem mediante habilitar via comando), channels.php(mesmo detalhe sobre o api.php, precisamos habilitar dentro do fw) e console.php.

web.php

O arquivo web.php conterá as rotas de sua aplicação com as interfaces para o usuário. Todas as rotas que têm esse fim deverão ser definidas neste arquivo.

api.php

Se você for trabalhar com APIs, expondo endpoints para que outras aplicações possam consumir seus recursos, você deverá definir suas rotas com este fim no arquivo api.php.

Esse arquivo não existe em um projeto novo, para habilitá-lo precisamos executar o comando php artisan install:api com o fim de ambientar toda a parte para APIs REST do framework.

channels.php

Se você for trabalhar com eventos de Broadcasting suas rotas deverão ser definidas neste arquivo, as rotas aqui dispostas são utilizadas para controle de acesso aos canais usados no Broadcast.

Esse arquivo também não existe em um projeto novo, para habilitá-lo precisamos executar o comando php artisan install:broadcast com o fim de ambientar toda a parte para mensagens broadcast do framework.

console.php

Arquivo para registro de comandos para o console e execução a partir do artisan.

Definição de Rotas

Como vimos no último capítulo, abordei duas formas de definição de rotas em nosso Hello World. Uma era a rota que já existia no arquivo web.php e a outra foi nossa definição de rota para nosso Hello World.

Vamos da uma revisada, uma relembrada:

1 Route::get('/', function () {
2     return view('welcome');
3 });

e

1 Route::get('hello-world', [\App\Http\Controllers\HelloWorldController::class, 'index\
2 ']);

Acima temos duas formas de definição para rotas, com respeito ao que será executado. Lembrando que o primeiro parâmetro do método get é a rota em questão e o segundo parâmetro será um callable: uma função anônima ou um método de um Controller que será executado ao acessarmos a rota.

Na rota inicial, que já tinhamos no arquivo web.php, vemos a utilização da função anônima e em nossa rota usamos a definição de chamada do controller e seu método diretamente.

Um primeiro ponto que podemos abordar sobre os métodos do Route, como vimos o get até o momento, é que teremos métodos respeitando os verbos http, como:

• GET: Acesso diretos a URL;
• POST: Envio de dados via body da Request com intuito de criar;
• PUT: Verbo que indica a intenção de atualizar um recurso;
• PATCH: Verbo que indica a intenção de atualizar pedaços de um recurso;
• DELETE: Verbo que indica a intenção de remover um recurso;
• OPTIONS: Quando enviado espera-se saber quais VERBOS HTTP determinada rota suporta;

Podemos utilizá-los da seguinte maneira:

• Route::get($route, $callback);
• Route::post($route, $callback);
• Route::put($route, $callback);
• Route::patch($route, $callback);
• Route::delete($route, $callback);
• Route::options($route, $callback);

Podemos usar os métodos conforme os verbos http mostrados, tendo sempre como primeiro parâmetro, a rota em si, e o segundo parâmetro o callable ou executável para esta rota quando acessada.

Route match e Route any

Se precisarmos usar uma rota que responda a determinados tipos de verbos http, podemos usar o método match do Route. Como abaixo:

1 Route::match(['get', 'post'], 'products/create', function(){
2 	return 'Esta rota bate com o verbo GET e POST';
3 });

No exemplo acima a rota products/create suporte acessos tanto via GET quanto via POST.

Caso queira que uma rota responda para todos os verbos ao mesmo tempo, você pode usar o método any do Route:

1 Route::any('products', function(){
2 	return 'Esta rota bate com todos os verbos HTTP mencionados anteriormente';
3 });

View Routes

Em determinados momentos você vai precisar apenas renderizar determinadas views como resultado do acesso a sua rota. Para isso temos o método view do Route, que nos permite setar uma rota, primeiro parâmetro, definir uma view, segundo parâmetro. Se precisarmos passar algum valor para esta view passamos o array associativo com os dados para nossa view, este sendo o terceiro parâmetro do método.

Veja como é simples:

1 //Exibindo somente a view: 127.0.0.1:8000/bem-vindo -> view resources/views/bemvindo\
2 .blade.php 
3 
4 Route::view('/bem-vindo', 'bemvindo');
5 
6 //Exibindo a view e mandando parâmetros para ela
7 
8 Route::view('/bem-vindo', 'bemvindo', ['name' => 'Nanderson Castro']);

Bem simples, ao acessarmos a rota bem-vindo em nosso browser, carregaremos a view bemvindo.blade.php diretamente como resultado.

Parâmetros dinâmicos

Continuando, vamos conhecer um ponto bem importante sobre rotas que é a possibilidade de informamos parâmetros dinâmicos. Parâmetros estes que podem servir para identificar determinado recurso, como uma postagem em um blog por exemplo.

Veja a rota definida abaixo:

1 Route::get('/products/{slug}', function($slug) {
2     return $slug;
3 });

Temos a rota /products/ após isso definimos um parâmetro dinâmico chamado slug, dentro de chaves como é solicitado pelo componente de rotas. Em nossa função anônima passamos o parâmetro $slug que receberá o valor dinâmico e assim, poderemos utilizar ele dentro da nossa função.

Se eu estiver usando um controller e seu método, basta informarmos no método o parâmetro correspondente como informamos na função anônima e assim utilizamos tranquilamente o valor do parâmetro dinâmico.

Com esta rota defininda em nosso arquivo web.php e nosso server levantado, podemos acessar em nosso browser a seguinte url: http://127.0.0.1:8000/products/teste-parametro-dinamico.

Resultado:

Como retornamos o parâmetro informado, teremos o valor dinâmico exibido em nosa tela como mostra a imagem acima.

Parâmetros Opcionais

Se você precisar definir parâmetros opcionais para sua rota em questão, basta adicionar a ? antes do fechamento da chave do parâmetro, na definição da rota. Veja abaixo:

1 Route::get('/products/{slug?}', function($slug = null) {
2 
3     return !is_null($slug) ? $slug : 'Comportamento sem a existência do param slug';
4     
5 });

Agora nosso parâmetro slug é opcional, ou seja, não será necessário informá-lo na rota e isso nos abre precedente para validarmos ou exibirmos os resultados com base na não existência do parâmetro.

Mais um ponto bem útil nas rotas no Laravel.

Regex em parâmetros

Podemos validar o formato dos parâmetros aceitos em nossas rotas por meio de expressões regulares para um melhor controle. Para isso podemos utilizar o método where com este fim:

1 Route::get('/user/{id}', function($slug) {
2     return $slug;
3 })
4 ->where(['id' => '[0-9]+']);

O método where espera um array associativo, sendo a chave o nome do parâmetro e o valor a expressão regular (Regex) a ser validada no parâmetro informado.

Se você tiver mais de um parâmetro dinâmico e quiser informar uma regex para tal, basta ir adicionando no array associativo, respeitando o pensamento chave sendo o parâmetro e valor sendo a experessão regular que irá validar o parâmetro informado, verificando se ele respeita a regra da Regex escrita.

Apelido para rotas

Outro ponto bem importante em nossas rotas são apelidos. Mas para que servem? Até agora conhecemos o valor real ou nome real da rota mas podemos chamá-las por meio de seus apelidos também, isso nos ajuda quando precisamos, em um futuro, alterar o nome real das rotas(se isso for necessário de alguma forma).

Quando fazemos referência aos apelidos, podemos alterar tranquilamente o nome real da rota que o peso desta modificação não será tão impactante assim. E como utilizar este apelido?

Vamos pegar nossa última rota do parâmetro dinâmico:

1 Route::get('/products/{slug}', function($slug) {
2     return $slug;
3 })
4 ->name('products.single');

Perceba a adição simples que fiz após o método get antes de fechar com o ;. Chamei o método name que me permite adicionar um apelido para a rota em questão, neste caso agora posso chamar o apelido products.single toda vez que eu precisar usar a rota products/{slug}.

Em um link em nossa view ao invés de usarmos o link da rota desta maneira:

1 <a href="/products/primeiro-produto">Primeiro Produto</a>

Vamos utilizar desta maneira:

1 <a href="{{route('products.single', ['slug' => 'primeiro-produto'])}}">Primeiro Prod\
2 uto</a>

Perceba acima que estamos em uma suposta view e utilizamos um método helper do Blade que é o route em nosso atributo href da âncora. O primeiro parâmetro do route é o apelido da rota e se a rota tiver parâmetros dinâmicos, que é o nosso caso, podemos informar o valor do parâmetro, dentro de um array, no segundo parâmetro do helper route, informando o nome do parâmetro dinâmico e o seu valor.

O método route irá gerar a url correta, informando o parâmetro dinâmico no local correto. Com isso fica mais simples, se precisarmos futuramente modificar o nome real da rota, uma vez que chamamos a rota pelo apelido ao invés de seu nome real.

Grupo de Rotas & Prefixo

Podemos definir determinadas configurações para um grupo específico de rotas e para conhecermos o poder do método group, decidi mostrar ele aqui com a definição de um prefixo, método existente no Route também.

Vamos ao código abaixo:

 1 Route::prefix('products')->group(function(){
 2 
 3     Route::get('/', [\App\Http\Controllers\ProductController::class, 'index'])->name\
 4 ('products.index');
 5     
 6     Route::get('/create', [\App\Http\Controllers\ProductController::class, 'create']\
 7 )->name('products.create');
 8     
 9     Route::post('/save', [\App\Http\Controllers\ProductController::class, 'save'])->\
10 name('products.save');
11 
12 });

Perceba no trecho de rotas acima, que utilizei incialmente o método prefix para definir esse prefixo para o grupo de rotas dentro do método group.

Agora, as rotas dentro do group serão prefixadas com o products, ficando desta maneira:

• /products/;
• /products/create;
• /products/save.

Duas rotas acessíveis via GET e uma acessível via POST.

O grupo nos permite esse tipo de configuração, quando precisamos organizar melhor determinadas configurações que se repetirão para mais de um set de rota. Isso melhora até a escrita dos nossos arquivos de rotas e definições.

Grupo de Rotas & Apelidos

Vamos melhorar ainda mais nosso set de rotas do momento passado. Podemos, também, definir um apelido base para um grupo de rotas, então vamos melhorar nosso grupo anterior.

Veja como ficou:

 1 Route::prefix('products')->name('products.')->group(function(){
 2 
 3     Route::get('/', [\App\Http\Controllers\ProductController::class, 'index'])->name\
 4 ('index');
 5     
 6     Route::get('/create', [\App\Http\Controllers\ProductController::class, 'create']\
 7 )->name('create');
 8     
 9     Route::post('/save', [\App\Http\Controllers\ProductController::class, 'save'])->\
10 name('save');
11 
12 });

Perceba que agora isolei a parte products., referente ao apelido das rotas, após a definição do prefixo. Agora as rotas deste grupo além de receberem um prefixo, irão receber um apelido base que será concatenado com os apelidos de cada rota do grupo.

Os apelidos ficarão desta forma:

• products.index;
• products.create;
• products.save.

Esses serão os apelidos das rotas, o mesmo que seria anteriormente mas agora com o detalhe de termos organizado e isolado, centralizando o que era repetido, ou seja, o products..

Assim como o prefixo e o apelido podemos centralizar outras configurações nestes arquivos, como middlewares, controllers e muitas outras opções que veremos mais a frente aqui nesta jornada.

Controllers

Já tivemos nosso primeiro contato com controllers anteriormente. Os controllers são parte importantíssima nesta organização, utilizando o Laravel.

Relembrando, de forma simples, os controllers são o ponto de delegação entre Model e View, recebendo a requisição e entregando para quem é de direito.

Utilizando o artisan podemos gerar, como já fizemos, os nossos controllers. Como fizemos, no capítulo passado, ao executarmos o comando abaixo:

1 php artisan make:controller HelloWorldController

Agora vamos explorar mais opções dentro deste comando e buscar mais produtividade na execução de nossos projetos.

Controllers como Recurso

Podemos gerar controllers com métodos para cada operação de CRUD e por meio de uma configuração de rota termos também, as rotas automáticas para cada um destes métodos.

Este tipo de controller chamamos de controller como recurso ou em muitos casos chamamos também de RESTFull Controllers. Vamos gerar e entender como são.

Em seu terminal na raiz do seu projeto execute o comando abaixo:

1 php artisan make:controller UserController --resource

A opção --resource pode ser chamada também como -r

Perceba agora que usei o mesmo comando para gerar um novo controller mas, caso acima, adicionei a opção --resource que criará um controller com os seguintes métodos abaixo:

• index;
• create;
• store;
• show;
• edit;
• update;
• destroy;

Perceba que quando iniciamos o controller como recurso, já temos um controller com os métodos acima definidos só no ponto para colocarmos nossas lógicas de inserção, leitura e etc.

Veja o controller gerado abaixo na íntegra:

 1 <?php
 2 
 3 namespace App\Http\Controllers;
 4 
 5 use Illuminate\Http\Request;
 6 
 7 class UserController extends Controller
 8 {
 9     /**
10      * Display a listing of the resource.
11      *
12      * @return \Illuminate\Http\Response
13      */
14     public function index()
15     {
16         //
17     }
18 
19     /**
20      * Show the form for creating a new resource.
21      *
22      * @return \Illuminate\Http\Response
23      */
24     public function create()
25     {
26         //
27     }
28 
29     /**
30      * Store a newly created resource in storage.
31      *
32      * @param  \Illuminate\Http\Request  $request
33      * @return \Illuminate\Http\Response
34      */
35     public function store(Request $request)
36     {
37         //
38     }
39 
40     /**
41      * Display the specified resource.
42      *
43      * @param  int  $id
44      * @return \Illuminate\Http\Response
45      */
46     public function show($id)
47     {
48         //
49     }
50 
51     /**
52      * Show the form for editing the specified resource.
53      *
54      * @param  int  $id
55      * @return \Illuminate\Http\Response
56      */
57     public function edit($id)
58     {
59         //
60     }
61 
62     /**
63      * Update the specified resource in storage.
64      *
65      * @param  \Illuminate\Http\Request  $request
66      * @param  int  $id
67      * @return \Illuminate\Http\Response
68      */
69     public function update(Request $request, $id)
70     {
71         //
72     }
73 
74     /**
75      * Remove the specified resource from storage.
76      *
77      * @param  int  $id
78      * @return \Illuminate\Http\Response
79      */
80     public function destroy($id)
81     {
82         //
83     }
84 }

Agora com o controller como recurso gerado, podemos expor rotas para cada um dos métodos acima. Neste caso, para facilitar mais ainda nossas vidas, temos um método dentro do Route chamado de resource que já expõe para nós as rotas apontando para cada um dos métodos vistos acima, simplificando ainda mais as coisas.

Em seu arquivo de rotas web adicione a rota abaixo:

1 Route::resource('/users', \App\Http\Controllers\UserController::class);

Se nós debugarmos as rotas existentes em nosso projeto até o momento, podemos encontrar, focando no controller como recurso e em suas rotas, o resultado destacado abaixo na imagem.

Para debugarmos as rotas existentes no Laravel, definidas dentro de sua aplicação, basta executar na raiz do seu projeto o comando abaixo:

1 php artisan route:list

Obtendo a lista de rotas de sua aplicação. Veja o destaque nas rotas criadas pelo método resource do Route:

Além de termos gerado o controller com os métodos para serem utilizados dentro de um CRUD completo, temos também a criação das rotas para cada um dos métodos deste controller, por meio da chamada de apenas um método, o método resource do Route.

O método resource recebe o nome da rota, tal qual um prefixo, como primeiro parâmetro e o nome do controller, gerado como recurso, no segundo parâmetro, simples como vimos.

Perceba que na imagem acima: temos as rotas, temos também apelidos para estas rotas e ainda temos rotas para cada um dos verbos HTTP.

Entenda abaixo:

• Temos uma rota principal, que serve para listagem de todos os dados, neste caso usuários. Esta rota é /users que aponta para o método index do UserController;
• Temos a rotas users/create que aponta para o método create do Usercontroller que se refere a tela de exibição do form de criação. A rota users/store aponta para o método store de UserController e se refere ao salvar de fato os dados vindos do form de criação;
• Temos ainda a rota para visualização de um dado específico, neste caso, podemos usar tanto a users/{user} (aponta para UserController@show) ou users/{user}/edit (aponta para UserController@edit) via GET, o edit aqui seria exatamente para uma tela com form de edição;
• Para atualização temos a rota users/{user} que aponta para o método update de UserController.
• Temos também a rota users/{user} e aponta para o método destroy do UserController, indicando a remoção de um dado.

Perceba acima ou pela imagem que temos rotas com nomes parecidos, em outros cenários a rota mais recente em ordem cima pra baixo seria a primeira a ser executada mas o que difere cada acesso é o verbo HTTP que também vemos na listagem do route:list ou na lista abaixo eu mostro.

Melhorando a visualização e simplificando:

• rota: /users/, verbo: GET, controller@método: UserController@index;
• rota: /users/, verbo: POST, controller@método: UserController@store;
• rota: /users/create, verbo: GET, controller@método: UserController@create;
• rota: /users/{user}, verbo: GET, controller@método: UserController@show;
• rota: /users/{user}, verbo: PUT ou PATCH, controller@método: UserController@update;
• rota: /users/{user}, verbo: DELETE, controller@método: UserController@destroy;
• rota: /users/{user}/edit, verbo: GET, controller@método: UserController@edit;

Lembrando que você precisa adicionar sua lógica para cada um dos métodos, entretanto, todas as rotas já estão definidas como vimos acima e quando geramos o controller temos as definições dos métodos também.

Conclusões

Vimos aqui neste capítulo diversas possibilidades sobre as rotas de nossa aplicação e mais opções referentes aos nossos controllers. É claro, que temos mais opções, tanto dentro das rotas quanto na exploração dos controllers.

A cada capítulo vamos conhecendo mais opções para rotas, por exemplo a opção dos middlewares, quando conhecermos os conceitos envolvendo esta parte!

No próximo capítulo iremos falar sobre o envio de dados de um formulário para nosso backend e a manipulação das requests e do nosso response.

Até lá!

Formulários, Request & Response

Neste capítulo vamos conhecer um ponto bem importante n criação das nossas aplicações, como manipular informações recebidas em nossas requests e as particularidades do response HTTP dentro do Laravel.

Aproveito também e já abordo essas requisições com dados vindos de um formulário, onde teremos pontos importantes a serem abordados neste aspecto.

Então vamos lá!

Iniciando pelo formulário

Para começar, vamos criar um formulário para envio dos dados para nosso controller. Para isso crie um arquivo chamado de create.blade.php dentro da pasta de views, colocando ele dentro da pasta products, então crie esta pasta também. O caminho completo até o arquivo ficará assim:

resources/views/products/create.blade.php

Veja o formulário abaixo a ser adicionado no create.blade.php:

 1 <form action="{{route('products.store')}}" method="post">
 2 
 3     <div class="w-full mb-6">
 4         <label class="block mb-2">Nome</label>
 5         <input type="text" name="name" class="w-full p-2 rounded">
 6     </div>
 7 
 8     <div class="w-full mb-6">
 9         <label>Descrição</label>
10         <input type="text" name="description"  class="w-full p-2 rounded">
11     </div>
12 
13     <div class="w-full mb-6">
14         <label>Conteúdo</label>
15         <textarea name="body" id="" cols="30" rows="10"  class="w-full p-2 rounded">\
16 </textarea>
17     </div>
18 
19     <div class="w-full mb-6">
20         <label>Preço</label>
21        <input type="text" name="price"  class="w-full p-2 rounded">
22     </div>
23 
24     <div class="w-full mb-6">
25         <label>Slug</label>
26         <input type="text" name="slug"  class="w-full p-2 rounded">
27     </div>
28 
29     <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-white\
30  font-thin">Criar Produto</button>
31 </form>

No formulário temos 5 campos diretamente, são eles:

• Nome;
• Descrição;
• Conteúdo;
• Preço;
• Slug (futuramente vamos automatizar esta geração);

Obs.: Utilizei a estrutrua do form pensando no TailwindCSS, mais a frente no livro vamos configurar esse framework css em nosso projeto. O TailwindCSS é um framework css pensado mais no utilitário, ou seja, classes que representam o estilo aplicado. Nele você também pode componentizar como Bootstrap por exemplo e pra isso você mesmo precisa criar seus código pra reutilização.

Nosso formulário trabalhará com envio dos dados via método POST e já adicionamos, na action do formulário, a chamada de uma rota pelo seu apelido, a products.store. Vamos gerar nosso controller e nossas rotas para que possamos fazer esse form funcionar.

Gere o controller a partir do seu terminal, com o comando abaixo:

1 php artisan make:controller Admin/ProductController

Perceba mais um aprendizado acima, como coloquei Admin/ antes do nome do nosso controller, ele será criado dentro da pasta Admin dentro da pasta de controllers. Isso simplifica também nossas gerações, onde podemos especificar pastas a dentro para uma melhor organização dos controllers.

Para este exemplo não vou gerar este controller como recurso porque nosso foco ainda não é gerarmos um crud e sim conhecermos esse trabalho entre as requisições e o envio de dados.

Uma vez criado o controller, adicione os dois métodos abaixo nele:

1 public function create()
2 {
3 	return view('products.create');
4 }

e também:

1 public function store(Request $request)
2 {
3 
4 }

O primeiro método será para exibição de nossa view do formulário e o segundo para manipularmos o que for enviado do formulário de criação. Este segundo método veremos mais adiante seu conteúdo.

Até o momento nosso controller fica desta maneira:

 1 <?php
 2 
 3 namespace App\Http\Controllers\Admin;
 4 
 5 use Illuminate\Http\Request;
 6 use App\Http\Controllers\Controller;
 7 
 8 class ProductController extends Controller
 9 {
10     public function create()
11     {
12 		return view('products.create');
13     }
14 
15     public function store(Request $request)
16     {
17 
18     }
19 }

View criada, controller e métodos definidos vamos adicionar no arquivo de rotas web.php nossas definições de rota para este trabalho. Vamos lá!

Veja as rotas adicionadas abaixo:

 1 Route::prefix('admin')->group(function(){
 2 
 3 	Route::prefix('products')->name('products.')->group(function(){
 4 	
 5 		Route::get('/create', [\App\Http\Controllers\Admin\ProductController::class, 'crea\
 6 te'])->name('create');
 7 		
 8 		Route::post('/store', [\App\Http\Controllers\Admin\ProductController::class, 'stor\
 9 e'])->name('store');
10 		
11 	});
12 
13 });

Perceba acima que isolei o prefixo admin para o grupo de rotas que contêm o nossas rotas de product. E também isolei o prefixo products, bem como o seu apelido products., para o conjunto de rotas pensadas para este capítulo.

No fim ao acessarmos /admin/products/create veremos nosso formulário, ainda sem estilo, carregado em nossa tela. E também ao enviarmos nosso form ele mandará os dados para nossa rota /admin/products/store.

Com nosso servidor ligado, através do comando php artisan serve podemos acessar nosso link http://127.0.0.1:8000/admin/products/create chegando ao resultado da imagem abaixo:

Feito isso vamos conhecer o request!

Request, manipulando requisições

Vamos começar este trecho tentando enviar qualquer dado para o nosso backend a partir do formulário. Podemos enviar até o form vazio mesmo, então vamos clicar em Criar Produto, enviando nosso formulário.

Se você recebeu a tela de expirado abaixo, não se preocupe! rsrsrsrsrsr!

Por que isso aconteceu? Perceba, pela sua barra de endereços, que ele enviou a requisição para a rota correta: /admin/products/store, então porque recebemos uma tela de requisição expirada?

Quando enviamos dados via POST, PUT ou PATCH o Laravel faz uma validação na requisição para evitar que fontes externas enviem dados ou falsifiquem nossa requisição. Esse controle é chamado de CSRF (Cross Site Request Forgery).

Obs.: O CSRF não é algo exclusivo do Laravel, é um tópico de segurança e recomendo fortemente a leitura sobre o assunto.

Agora como podemos adicionar este controle de segurança em nosso formulário? Vamos lá então, adicione após a abertura da tag form o seguinte input abaixo:

1 <input type="hidden" name="_token" value="{{csrf_token()}}">

Acima estamos enviando o token csrf, para validar a procedência e envio dos dados do nosso formulário, através da requisição. Feito isso, volte para a página do formulário atualize e tente enviar novamente.

Agora você verá tudo branco e a página de expirado já não existe mais, como não temos nada definido no método store, lá no controller, o resultado será mesmo uma página em branco mas nossa requisição post, vinda do formulário, já bate na execução do método corretamente.

O input acima, com o token csrf, pode ser substituido completamente pelo:

1  {{csrf_field()}}

Que adicionará o input completo como fizemos na mão anteriormente. Ou ainda podemos simplificar mais, utilizando uma diretiva disponível do blade, segue abaixo:

1  @csrf

Que também adiciona o input como fizemos anteriormente. O formulário agora fica desta forma:

 1  <form action="{{ route('products.store') }}" method="post">
 2     @csrf
 3 
 4     <div class="w-full mb-6">
 5         <label class="block mb-2">Nome</label>
 6         <input type="text" name="name" class="w-full p-2 rounded">
 7     </div>
 8 
 9     <div class="w-full mb-6">
10         <label>Descrição</label>
11         <input type="text" name="description" class="w-full p-2 rounded">
12     </div>
13 
14     <div class="w-full mb-6">
15         <label>Conteúdo</label>
16         <textarea name="body" id="" cols="30" rows="10" class="w-full p-2 rounded"><\
17 /textarea>
18     </div>
19 
20     <div class="w-full mb-6">
21         <label>Preço</label>
22         <input type="text" name="price" class="w-full p-2 rounded">
23     </div>
24 
25     <div class="w-full mb-6">
26         <label>Slug</label>
27         <input type="text" name="slug" class="w-full p-2 rounded">
28     </div>
29 
30     <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-white\
31  font-thin">Criar Produto</button>
32 </form>

Agora que nosso form já está ‘funcionando’ e nossa requisição está chegando no método como podemos manipular os dados dentro do método store?

Manipulando os dados da requisição

Se voltarmos ao método store do ProductController, vamos perceber que em sua assinatura temos a definição de um parâmetro.

1 public function store(Request $request)
2 {
3 
4 }

O parâmetro $request, e seu tipo esperado é um objeto Request do próprio Laravel. O objeto Request vêm do namespace Illuminate\Http\Request e ele é automaticamente resolvido pelo container de injeção de dependências do Laravel, mais a frente falaremos sobre esse container.

Com isso, por meio do parâmetro $request temos a possibilidade de acesso, das mais variadas formas, aos dados enviados na requisição para nosso método, e em nosso caso, vindos do formulário.

Vamos ver um panorama geral dos dados enviados. Adicione o seguinte trecho dentro do método store:

1 dd($request->all());

Acima temos contato com mais uma função helper do Laravel, o dd que simplesmente faz uma dump mais customizado dos dados informados a ele e em seguida joga um die travando a continuação da execução do código. Por isso o dd ou dump and die.

Continuando…

Preencha dados em seu formulário e envie novamente a requisição. Veja o resultado:

O resultado acima são todos os campos vindos do nosso formulário, o resultado do dump é o que temos acima mas os dados estão sendo resgatados por meio do método all do objeto Request, que traz todos os dados enviados por meio desta requisição tal qual pegassemos diretamente do nosso conhecido $_POST.

Recuperando valores específicos

Você pode acessar os campos diretamente, por exemplo, se você quiser acessar o nome do produto, enviado do formulário, você pode acessar das seguintes maneiras:

1 dd($request->get('name'));

ou

1 dd($request->name);

ou ainda

1 dd($request->input('name'));

Isso vale para cada campo que você envia e que deseja recuperar o valor.

Obs.: Só uma observação, e frisando novamente, estou usando o dd aqui apenas para debug. Mais a frente vamos concluir esta etapa de manipulação, como por exemplo, pegar estes valores e salvar no banco de dados.

Verificando a existência de um dado na requisição

Podemos verificar ainda se determinado campo, parâmetro ou input foi informado em nossa requisição. Para isso podemos utilizar o método has do objeto request.

Veja abaixo:

1 if($request->has('name')) {
2     dd($request->name);
3 }

Com isso podemos realizar determinadas operações para a existência ou não existência dos campos. Se você deseja verificar a existência de vários inputs, você pode utilizar o método hasAny, veja abaixo:

1 if($request->hasAny(['name', 'body', 'slug'])) {
2     dd($request->name);
3 }

Recuperando campos específicos

Podemos recuperar x inputs se precisarmos. Por exemplo, se você quiser recuperar apenas o campo name e o campo slug da request:

1 $request->only(['name', 'slug']);

Desta maneira vamos receber um array com os dois campos informados e seus respectivos valores.

Caso você queira ignorar campos específicos, também é possivel, por exemplo:

1 $request->except(['name']);

Neste caso receberemos um array com todos os campos e somente o campo name não estará presente neste array. São método bem úteis quando precisamos destes comportamentos.

Trabalhando com Query Strings ou Parâmetros de URL

Parâmetros de url, as famosas query strings, são parâmetros informados em nossa url sempre após a ? e respeitando chave=valor e quando temos mais de um parâmetro são concatenados pelo &. A querystring é a forma que a requisição envia os dados mantendo seu estado na própria URL com já conhecemos quando estudamos no PHP Básico.

Por exemplo, como eu poderia recuperar o parâmetro search da seguinte url http://127.0.0.1:8000?search=teste?

Para acessarmos seu valor, nós podemos utilizar o método query para recuperar este input exclusivo vindo da url.

Por exemplo:

1 $request->query('search');

Este método, o query, assim como o get e o input, aceita um segundo parâmetro pro caso da não existência do parâmetro ou input solicitado. Podemos definir um valor default que será carregado caso não tenhamos valor no acesso em questão.

Veja abaixo:

 1 $request->query('search', 'este valor será retornado caso não tenhamos o parâmetro s\
 2 earch na query string');
 3 
 4 //Pro input e pro get
 5 
 6 $request->get('title', 'este valor será retornado caso não tenhamos o parâmetro titl\
 7 e na requisição');
 8 
 9 $request->input('title', 'este valor será retornado caso não tenhamos o parâmetro ti\
10 tle na requisição');

PS.: por padrão esse valor do segundo parâmetro é NULL então você também pode testar direto por seu retorno se o dado veio ou não com valor. Caso queira verificar se tal chave existe aí recorremos ao has como vismo anteriormente.

Response: manipulando respostas

Dentro das linguagens Web é importante entendermos o protocolo HTTP e a base dessa arquitetura que é a Web, onde trabalhamos com Requests & Responses e no meio temos os processamentos no backend, seja lá qual for a linguagem.

Manipulamos nossa requisição e de certa forma realizamos processamentos até o momento, agora precisamos conhecer a manipulação das responses ou respostas HTTP.

É claro que abordarei aqui dentro da estrutura do framework mas já deixo uma recomendação de, se caso você não tenha conhecimento básico do http pelo menos, procure mais informações sobre o assunto para entender melhor a arquitetura da web, isso vai te abrir muito a mente.

Então, como podemos manipular esse tal response ou respostas http?

Manipulando as respostas HTTP

Podemos manipular as respostas http em nossos controllers ou funções anônimas de nossas rotas, utilizando a função helper response.

Veja abaixo uma utilização simples:

1 return response('Retornando uma resposta', 200);

Acima retornei uma resposta com o conteúdo Retornando uma resposta e o status code http 200, que se refere a status de sucesso.

Podemos definir cabeçalhos HTTP em nossa resposta também. Por exemplo, posso dizer que o tipo da minha resposta é um json da seguinte maneira:

1 return response(['msg' => 'Retorno do tipo json'], 200)
2             ->header('Content-Type', 'application/json');

Agora o tipo da resposta, que por default seria do tipo ‘text/html’, será do tipo ‘application/json’ por meio da manipulação do cabeçalho http Content-Type e informando o mime-type por meio deste cabeçalho, em nosso caso, colocando o tipo para json: application/json.

Podemos ainda manipular cookies e enviar quantos cabeçalhos forem necessários por meio do objeto response. Por exemplo, se você quiser retornar um cookie em uma determinada resposta, basta utilizar como abaixo:

1 return response(['msg' => 'Retorno do tipo json'], 200)
2             ->cookie('nome_cookie', 'valor_cookie', 'tempo_em_minutos_de_validade_do\
3 _cookie');

Redirecionamentos

Dentro desta manipulação do response, que têm a ver com o retorno de nossas rotas (quer seja em função anônima quer seja no método de um controller), precisamos abordar, também, sobre redirecionamentos.

Em alguns momentos vamos precisar apenas retornar um redirecionamento pós realização de uma determinada execução. Para isso temos a função helper redirect:

1 return redirect('/');

Acima creio que está bem intuitivo mas não custa comentar.

Após um determinado processo posso redirecionar o usuário para uma determinada url, acima redireciono ele para a página inicial do nosso website mas podemos melhorar ainda mais esses redirecionamentos. No trecho acima redirecionei ele para uma url chamando o nome real da rota, entretanto, eu te disse anteriormente que é melhor trabalharmos com os apelidos da rota ao invés do seu nome real, correto?

Correto, então não se preocupe!

Podemos redirecionar o usuário para a rota desejada por meio do apelido desta rota.

Veja abaixo:

1 return redirect()->route('home');

Chamo a função redirect sem parâmetros, com isso temos o retorno do objeto \Illuminate\Routing\Redirector e com isso posso ter acesso ao método route, que inclusive já utilizamos aqui no livro. Agora basta que eu informe o apelido da rota desejada, e se essa rota possuir parâmetros dinâmicos basta informar em um array no segundo parâmetro do route como já vimos anteriormente também.

Podemos utilizar também um redirect para o estado anterior de uma requisição, isso é perfeito para momentos de erro no processamento de determinado acesso ou envio de dados. Por exemplo, quando enviamos os dados de um formulário para o backend e temos algum erro de validação nos dados.

Para isso temos a função helper back.

Por exemplo:

1 return back();

Que retornará o usuário para o estado anterior da requisição assim como o botão back do browser ou melhor simulando esse comportamento.

Geralmente usamos essa função back para momentos de erro de processo ou validações, e nestes casos você precisa voltar o usuário pro momento anterior, caso o usuário tenha mandado dados de um formulário podemos retornar os campos já digitados por ele também, como podemos ver abaixo:

1 return back()->withInput();

Acima além de voltarmos pro estado da requisição anterior, estamos mandando de volta os inputs digitados. Para manipularmos lá na view, no form e exibir os valores vindos do withInput podemos usar a função helper old nos inputs do nosso formulário.

Lembra do nosso formulário? Olha como ele fica após adicionarmos essa possibilidade de pegar o valor novamente dos campos digitados anteriormente pelo usuário:

 1 <form action="{{ route('products.store') }}" method="post">
 2     @csrf
 3 
 4     <div class="w-full mb-6">
 5         <label class="block mb-2">Nome</label>
 6         <input type="text" name="name" class="w-full p-2 rounded" value="{{ old('nam\
 7 e') }}">
 8     </div>
 9 
10     <div class="w-full mb-6">
11         <label>Descrição</label>
12         <input type="text" name="description" class="w-full p-2 rounded" value="{{ o\
13 ld('description') }}">
14     </div>
15 
16     <div class="w-full mb-6">
17         <label>Conteúdo</label>
18         <textarea name="body" id="" cols="30" rows="10" class="w-full p-2 rounded">{\
19 { old('body') }}</textarea>
20     </div>
21 
22     <div class="w-full mb-6">
23         <label>Preço</label>
24         <input type="text" name="price" class="w-full p-2 rounded" value="{{ old('pr\
25 ice') }}">
26     </div>
27 
28     <div class="w-full mb-6">
29         <label>Slug</label>
30         <input type="text" name="slug" class="w-full p-2 rounded" value="{{ old('slu\
31 g') }}">
32     </div>
33 
34     <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-white\
35  font-thin">Criar Produto</button>
36 </form>

Perceba no textarea e nos atributos value de cada input, onde temos agora o print do retorno da função helper old. Nesta função helper informamos o nome do campo que queremos recuperar o valor digitado anteriormente.

Caso aquele campo em questão não esteja na requisição, adicionado pelo withInput, o campo simplesmente fica em branco e o usuário preenche tranquilamente ou altera, se necessitar, o valor previamente digitado.

Isso é perfeito para o usuário, que não precisará digitar tudo novamente caso tenha algum problema no backend e nós se precisarmos retornar ele pro estado anterior pós uma validação não satisfeita por exemplo.

Conclusões

Neste capítulo trabalhamos com o envio de dados de um formulário para uma determinada rota e aprendemos também a manipular estes valores além de conhecermos mais detalhes sobre o objeto Request e Response.

Vimos ainda, particularidades sobre as repostas HTTP nos resultados de nossos processos, além de conhecermos as possibilidades de redirecionamento que estão diretamente atrelados aos responses uma vez que os redirecionamentos também são uma execução pós-processos.

Agora que já entendemos essas manipulações, vamos conhecer como o Laravel trabalha com banco de dados e como podemos manipular a parte do Model fechando o ciclo MVC dentro do nosso livro.

Nos vemos no próximo capítulo.

Database: Migrations, Seeds & Factories

Neste capítulo vamos entrar na área, provavelmente a mais esperada, do banco de dados. Conhecendo como o Laravel nos permite realizar a persistência dos dados em nossas aplicações web.

Preciso ressaltar que temos algumas camadas dentro do framework quando tratamos de banco de dados, uma delas é a que vamos abordar neste capítulo, a camada mais baixa, a camada mais estrutural composta por: migrations, seeds & model factories.

Vamos entender o que cada ponto têm de importante aqui.

Comecemos pelas migrations.

Migrations

As migrations ou migrações são ferramentas que nos auxiliam no versionamento da estrutura de nossas bases de dados. Funciona basicamente como uma documentação da linha histórica com respeito ao crescrimento estrutural do banco, criação das tabelas, ligações e etc.

Vale ressaltar que o conceito migrações não é algo do Laravel mas que ele se utiliza para trazer mais essa opção e facilidade para quem está desenvolvendo. Criar tabelas e seus aparatos se torna mais fácil quando realizamos isso do ponto de vista de código, que após um comando via artisan é traduzido para o banco em questão.

As migrations dentro do nosso projeto podem ser encontradas dentro da pasta database/migrations. Nesta pasta você já vai encontrar alguns arquivos de migração iniciais, como a migração para a tabela de usuários dentre outras migrações referentes a tabela de jobs(usada para a parte de filas) e algumas a mais.

Vamos da uma olhada na migration da tabela de usuários e entender como é formado um arquivo de migração.

Veja abaixo o arquivo 0001_01_01_000000_create_users_table.php:

 1 <?php
 2 
 3 use Illuminate\Database\Migrations\Migration;
 4 use Illuminate\Database\Schema\Blueprint;
 5 use Illuminate\Support\Facades\Schema;
 6 
 7 return new class extends Migration
 8 {
 9     /**
10      * Run the migrations.
11      */
12     public function up(): void
13     {
14         Schema::create('users', function (Blueprint $table) {
15             $table->id();
16             $table->string('name');
17             $table->string('email')->unique();
18             $table->timestamp('email_verified_at')->nullable();
19             $table->string('password');
20             $table->rememberToken();
21             $table->timestamps();
22         });
23 
24         Schema::create('password_reset_tokens', function (Blueprint $table) {
25             $table->string('email')->primary();
26             $table->string('token');
27             $table->timestamp('created_at')->nullable();
28         });
29 
30         Schema::create('sessions', function (Blueprint $table) {
31             $table->string('id')->primary();
32             $table->foreignId('user_id')->nullable()->index();
33             $table->string('ip_address', 45)->nullable();
34             $table->text('user_agent')->nullable();
35             $table->longText('payload');
36             $table->integer('last_activity')->index();
37         });
38     }
39 
40     /**
41      * Reverse the migrations.
42      */
43     public function down(): void
44     {
45         Schema::dropIfExists('users');
46         Schema::dropIfExists('password_reset_tokens');
47         Schema::dropIfExists('sessions');
48     }
49 };

Perceba acima que a classe de migração, inicialmente extende de uma classe base chamada Migration e traz a definição de dois métodos, o método up e o método down.

O método up será chamado quando essa migração for executada em nosso banco de dados. E o método down contêm a definição do inverso do método up, no método down nós definimos a remoção do que foi aplicado no método up, isso nos permite voltarmos para estados anteriores pré-execução do último lote de migrações.

Vamos da uma atenção ao método up, focando no trecho da criação da tabela users:

 1 public function up()
 2 {
 3 	Schema::create('users', function (Blueprint $table) {
 4         $table->id();
 5         $table->string('name');
 6         $table->string('email')->unique();
 7         $table->timestamp('email_verified_at')->nullable();
 8         $table->string('password');
 9         $table->rememberToken();
10         $table->timestamps();
11     });
12 
13     //...
14 }

Temos uma classe base responsável pela definição dos schemas (Schema) da base de dados e é com ela que criamos nossa tabela por meio do método create, informando como primeiro parâmetro o nome da tabela e o segundo parâmetro será um callback (ou função anônima) onde definiremos os campos e estrutura da tabela em questão, no trecho acima a tabela users.

Para definir os campos de nossa tabela precisamos do objeto Blueprint, que nos permite criar os campos e tipos por meio de seus métodos, por isso tipamos o parâmetro $table, do callback, como Blueprint.

O Blueprint contêm métodos para tudo o que é necessário de manipulação de nossa tabela como: geração e remoção de colunas, os mais variados tipos de dados para as colunas em questão, definição de chaves estrangeiras, criação de índices e muito mais.

Podemos criar nossas chaves primárias e auto-incrementáveis utilizando o método id (método este que já vêm na migration, quando fazemos a criação do arquivo pelo artisan), como temos na linha abaixo:

1 $table->id();

Podemos definir campos do tipo string (Varchar), como ocorre abaixo:

1 $table->string('name');
2 $table->string('email')->unique();

Acima temos a definição de dois campos Varchar e por default recebe 255 caracteres, caso queira especificar um tamanho para o campo, basta preencher o segundo parâmetro com o valor inteiro, correspondente ao tamanho do campo desejado.

Perceba também, que para o e-mail atribuimos uma definição na coluna, assinalando este campo como unique ou seja evitando a duplicação de linhas com o mesmo email, tornando assim, a partir da base, o usuário único por email.

Podemos definir campos de data e hora por meio do método timestamp, veja abaixo:

1 $table->timestamp('email_verified_at')->nullable();

O campo email_verified_at tabém permitirá nulo, isso definido pelo método nullable.

Temos também a definição de mais um campo tipo VARCHAR para a coluna password:

1 $table->string('password');

E por fim temos a chamada do método rememberToken() e também do timestamps(), o que são esses métodos ou que eles fazem?

1 $table->rememberToken();
2 $table->timestamps();

O método rememberToken irá criar uma coluna chamada de remember_token, varchar com tamanho 100 e aceitando o valor nulo. Já o método timestamps irá criar dois campos do tipo timestamp, um chamado de created_at e outro chamada de updated_at, ambos para representarem a data de criação e atualização do dado.

Um ponto interessante é que o Laravel controla os valores destes dois campos(created_at, updated_at), para data de criação e atualização de registros, automaticamente via Models.

Se o método up define a criacão da tabela de users(usuários) o down define a remoção desta tabela. Veja como está a definição do método down:

1 public function down()
2 {
3         Schema::dropIfExists('users');
4         Schema::dropIfExists('password_reset_tokens');
5         Schema::dropIfExists('sessions');
6 }

O método dropIfExists, do objeto Schema, permite a remoção da tabela da base se ela existir, conretizando o inverso do método up. Isso facilita pois podemos voltar um passo anterior, na linha de execução das migrations, desfazendo alterações propostas pela migração em questão.

Desde o Laravel 11 a migração para a tabela de users vêm com as definições para mais duas tabelas, como é muito tranquilo entender a estrutura dessas migrations, e claro, aqui espero que você entenda bem do banco de dados, deixo pra você olhar as outras definições existentes neste arquivo de migração atual.

Agora como pegamos esse código Orientado a Objetos e jogamos para uma base relacional? É o que vamo ver a seguir.

Executando primeira migração

Para executarmos as migrações existentes no projeto podemos utilizar o comando: php artisan migrate.

Este comando sempre vai executar as migrações mais novas na base de dados, as migrações que já foram executadas são registradas na tabela migrations. A tabela migrations é criada pelo Laravel justamente para controlar quais arquivos de migração foram executados.

Aqui te lembro que quando iniciamos o projeto as migrações já foram executadas, ou seja, essas migrações padrões vindas no framework já estão executadas na nossa base de dados (dê uma olhada na tua base depois). O nome da tua base é o nome que você deu pro seu projeto e o Laravel também cria essa base automaticamente baseada nesse nome, lembrando também, que as variáveis de acesso ao banco estão no arquivo .env.

Veja abaixo como está no projeto atualmente:

1 #Parâmetros dentro do arquivo .env
2 
3 DB_CONNECTION=mysql
4 DB_HOST=127.0.0.1
5 DB_PORT=3306
6 DB_DATABASE=store_app
7 DB_USERNAME=root
8 DB_PASSWORD=

Caso você queira utilizar outro banco de dados, que não mysql, será necessário alterar o drive na variável DB_CONNECTION.

Por exemplo, temos os seguintes drives disponiveis por padrão:

• Mysql: mysql;
• Sqlite: sqlite (Se for usar sqlite, comente com # as linhas HOST, DATABASE, USERNAME E PASSWORD e crie um arquivo database.sqlite na pasta database);
• PostgresSql: pgsql;
• SQL Server: sqlsrv;
• MariaDB: mariadb.

Ao alterar seu drive você pode rodar o php artisan migrate novamente e caso teu banco não exista o Laravel perguntará se você deseja que ele crie e assim as migration serão executadas.

Sempre que formos rodar as migrações em nosso projeto, e repetindo, o comando será:

1 php artisan migrate

Veja a imagem abaixo, ele é da versõa anterior do livro mas representa bem o resultado de migratons executadas na base. O log de sucesso será sempre neste caminho:

Se você for na sua base de dados, encontrará a tabela migrations como comentei anteriormente. Nesta tabela está registrada as migrations já executadas em nosso projeto:

E é claro as tabelas também foram criadas e estão em nosso banco agora e o número de tabelas é maior pois o Laravel resumiu várias execuções por arquivo e não mais um arquivo por criação de tabela, como é visto na própria migration de users.

Mas, você me pergunta, como posso criar minhas migrações para tabelas do meu projeto? Certo, vamos fazer isso agora!

Criando Nossas Migrações

Primeiro passo é irmos ao nosso terminal e executarmos o comando para geração de nosso primeiro arquivo de migração:

1 php artisan make:migration create_products_table

O comando acima criará nosso primeiro arquivo de migração dentro da pasta de migrações, chamado de 2025_03_25_150613_create_products_table.php, o nome do arquivo de migração respeita a data de criação e o nome escolhido, em nosso caso: create_products_table.

Essa definição da data e timestamp, do momento de geração desta migration, permite o Laravel organizar a ordem das migrações e a linha em que elas devem ser executadas, no caso, sempre da mais antiga para a mais nova/recém criada.

Um ponto interessante é que, como colocamos o nome da migração como create_products_table, o Laravel automaticamente preenche o conteúdo dos métodos up e down, da migration, e adiciona algumas colunas base para a tabela, como id e a definição para as colunas created_at e updated_at.

Isso facilita muito nossa vida durante o desenvolvimento. Veja abaixo:

 1 <?php
 2 
 3 use Illuminate\Database\Migrations\Migration;
 4 use Illuminate\Database\Schema\Blueprint;
 5 use Illuminate\Support\Facades\Schema;
 6 
 7 return new class extends Migration
 8 {
 9     /**
10      * Run the migrations.
11      */
12     public function up(): void
13     {
14         Schema::create('products', function (Blueprint $table) {
15             $table->id();
16             $table->timestamps();
17         });
18     }
19 
20     /**
21      * Reverse the migrations.
22      */
23     public function down(): void
24     {
25         Schema::dropIfExists('products');
26     }
27 };

Agora vamos as nossas adições, a adição dos nossos campos para nossa tabela de produtos. Criaremos os seguintes campos:

• name: string 255;
• description: string 255;
• body: text;
• price: integer; //irei explicar em breve como vamos manipular
• in_stock: interger;
• slug: string 255;
• is_active: boolean.

Veja abaixo o código a ser adicionado após o método id, na migração:

1     $table->string('name');
2     $table->string('description');
3     $table->text('body');
4     $table->integer('price');
5     $table->integer('in_stock');
6     $table->string('slug');
7     $table->boolean('is_active');

Simples, acima realizamos as definições dos nossos campos. Agora estamos aptos a executar esta migração em nosso banco de dados, para isso vamos ao nosso terminal executar o comando que já conhecemos.

Veja abaixo:

1 php artisan migrate

Ao executarmos o comando acima novamente, o Laravel só executará as migrações que ainda não foram executadas, por isso que temos o registro na tabela migrations feita automaticamente pelo framework. Veremos que apenas a migração para a tabela de produtos é que será executada desta vez.

Veja o resultado:

Este processo de trabalho com migrations será parte do seu desenvolvimento e mais a frente dedicaremos um capítulo aos relacionamentos na base e dentro dos models (que ainda veremos também).

É importante salientar que aqui na camada de banco é importante que você entenda bem desta parte para lhe dá melhor no que se trata a tua base de dados e as facilidades que o framework traz para você.

O Laravel possui definições, a partir do Blueprint, de tudo que é necessário para o mapeamento dos tipos das tuas colunas, configuração de CONSTRAINTS e muito mais. Lembrando que pro processo reverso também temos métodos especificos para remover chaves estrangeiras, remover colunas etc, ou seja, nas migrações temos o aparato necessário para a tratativa estutural do nosso banco de dados.

Por hora vamos aos seeds e as factories.

Seeds

Quando estamos em nosso ambiente de desenvolvimento sempre precisamos de dados no banco para testes e como sabemos, isso é um saco durante o processo de desenvolvimento. Os seeds nos permitem automatizar este processo simplificando nosso trabalho. Podemos, por meio das seeds, alimentar nosso banco de dados com informações para que possamos testar nossos CRUDs por exemplo.

Você pode encontrar os seeds do sistema dentro da pasta database/seeders, dentro desta pasta você vai encontrar o arquivo DatabaseSeeder.php que é o arquivo principal que executa todas as outras seeds que tivermos nesta pasta ou pode concentrar nele as execuções diretamente.

Veja seu conteúdo atual do arquivo:

 1 <?php
 2 
 3 namespace Database\Seeders;
 4 
 5 use App\Models\User;
 6 // use Illuminate\Database\Console\Seeds\WithoutModelEvents;
 7 use Illuminate\Database\Seeder;
 8 
 9 class DatabaseSeeder extends Seeder
10 {
11     /**
12      * Seed the application's database.
13      */
14     public function run(): void
15     {
16         // User::factory(10)->create();
17 
18         User::factory()->create([
19             'name' => 'Test User',
20             'email' => 'test@example.com',
21         ]);
22     }
23 }

Perceba a linha comentada //User::factory(10)->create();: esta linha é um exemplo para a chamada de uma factory, que nos permite gerar dados fakes em massa.

Já o trecho abaixo, que também é uma chamada de factory:

1 User::factory()->create([
2     'name' => 'Test User',
3     'email' => 'test@example.com',
4 ]);

Cria apenas um usuário, baseado na classe factory UserFactory da pasta database/factories, diretamente na base de dados, claro preciso executar o comando para rodar a seed e veremos em breve.

Vamos criar dois arquivos de seed para este momento, primeiro o arquivo que já temos referenciado acima, o UsersTableSeeder e também vamos criar o ProductsTableSeeder.

Tá! Mas como podemos criar isso? Eu te mostro, é bem simples!

Execute os comandos abaixo, primeiro executando a geração de um, depois do outro:

1 php artisan make:seeder UsersTableSeeder

Após a execução acima, execute a criação do outro arquivo seeder:

1 php artisan make:seeder ProductsTableSeeder

Veja o resultado:

Após a criação, veja que temos dois arquivos, a mais, criados dentro da pasta de seeders, o UsersTableSeeder.php e também o ProductsTableSeeder.php.

Agora o que faremos com eles?

Podemos utilizar ambos os arquivos de seed para gerarmos 1 usuário e 1 produto para nossa base. Como fazer isso?

Abra o arquivo UsersTableSeeder.php e adicione o código abaixo no método run:

1 DB::table('users')->insert([
2     'name'     => 'Primeiro Usuário',
3     'email'    => 'email@email.com',
4     'password' => bcrypt('secret')
5 ]);   

PS.: Não esqueça de add o namespace pro DB: use Illuminate\Support\Facades\DB;

Acima temos o primeiro contato com o objeto DB, que nos permite a execução de queries SQL no mais baixo nível, em relação a parte do ORM que veremos mais a frente. Nele informo a tabela que quero realizar a inserção do dado, por meio do método table e logo após, aninhando, chamo o método insert informando um array associativo, respeitando as colunas como chave e seus valores a serem salvos.

Perceba que no campo de senha do usuário utilizo o helper bcrypt para encryptar a senha do nosso usuário.

Após isso adicione o conteúdo do método run do ProductsTableSeeder:

1 DB::table('products')->insert([
2     'name'       => 'Primeiro Produto',
3     'description' => 'Produto teste com seeds',
4     'body'     => 'Conteúdo do Produto',
5     'in_stock'    => 34,
6     'price'       => (14.99 * 100),
7     'is_active'   => 1,
8     'slug'        => 'primeira-produto'
9 ]);

Agora vamos voltar lá no DatabaseSeeder e adicionar a chamada para estas duas classes Seed, que acabamos de criar e definir: UsersTableSeeder & ProductsTableSeeder.

O conteúdo do arquivo DatabaseSeeder ficará assim, veja ele todo na íntegra abaixo:

 1 <?php
 2 
 3 namespace Database\Seeders;
 4 
 5 use App\Models\User;
 6 // use Illuminate\Database\Console\Seeds\WithoutModelEvents;
 7 use Illuminate\Database\Seeder;
 8 
 9 class DatabaseSeeder extends Seeder
10 {
11     /**
12      * Seed the application's database.
13      */
14     public function run(): void
15     {
16         // User::factory(10)->create();
17 
18         // User::factory()->create([
19         //     'name' => 'Test User',
20         //     'email' => 'test@example.com',
21         // ]);
22 
23         //Chamada dos nosso seeders
24         $this->call(UsersTableSeeder::class);
25         $this->call(ProductsTableSeeder::class);
26     }
27 }

Este passo feito, vamos ao terminal e conhecer mais um comando. Desta vez para execução dos nossos seeds, alimentando dados em nossa base.

Em seu terminal e na raiz do projeto execute o comando abaixo:

1 php artisan db:seed

Veja o resultado:

Se você for ao seu banco e consultar as tabelas verá que os dados foram criados corretamente como definimos nas classes de seed.

Se precisarmos de mais dados, como por exemplo, inserir 30 produtos e fazer isso só com seeds teríamos um trabalho colossal mas este trabalho se simplifica por meio do que chamamos de Model Factories.

Então vamos crescer mais dentro do Laravel conhecendo mais esta funcionalidade que nos auxilia neste camada/etapa do desenvolvimento.

Vamos continuando…

Factories

Quando precisamos realizar a geração de muitos dados de forma mais automatizada podemos utilizar as Factories ou Model Factories para realizar este trabalho.

Aqui, de certa forma, teremos algum contato sobre models mas não vou me ater a eles (Models) no momento, pois o próximo capítulo será sobre esta camada e o tratamento com banco de dados. Como precisamos de models, para uso das Factories, na geração automatizada de dados para nossa aplicação, vou começar primeiramente com o model que já vem no projeto recém criado, o model Users.

As factories definem as regras para criação de dados fictícios em nossas tabelas, com base no model escolhido e conforme a quantidade especificada. No fim das contas, são chamados de factories ou fábricas por serem um esboço para criação de dados e junto com os seeds realizamos a inserção dos dados na base.

Você pode encontrar os arquivos de factories na pasta database/factories.

Nesta pasta já temos um arquivo de factory, o UserFactory.php. Veja o conteúdo dele abaixo:

 1 <?php
 2 
 3 namespace Database\Factories;
 4 
 5 use Illuminate\Database\Eloquent\Factories\Factory;
 6 use Illuminate\Support\Facades\Hash;
 7 use Illuminate\Support\Str;
 8 
 9 /**
10  * @extends \Illuminate\Database\Eloquent\Factories\Factory<\App\Models\User>
11  */
12 class UserFactory extends Factory
13 {
14     /**
15      * The current password being used by the factory.
16      */
17     protected static ?string $password;
18 
19     /**
20      * Define the model's default state.
21      *
22      * @return array<string, mixed>
23      */
24     public function definition(): array
25     {
26         return [
27             'name' => fake()->name(),
28             'email' => fake()->unique()->safeEmail(),
29             'email_verified_at' => now(),
30             'password' => static::$password ??= Hash::make('password'),
31             'remember_token' => Str::random(10),
32         ];
33     }
34 
35     /**
36      * Indicate that the model's email address should be unverified.
37      */
38     public function unverified(): static
39     {
40         return $this->state(fn (array $attributes) => [
41             'email_verified_at' => null,
42         ]);
43     }
44 }

As Factories, no Laravel desde a v8, receberam diversos incrementos e o primeiro deles é a estrutura de classe que foi adicionada em sua escrita. Antes as factories eram arquivos php com o código definido de forma imperativa.

Esta classe factory, do UserFactory, e outras classes que iremos gerar no futuro, são bem tranquilas de entender. Primeiramente o Laravel faz o autodiscover da classe de factory por meio do padrão <Model>Factory e sempre que precisarmos executar a criação destes dados fazemos por meio do model, que recebe uma trait pra lhe dá corretamente com a sua classe factory.

No método definition, podemos definir o esboço para geração dos nossos dados fakes, perceba que o array retornado neste método respeita exatamente a estrutura da tabela users. É importante ressaltar que os dados fakes são gerados pelo pacote Faker que já está associado na classe base a qual nossa classe factory extende e este pacote faker nos permite gerar todo tipo de dado falso(pra testes), como números de telefone, nomes, frases, textos e muitos mais.

Esta classe UserFactory, possui ainda mais um método que se utiliza do pensamento de estado durante a execução desta factory, que foi adicionado as factories no Laravel 8. Basicamente podemos criar métodos que podem ser chamados durante a execução desta factory de forma a gerar x dados com status específicos, como você pode ver exatamamente na ideia do método unverified. Posso criar x usuários com o status de email não verificado.

PS.: Sempre que precisar de dados fake para sua coluna em questão, dê uma olhada nas possibilidades disponiveis no link https://github.com/fzaninotto/Faker#formatters.

Como podemos executar esta factory existente?

Vamos ver a seguir.

Model Factories com Seeds

Como comentado, vamos executar nossa inserção de dados utilizando o dado esboçado pela factory. Como o título do trecho diz, precisamos combinar a geração dos dados, utilizando a factory, junto com a execução via seeds. Agora, vamos alterar nosso UsersTableSeeder para utilizar as factories.

Comente o conteúdo do método run do UsersTableSeeder e adicione a chamada abaixo:

1 \App\Models\User::factory(10)->create();

Ao invés de usarmos o objeto DB, como fizemos anteriormente, chamaremos a partir do model User o método factory, que recebe como parâmetro a quantidade de dados que queremos criar, neste caso 10 e logo após podemos chamar o método create que é quem irá de fato alimentar a tabela com estes dados.

Depois desta definição na classe UsersTableSeeder vamos ao terminal e vamos rodar somente o seed para a classe de seed de usuário.

Para isto execute o comando abaixo:

1 php artisan db:seed --class=UsersTableSeeder

Resultado:

Acima conhecemos mais uma possibilidade dos seeds, podemos executar seeds especificando a classe que queremos executar, em nosso caso apenas o conteúdo do UsersTableSeeder informando o parâmetro --class e o nome da classe.

Se você for ao seu banco, além do dado que já haviamos inserido no momento anterior com o seed, você verá mais 10 registros que foram gerados neste último comando, por meio da execução da factory via execução dos seeds. Perceba que isso simplifica bastante nossas vidas, pois se quisermos mais dados fakes, basta definirmos a quantidade desejada no parâmetro do método factory.

Por hora sobre factories e seeds é o que queria mostrar dado o escopo do nosso capítulo, em breve, nos próximos capítulos trabalharemos mais com estas camadas quando começarmos a focar nos conhecimentos dos Models e darmos largada de vez ao nosso app exemplo aqui do livro.

Migrations! Revertendo coisas!

Agora que já conhecemos como criar tabelas e como alimentá-las com dados falsos para nosso desenvolvimento, vamos entender como podemos reverter as coisas quando tratamos das migrações e suas criações e alterações.

Primeramente caso precisemos voltar o último lote de migrações executados, podemos usar o comando abaixo:

1 php artisan migrate:rollback

O comando migrate:rollback, como comentado, desfará tudo que as migrações do último lote de execução fizeram. Em nosso caso, foi a criação da tabela de produtos. Você pode voltar também as execução por meio de passos, informando o parâmetro --step:

1 php artisan migrate:rollback --step=2

Neste caso acima, ele desfará as duas migrações mais recentes, nesse desfazer de coisas que o método down da migration faz em suas definições.

Lembrando que nos processos de reverter coisas em migrations os métodos down é que serão chamadas e executados das migrações mais novas para as mais antigas.

Podemos ainda realizar operações em cima de todas as migrações, desfazendo-as, de uma vez só com o comando abaixo:

1 php artisan migrate:reset

O comando desfará todas as migrações executadas em sua base, deixando apenas a tabela migrations mas vazia. Caso queiramos resetar e re-executar as migrações novamente de uma vez só, podemos executar o comando abaixo:

1 php artisan migrate:refresh

Ou ainda executar tudo do zero novamente com o comando fresh, que apaga todas as tabelas e executa as migrations novamente:

1 php artisan migrate:fresh

Este comando acima, o migrate:fresh, executa um drop table na base antes de re-executar as migrations então tome cuidado caso tenha tabelas que não estão mapeadas por migrations, pois com o drop elas podem ser removidas e este ponto é o que diferencia o fresh do refresh.

O refresh faz um rollback e re-executa as migrações sem mexer na base no que diz respeito a coisas fora das migrações e o fresh faz um drop (ALL) table para poder executar as migrações novamente.

Refresh com execução de seeds

Caso queira voltar todos os passos executados nas migrations e na re-execução, executar as seeds junto, podemos informar o parâmetro --seed como opção ao comando refresh.

Veja abaixo:

1 php artisan migrate:refresh --seed

Com isso teremos a execução reversa das migrações, sua re-execução e ainda a execução das seeds no banco de dados. Veja o resultado do comando abaixo:

Isso facilita muito nossas vidas!

Podemos usar o parâmetro --seed tanto no migrate:refresh, como no migrate:fresh e também na execução do comando migrate.

Conclusões

Bom, este capítulo foi bem denso e trabalhoso mas com muitas vantagens demonstradas pelo framework Laravel. Recomendo fortemente que você execute bastante os comandos aprendidos aqui e teste cada nuance dos comandos para reverter coisas no banco via migrations.

No próximo capítulo vamos subir o nível de utilização da camada de banco, tratando diretamente com os Models e suas representações.

Então até lá!

Eloquent, trabalhando com Models

Continuando nosso trabalho com a camada de dados e persitência, vamos subir o nível, conhecendo a camada dos models e como podemos trabalhar buscas, inserções, atualizações, remoções via objetos.

Vamos começar primeiro pelas queries e ir crescendo nosso conhecimento no decorrer deste capítulo. Para isto vamos usar nosso controller ProductController que se encontra dentro da pasta Admin em controllers.

Mas antes…

Os Models!

No Laravel, os models são a representação, do ponto de vista de objetos, das tabelas do nosso banco de dados.

Por exemplo, por convenção do framework, se eu tenho uma tabela chamada products na base, a representação em model desta tabela será uma classe chamada de Product. Se eu tenho uma tabela users, sua representação via model será uma classe chamada de User.

O Laravel automaticamente tentará, por convenção, resolver sua tabela no plural por ter o pensamento, na base, de uma coleção de dados, ou seja, se tenho um model Product e como comentado, o Laravel tentará buscar os dados da tabela products.

É possível mudar essa mágica do framework, sobscrevendo a propriedade protegida $table dentro do model que deseja mudar, colocando o nome da sua tabela caso ela não siga a convenção do plural resolvida pelo Laravel.

Vamos começar a entender como interagir com os dados.

Por exemplo, como posso pegar todos as postagens via Model? Para isto temos um método chamada de all que faz este trabalho para nós.

Por exemplo:

1 return \App\Models\Product::all();

O resultado do método acima se fossemos pensar em uma query na base, seria uma sql como esta:

1 select * from products

Lembrando que ainda não criamos nosso primeiro model, então vamos a esta tarefa. Execute na raiz do projeto o seguinte comando gerador:

1 php artisan make:model Product

Veja o conteúdo do model abaixo:

 1 <?php
 2 
 3 namespace App\Models;
 4 
 5 use Illuminate\Database\Eloquent\Model;
 6 
 7 class Product extends Model
 8 {
 9     //
10 }

Veja nosso model acima, bem simples inclusive, basicamente todo o processo para manipular o banco é herdado da classe Model, do Eloquent que é o ORM responsável por trabalhar esta camada de Objeto para o Relacional do Banco de Dados.

Neste model, caso tivessemos gerado a factory junto, ele viria com a trait para manipulação das factories, factories essas que vimos anteriormente aqui na jornada.

Se, por ventura, você quiser utilizar um nome de tabela de sua escolha e não quiser que o Laravel resolva o nome dela de forma mágica, você pode sobscrever o atributo $table dentro do seu model como mostrado no conteúdo abaixo:

 1 <?php
 2 
 3 namespace App\Models;
 4 
 5 use Illuminate\Database\Eloquent\Model;
 6 
 7 class Product extends Model
 8 {
 9     protected $table = 'nome_da_sua_tabela';
10 }

Acima ao invés do Laravel tentar encontrar a tabela no plural ele pegará o valor do atributo $table.

Deixarei o conteúdo acima para exemplo mas utilizarei a convenção em nossos models sem a utilização do atributo $table.

Certo mas então o que é o Eloquent?

Eloquent?

O Eloquent é o ORM padrão do Laravel, é a camada, via objetos, para manipulação dos dados de seu banco. O ORM é a camada que traduz sua estrutura de objetos, Models, para a camada relacional do seu banco de dados.

Veja um exemplo de inserção de um produto utilizando o Eloquent:

 1 //O códiga poderia está em um método do controller
 2 
 3 $product = new \App\Models\Product();
 4 $product->name       = 'Product salvo com eloquent e active record';
 5 $product->description = 'Descrição product';
 6 $product->body     = 'Conteúdo do product';
 7 $product->slug        = 'product-salvo-com-eloquent-e-active-record';
 8 $product->in_stock    = 30;
 9 $product->price       = (299.90 * 100);
10 $product->is_active   = true;
11 
12 //Aqui a inserção do produto é , de fato, realizado na tabela.
13 $product->save(); 

Veja como é simples, dou inicio uma nova instância de Product , chamo as colunas como atributos do objeto e por fim para salvar os dados atribuídos a cada um dos atributos, utilizo o método save do model para realizar a operação de criação do nosso produto.

Aqui no livro vou abordar mais conceitos do Eloquent de forma prática e pontuando os comportamentos. Me utilizarei, para salvar e atualizar os dados, do conceito de Mass Assignment que explicarei mais a frente.

PS.: Antes de prosseguirmos, recomendo fortemente a leitura sobre Active Record caso queira conhecer esse padrão, o modelo de inserção apresentado acima se utiliza deste padrão. Padrão este que têm muitos contras por parte da comunidade mas vale o conhecimento toda via.

Eloquent na prática

Lembra que já temos um controller para utilização e criação de um CRUD para produtos?

Por meio deste CRUD vamos focar nos pontos mais cruciais para você conhecer o trabalho do Eloquent em nossas aplicações. Nosso controller encontra-se na pasta dos controllers, dentro da pasta Admin e o controller ProductController.

Primeiramente vamos definir nosso método index. Trabalhando do ponto de vista dos models eu consigo realizar operações de busca dos dados em minhas tabelas, como mostrado anteriormente posso buscar todos os registros do banco de dados por meio do método all.

Trecho abaixo:

1 return \App\Models\Product::all();

Ou posso retornar os dados paginados, para exibição em uma tabela html na view. Então vamos começar a implementar o método index no controller ProductController que está na pasta Admin.

Veja o conteúdo dele abaixo:

1 public function index()
2 {
3 	$products = Post::paginate(15);
4 
5 	dd($products); //no próximo capítulo vamos mandar para view...
6 }

Veja o código acima, por enquanto, ainda não vamos utilizar a view, retornaremos a ela e os pontos do Blade no próximo capítulo. Voltando ao código acima, perceba que chamei o Product::paginate, informando que quero 15 produtos, neste caso, os dados vão vir do banco paginados e teremos os 15 produtos por cada tela da paginação.

Não esqueça de importar o Model Product em seu controller:

1 use App\Models\Product;

Agora, vamos lá no arquivo de rotas e realizar uma pequena alteração no que já havíamos feito, para o conjunto de rotas de produto, então, o que está assim:

 1 Route::prefix('admin')->group(function () {
 2 
 3     Route::prefix('products')->name('products.')->group(function () {
 4 
 5         Route::get('/create', [\App\Http\Controllers\Admin\ProductController::class,\
 6  'create'])->name('create');
 7 
 8         Route::post('/store', [\App\Http\Controllers\Admin\ProductController::class,\
 9  'store'])->name('store');
10     });
11 });

Vamos atualizar para a chamada do controller como recurso, ficando como vemos abaixo:

1 Route::prefix('admin')->group(function(){
2 
3 	Route::resource('products', \App\Http\Controllers\Admin\ProductController::class);
4 
5 });

Perceba, que agora simplificamos mais ainda nossas rotas dentro do grupo para o admin. Quando trabalhamos no capítulo sobre request e response, os métodos create e store, que já existem no controller, foram pensados já para deixá-los no pensamento do método resource e os controllers como recurso.

Se você for ao seu browser agora e acessar http://127.0.0.1:8000/admin/products você verá o resultado abaixo:

Veja que expandi o atributo items e seu nivel a dentro, onde temos a coleção de dados retornada. Veja que tivemos 1 item retornado, em nosso caso o produto criado durante o aprendizado de seeds.

Quandos se trata de navegação nos dados paginados o passo é bem simples, basta informarmos na url o parâmetro page=<pagina-que-queremos> (como querystring) por exemplo.

O retorno do método paginate do eloquent, e como podemos ver na imagem anterior, é um objeto do tipo Illuminate\Pagination\LengthAwarePaginator que dentre muitos detalhes possui também o método para exibir a paginação em nossas telas na camada de views.

Quando formos trabalhar com as views e o Blade, veremos uma forma simples de criar a páginação no frontend, simplificando esta navegação.

Buscando apenas um produto

Para buscarmos dados específicos, podemos trabalhar com diversos métodos. Por exemplo, se você quiser buscar um produto pelo id dele, você pode usar o método find.

Veja:

1 Product::find(1);

Ou ainda, buscando pelo id, você pode usar o método findOrFail, que caso o Eloquent não encontre o produto em questão, irá lançar uma Exception causando um 404 NOT Found. Podemos usar desta maneira:

1 Product::findOrFail(1);

Vamos criar agora o método em nosso controller ProductController para recuperação de um produto, para nossa tela de edição. Veja o conteúdo do método edit e já adicione ele em seu controler:

1 public function edit($product)
2 {
3 	$product = Product::findOrFail($product);
4 
5 	dd($product); //em breve mandaremos pra view
6 }

Usarei o findOrFail para termos o melhor controle para quando o produto não for encontrado, comportamento mencionado anteriormente. Já aproveite e adicione o método show no controller e nele apenas vamos redirecionar para a tela de edição uma vez que não teremos uma tela de visualização de um produto específico.

1 public function show($product)
2 {
3     return redirect()->route('products.edit', ['product' => $product]);
4 }

Abaixo eu destaco só o atributo original que traz o dados retornados do método findOrFail, visualizamos acessando http://127.0.0.1:8000/admin/products/1/edit:

Nosso controller até o momento está abaixo, com os dois métodos criados no capítulo sobre requests e junto do index, edit e o show criados agora.

Veja na íntegra:

 1 <?php
 2 
 3 namespace App\Http\Controllers\Admin;
 4 
 5 use App\Http\Controllers\Controller;
 6 use App\Models\Product;
 7 use Illuminate\Http\Request;
 8 
 9 class ProductController extends Controller
10 {
11     public function index()
12     {
13         $products = Product::paginate(15);
14 
15         dd($products); //no próximo capítulo vamos mandar para view...
16     }
17 
18     public function create()
19     {
20         return view('products.create');
21     }
22 
23     public function store(Request $request)
24     {
25         dd($request->all());
26     }
27 
28     public function show($product)
29     {
30         return redirect()->route('products.edit', ['product' => $product]);
31     }
32 
33     public function edit($product)
34     {
35         $product = Product::findOrFail($product);
36 
37         dd($product); //em breve mandaremos pra view
38     }
39 }

Agora vamos ao método store pois nele vamos trabalhar a inserção de dados propriamente dita!

Inserindo dados com Eloquent

Como mencionei anteriormente, poderíamos utilizar a criação de dados usando Active Record, por meio da referência dos atributos dinâmicos, baseado nas colunas do banco para aquela tabela (produtos) e por meio do método save criar um dado.

Como estamos tratando aqui de criação, vou mostrar a título de conhecimento o salvar dos dados usando Active Record dentro de nosso método, veja como ficaria.

Altere o conteúdo do método store, já existente, para o conteúdo abaixo:

 1 public function store(Request $request)
 2 {
 3     $data = $request->all();
 4 
 5     /**
 6     Preço recebido, exe.: 19,99 -> passa pelo replace -> 19.99 e salvamos ele como i\
 7 nteiro multiplicando por 100 jogando as casa decimais 2 casas para direita.
 8     */
 9     $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
10 
11     $product = new Product();
12 
13     $product->name        = $data['name'];
14     $product->description = $data['description'];
15     $product->body        = $data['body'];
16     $product->in_stock    = 48; //está fixo mas vamos adiciona-lo no formulário ainda
17     $product->price       = $price * 100;
18     $product->slug        = $data['slug'];
19     $product->is_active   = true;
20 
21     dd($product->save()); //veja o resultado no browser
22 }

Veja que agora pego os dados de cada campo a partir da request, vindas do formulário, e repasso para cada atributo de nosso model e na chamada do método save nós criamos este produto na base.

PS.: Aqui no ebook irei trabalhar o preço dos produtos como inteiro para termos mais precisão nas ações de lidar com as manipulações em produtos, por isso faço o replace que seria feito de fato para salvar o dado como float mas aqui estamos trabalhando com inteiro, então, multiplicamos por 100 esse preço ao salvar o dado, movendo a virgula duas casa para a direita deixando nosso preço como inteiro.

PS2.: Em breve vamos delegar estas manipulações para nosso model para limpar melhor nossos controllers e ao recuperar o dado vamos trabalhar ele de forma flutuante com precisão 2, para isso vamos dividir o preço por 100 trazendo a vírgula 2 casa para esquerda.

Para testarmos, vamos ao nosso link http://127.0.0.1/admin/products/create e envie os dados via form. Veja o resultado na imagem abaixo:

Perceba que o resultado do método save foi o valor boleano true, confirmando assim a criação do registro em nossa base. Se você quiser atualizar um registro usando Active Record, basta, ao invés de instanciar um model post, passar o resultado de um find por exemplo ou um dado buscado na base:

 1 $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
 2 
 3 $product = Product::findOrFail(1);
 4 
 5 $product->name        = $data['name'];
 6 $product->description = $data['description'];
 7 $product->body        = $data['body'];
 8 $product->in_stock    = 48; 
 9 $product->price       = $price * 100;
10 $product->slug        = $data['slug'];
11 $product->is_active   = true;
12 
13 dd($product->save()); //aqui ele vai atualizar

Como temos a referência na variável $product de um dado recém-buscado na base, ao chamarmos o método save o Eloquent irá atualizar este registro ao invés de criar um novo.

Lembrando que você, ao atualizar, pode chamar apenas as colunas que deseja atualizar o dado de fato.

Este trecho foi um rápido desmontrativo do Active Record no Eloquent, quero te mostrar uma técnica mais direta e que é mais utilizada hoje em dia dentro do Laravel, via Eloquent. Esta técnica é o que chamamos de Mass Assignment ou Atribuição em Massa.

Vamos conhecer esta técnica.

Mass Assignment

Mass Assignment ou Atribuição em Massa é uma forma de inserir ou atualizar os dados por meio de uma única chamada e de uma vez só quando necessitamos de realizar estas operações.

Por exemplo, eu poderia passar todo o array vindo da request e já salvar isso direto no banco por meio de um método do Eloquent, o método create.

Então vamos a alteração, mais uma vez, do nosso método store, que está assim:

 1 public function store(Request $request)
 2 {
 3     $data = $request->all();
 4 
 5     $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
 6 
 7     $product = new Product();
 8 
 9     $product->name        = $data['name'];
10     $product->description = $data['description'];
11     $product->body        = $data['body'];
12     $product->in_stock    = 48; //está fixo mas vamos adiciona-lo no formulário ainda
13     $product->price       = $price * 100;
14     $product->slug        = $data['slug'];
15     $product->is_active   = true;
16 
17     dd($product->save()); //veja o resultado no browser
18 }

Agora, passará a ficar assim:

 1 public function store(Request $request)
 2 {
 3     $data = $request->all();
 4 
 5     $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
 6 
 7     $data['in_stock']   = 48;
 8     $data['price']      = $price * 100;
 9     $data['is_active']  = true;
10 
11     dd(Product::create($data)); //veja o resultado no browser
12 }

Perceba a redução acima, ao invés de chamarmos cada atributo baseado na coluna de nossa tabela, chamamos apenas o método create passando para ele nosso array recuperado da request, lembrando que este array associativo respeita chave(coluna da tabela) e valor desta chave, o valor a ser inserido.

Se você for ao browser e testar isso enviando os dados do formulário, perceberá que teremos uma exception sobre a adição de um campo na propriedade $fillable do model, aqui entra um ponto importante.

Antes de comentar o erro, você pode está se perguntando: Esta atribuição em massa não pode ser problemática, já que ela pelo visto aceita tudo?!

Veja a exception lançada:

Para resolver a exception lançada acima, sobre o atributo $fillable e o seu questionamento ao mesmo tempo, nós precisamos de fato definir este bendito atributo $fillable lá no model, o model do momento Product.

Agora para que serve este atributo? Tecnicamente ele é bem simples.

Como estamos passando esta atribuição de uma vez só, precisamos indicar para o Model/Eloquent que ao salvarmos ou atualizarmos os dados usando a atribuição em massa quais são os atributos que ele deve permitir o passar dos valores a serem salvos na tabela representada pelo Model.

Não esqueça que o array associativo, passado ao métodos create, deve respeitar as colunas da tabela como chave de cada linha do array a ser inserido. No model definimos uma lista com as colunas/atributos permitdos na Atribuição em Massa, definindo a propriedade $fillable e apenas aqueles campos listado neste atributo é que receberão o valor a ser inserido.

Então vamos adicionar ele em nosso model Product e logo após comentarmos mais um pouco sobre este detalhe.

Veja a alteração em Product.php:

 1 <?php
 2 
 3 namespace App\Models;
 4 
 5 use Illuminate\Database\Eloquent\Factories\HasFactory;
 6 use Illuminate\Database\Eloquent\Model;
 7 
 8 class Product extends Model
 9 {
10     protected $fillable = [
11 		'name',
12 	    'description',
13 	    'body',
14 	    'slug',
15 	    'is_active',
16 	    'in_stock',
17         'price'
18     ];
19 }

Agora com os campos adicionados no atributo $fillable vamos enviar os dados novamente e atualizando o link com o erro anterior e clicando em reenviar no browser.

Veja o resultado do dd, vindo do método create do Eloquent, em nossa tela:

O método create ao criar um dado, retorna este dado criado junto com seu id na base como resultado populado no model em questão, aqui o model Product. Veja o conteúdo da informação abrindo a propriedade original.

A segurança do método create, usando a atribuição em massa, se dá pela propriedade $fillable no model que uma vez definida e tendo as colunas permitidas, só teremos o preechimento das informações para a coluna mapeada nesta propriedade.

Agora como fazemos a atualização do dados massa?

Vamos lá.

Atualizando Dados em Massa

Para atualizarmos os dados, vamos trabalhar aqui com nossa view de edição e conhecer mais alguns detalhes do Laravel, crie lá dentro da pasta resources/views/products o arquivo edit.blade.php e adicione o conteúdo abaixo:

 1 <form action="{{ route('products.update', ['product' => $product->id]) }}" method="p\
 2 ost">
 3 
 4     @csrf
 5     @method('PUT')
 6     <div class="w-full mb-6">
 7         <label class="block mb-2">Nome</label>
 8         <input type="text" name="name" class="w-full p-2 rounded" value="{{ $product\
 9 ->name }}">
10     </div>
11 
12     <div class="w-full mb-6">
13         <label>Descrição</label>
14         <input type="text" name="description" class="w-full p-2 rounded" value="{{ $\
15 product->description }}">
16     </div>
17 
18     <div class="w-full mb-6">
19         <label>Conteúdo</label>
20         <textarea name="body" id="" cols="30" rows="10" class="w-full p-2 rounded">{\
21 { $product->body }}</textarea>
22     </div>
23 
24     <div class="w-full mb-6">
25         <label>Preço</label>
26         <input type="text" name="price" class="w-full p-2 rounded" value="{{ number_\
27 format($product->price, 2, ',', '.') }}">
28     </div>
29 
30     <div class="w-full mb-6">
31         <label>Slug</label>
32         <input type="text" name="slug" class="w-full p-2 rounded" value="{{ $product\
33 ->slug }}">
34     </div>
35 
36     <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-white\
37  font-thin">Atualizar
38         Produto</button>
39 </form>

Agora, lá no método edit do ProductController substitua a linha do dd pelo trecho abaixo:

1 $product->price = $product->price / 100; //voltando pro ponto flutuante
2 
3 return view('products.edit', compact('product'));

Se você acessar o link http://127.0.0.1:8000/admin/products/1/edit você obterá o resultado abaixo:

Veja nosso formulário de edição acima já preenchido com os valores pegos do banco pelo Eloquent e enviados para a view.

Agora vamos entender os códigos do formulário de edição acima. Vamos lá.

Primeiramente atente a chamada da rota na action do formulário:

1 <form action="{{ route('products.update', ['product' => $product->id]) }}" method="p\
2 ost">

Enviaremos nossos dados para a rota de apelido products.update atribuída pelo método resource do Route, informamos o nome do parâmetro dinâmico da rota no array do segundo parâmetro da função helper route que será o id do produto, estes dados serão enviados para o método update lá do ProductController, que vamos criar ainda.

Temos agora mais uma alteração/novidade, a chamada da diretiva @method. Vamos entender ela:

Sabemos que os formulários html só suportam os verbos http: post e get. Por meio da diretiva @method fazemos o Laravel interpretar o formulário em questão com o verbo definido na diretiva, ou seja, como usei o valor PUT este formulário será interpretado pelo Laravel como sendo enviado via verbo PUT e cairá para a execução do método update do controller, que é o método que recebe as solicitações quando usamos o verbo PUT ou PATCH em nossa requisição.

Caso você ainda não tenha ouvido falar deste verbos HTTP além do GET e POST, basicamente o HTTP permite que realizemos requisições com mais contexto do que simplesmente recuperar(GET) e salvar (POST). Temos verbos HTTP para o pensamento de cada operação de manipulação de um dado, que normalmente chamamos de Recurso no âmbito da requisição. Os verbos HTTP mais conhecidos são:

• GET: traz o pensamento de recuperar um dado, basicamente sempre que acessamos um link na web usamos este verbo;
• POST: traz o pensamento de criação de um novo dado;
• PUT: traz o pensamento de atualizar um dado por completo;
• PATCH: traz o pensamento de atualizar partes de um dado;
• DELETE: o nome é intuitivo, traz o pensamento de remover um dado;
• OPTIONS: retorna os verbos aceitos em um determinado endpoint;

Continuando, agora em nossos inputs recebemos os valores vindos lá do controller e adicionado no atributo value de cada input. Quando fazemos uma busca pela postagem desejada, ele retorna um objeto populado com os dados desta postagem, o que nos resta é acessarmos eles respeitando os nomes das colunas mas chamando como atributos do objeto e isto pode ser visto em cada atributo value dos inputs do nosso formulário de edição.

Agora precisamos definir o método para manipulação dos dados enviados do formulário de edição, para isso crie um método chamado de update em seu controller com o conteúdo abaixo:

 1 public function update($product, Request $request)
 2 {
 3     //Atualizando com mass assignment
 4     $data = $request->all();
 5     $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
 6     $data['price'] = $price * 100;
 7 
 8     $product = Product::findOrFail($product);
 9     $product->update($data);
10 
11     return redirect()->route('products.edit', ['product' => $product->id]);
12 }

Perceba que busquei o produto usando o método findOrFail e passando o id vindo da url, no parâmetro dinâmico. Neste caso, como quero atualizar, o método para este processo em massa, é o método do eloquent chamado de update, que me retorna um booleano para o sucesso ou falha desta execução.

Você pode testar sua edição acessando http://127.0.0.1:8000/admin/products/<id-produto>/edit, o sucesso da atualização é o redirecionamento para a tela de edição então verifique se o dado que você atualizou persistiu atualizando a própria página do browser na tela de edição após submeter o formulário e ele redirecionar para a edição novamente.

Vamos ao passo final do CRUD, a remoção de um dado com Eloquent.

Deletando Registros

Bom, agora para completarmos nosso ciclo de CRUD, vamos deletar produtos de nossa base. Isso será realizado pelo método delete do Eloquent.

Veja o método abaixo a ser adicionado no ProductController:

1 public function destroy($product)
2 {
3     $product = Product::findOrFail($product);
4     
5     dd($product->delete());
6 }

O método do controller como recurso que responde a chamada para remoção de um dado é o destroy, entretanto, o método do Eloquent que irá remover um dado é o delete que retorna um boleano para o caso de sucesso ou falha da operação de remoção do dado na base.

Perceba que, como queremos remover uma postagem, precisamos buscar por ela via Eloquent para então removermos.

Agora precisamos adicionar o botão de remoção lá na tela de edição, neste caso como precisamos simular o envio do verbo http DELETE, vou precisar usar um form para o botão de remoção.

Adicione o form abaixo, após o formulário de edição:

1 <form action="{{route('products.destroy', ['product' => $product->id])}}" method="po\
2 st">
3     @csrf
4     @method('DELETE')
5     <button type="submit">Remover Produto</button>
6 </form>

Perceba também que temos adicionado o controle csrf para esta operação, além da definição da diretiva @method com o verbo http DELETE.

A tela de edição fica assim:

Ao clicar no botão remover, você verá o resultado na tela, true para sucesso na remoção ou false para o caso de falha. Após removido se tentarmos acessar a mesma postagem teremos uma tela de 404 em nossa cara:

Um pequeno e último detalhe ao invés de realizarmos um dd após o processo de remoção vamos redirecionar para a listagem de produtos. Veja o método destroy agora:

1 public function destroy($product)
2 {
3     $product = Product::findOrFail($product);
4     $product->delete();
5 
6     return redirect()->route('products.index');
7 }

Façamos o mesmo no método store, como retorno do método store coloque o redirect para a tela de edição do produto recém criado, como mostrado no método completo abaixo:

 1 public function store(Request $request)
 2 {
 3     $data = $request->all();
 4 
 5     $price = (float) str_replace(['.', ','], ['', '.'], $data['price']);
 6 
 7     $data['in_stock']    = 48; //está fixo mas vamos adiciona-lo no formulário ainda
 8     $data['price']       = $price * 100;
 9     $data['is_active']      = true;
10 
11     $product = Product::create($data);
12 
13     return redirect()->route('products.edit', ['product' => $product->id]);
14 }

Agora completamos as 4 etapas de um CRUD utilizando o Eloquent, que nos permite trabalhar com o banco pela visão de objetos.

Conclusões

Neste capítulo conhecemos diversas possibilidades usando o Eloquent, o ORM padrão do Laravel. Com isso realizamos a criação de um CRUD completo usando nosso Model Product por meio dos métodos disponíveis e herdados do Model do Eloquent, que nos permitiu realizar estas operações: seleção, criação, atualização e ainda remoção de produto no banco de dados.

Para completarmos o ciclo e deixarmos as coisas mais dinâmicas e integradas, precisamos conhecer o Blade, o famoso template engine do Laravel e que nos permite escrever views de forma mais dinâmica e rápida.

Conheceremos o Blade no próximo capítulo. Até lá!

Blade, Template Engine do Laravel

Olá tudo bem? Vamos continuar nosso livro e desta vez vamos conhecer o famoso template engine do Laravel, o Blade.

O Blade é o template engine default do Laravel e traz consigo diversas estruturas que simplificam muito nosso trabalho:

O Blade ao longo do tempo veio e vem recebendo diversos incrementos e pretendo mostrar, na prática, estas possibilidades usando seu poder para construirmos nossas views.

Então vamos criar as views de nossa aplicação utilizando o poder do Blade!

Layouts

Vamos começar pelo layout, em nosso Hello World com Laravel nós tivemos um contato com o blade quando mandamos nossa mensagem (Hello World) para a view e exibimos ela com o interpolador {{ }}, que nos permite exibir informações passadas a ele. Antes de entrarmos em pontos como este que comentei, vamos definir e organizar um template base usando o blade para melhor dispor as views do nosso painel.

Primeiramente crie uma pasta chamada de layouts dentro da pasta de views e dentro da pasta layouts crie o arquivo app.blade.php. Adicione o seguinte conteúdo e logo após farei os comentários:

 1 <!doctype html>
 2 <html lang="en">
 3 
 4 <head>
 5     <meta charset="UTF-8">
 6     <meta name="viewport"
 7         content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-sc\
 8 ale=1.0, minimum-scale=1.0">
 9     <meta http-equiv="X-UA-Compatible" content="ie=edge">
10     <title>Loja - Code Experts</title>
11     <script src="https://cdn.tailwindcss.com"></script>
12 </head>
13 
14 <body>
15     <nav class="w-full mb-10 flex justify-between bg-gray-900 px-4">
16         <a href="/" class="text-white py-4">Experts Store 12</a>
17         <ul>
18             <li class="py-4">
19                 <a href="{{ route('products.index') }}"
20                     class="text-white px-6 py-4 hover:bg-purple-800 transition ease-\
21 in-out duration-300">Produtos</a>
22             </li>
23         </ul>
24     </nav>
25     <div id="container" class="max-w-7xl mx-auto p-6">
26         <!-- Aqui será inserido o conteúdo das páginas filhas -->
27 
28         @yield('content')
29 
30         <!-- Aqui será inserido o conteúdo das páginas filhas -->
31     </div>
32 </body>
33 
34 </html>

Acima temos a definição do nosso layout base, aqui entramos no primeiro conceito do Blade, neste caso, na herança de templates. Se você perceber no layout, defini dentro do body na div#container uma diretiva chamada de @yield que me permite apontar onde os templates devem exibir seus conteúdos.

Por exemplo, vamos entender como isso funciona fazendo nossa view create.blade.php herdar do nosso layout app.blade.php. Veja as alterações que fiz na view create.blade.php:

 1 @extends('layouts.app')
 2 
 3 @section('content')
 4     <form action="{{ route('products.store') }}" method="post">
 5         @csrf
 6 
 7         <div class="w-full mb-6">
 8             <label class="block mb-2">Nome</label>
 9             <input type="text" name="name" class="w-full p-2 rounded border border-g\
10 ray-900" value="{{ old('name') }}">
11         </div>
12 
13         <div class="w-full mb-6">
14             <label>Descrição</label>
15             <input type="text" name="description" class="w-full p-2 rounded border b\
16 order-gray-900"
17                 value="{{ old('description') }}">
18         </div>
19 
20         <div class="w-full mb-6">
21             <label>Conteúdo</label>
22             <textarea name="body" id="" cols="30" rows="10" class="w-full p-2 rounde\
23 d border border-gray-900">{{ old('body') }}</textarea>
24         </div>
25 
26         <div class="w-full mb-6">
27             <label>Preço</label>
28             <input type="text" name="price" class="w-full p-2 rounded border border-\
29 gray-900"
30                 value="{{ old('price') }}">
31         </div>
32 
33         <div class="w-full mb-6">
34             <label>Slug</label>
35             <input type="text" name="slug" class="w-full p-2 rounded border border-g\
36 ray-900"
37                 value="{{ old('slug') }}">
38         </div>
39 
40         <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-w\
41 hite font-thin">Criar Produto</button>
42     </form>
43 @endsection

O trecho de template acima, além da adição dos trecho de herança, eu adicionei algumas classes nos inputs para exibir uma borda neles. Lembre de pegar este código e atualizar em seu projeto.

Aqui temos o conteúdo do formulário envolvido por uma diretiva chamada de @section que recebe o valor content e a definição de onde essa diretiva termina, indicada pelo @endsection. O que isso quer dizer?!

A diretiva @section define o conteúdo que será substituido no layout principal, ou seja, quando eu acessar essa view ele vai herdar o que tem em app.blade.php e onde eu defini o @yield('content') , será adicionado o conteúdo que temos na diretiva @section, no caso da view create.blade.php o que estiver na section content e exibirá o conteúdo do formulário junto do layout base.

Mas Nanderson, onde está definido que o create.blade.php herda de layout.blade.php? Não comentei de propósito mas ele se encontra como sendo a primeira linha da nossa view, veja a definição que aponta de qual template create.blade.php herda, por meio da diretiva @extends, o layout pai. Neste caso digo que a view create.blade.php herda de app.blade.php informando a diretiva @extends da seguinte maneira: @extends('layouts.app').

Sendo que layouts é a pasta dentro de views e app o arquivo app.blade.php, onde sabemos que o Laravel irá incluir a extensão internamente e linkar o caminho completo até a pasta layouts.

Alterei também a view edit.blade.php, segue o conteúdo:

 1 @extends('layouts.app')
 2 
 3 @section('content')
 4 <form action="{{ route('products.update', ['product' => $product->id]) }}" method="p\
 5 ost">
 6         @csrf
 7         @method('PUT')
 8         <div class="w-full mb-6">
 9             <label class="block mb-2">Nome</label>
10             <input type="text" name="name" class="w-full p-2 rounded border border-g\
11 ray-900" value="{{ $product->name }}">
12         </div>
13 
14         <div class="w-full mb-6">
15             <label>Descrição</label>
16             <input type="text" name="description" class="w-full p-2 rounded border b\
17 order-gray-900"
18                 value="{{ $product->description }}">
19         </div>
20 
21         <div class="w-full mb-6">
22             <label>Conteúdo</label>
23             <textarea name="body" id="" cols="30" rows="10" class="w-full p-2 rounde\
24 d border border-gray-900">{{ $product->body }}</textarea>
25         </div>
26 
27         <div class="w-full mb-6">
28             <label>Preço</label>
29             <input type="text" name="price" class="w-full p-2 rounded border border-\
30 gray-900"
31                 value="{{ number_format($product->price, 2, ',', '.') }}">
32         </div>
33 
34         <div class="w-full mb-6">
35             <label>Slug</label>
36             <input type="text" name="slug" class="w-full p-2 rounded border border-g\
37 ray-900"
38                 value="{{ $product->slug }}">
39         </div>
40 
41         <button class="px-4 py-2 bg-green-700 border border-green-900 rounded text-w\
42 hite font-thin">Atualizar
43             Produto</button>
44     </form>
45 
46     <form action="{{ route('products.destroy', ['product' => $product->id]) }}" meth\
47 od="post">
48         @csrf
49         @method('DELETE')
50         <button type="submit" class="px-4 py-2 bg-red-700 border border-red-900 roun\
51 ded text-white font-thin mt-8">Remover
52             Produto</button>
53     </form>
54 @endsection

Alterei as bordas dos inputs aqui também além de adicionar alguns estilos no button do form de remoção.

Veja o formulário na íntegra na imagem abaixo:

Aqui já temos alguns estilos aplicados por conta que desde o ínicio nosso form já possuía algumas classes utilitárias do TailwindCSS(tailwindcss.com), não comentarei muito dele aqui neste ebook mas tentarei na maior parte das vezes explicar os trechos que forem importantes e claro, se você conhece bem CSS o tailwindcss será algo mais tranquilo pra você.

Lá no Layout base, o app.blade.php, por hora mantêm o link do cdn do tailwindcss. O trecho do layout base que uso o cdn é destacado abaixo:

1 <script src="https://cdn.tailwindcss.com"></script> 

Agora vamos para a nossa listagem dos produtos e conhecer mais possibilidades do Blade.

Laços de Repetição & Condicionais

Sabemos que para iterarmos em cima de uma coleção de dados precisamos usar laços de repetição, o Blade nos traz algumas possibilidades interessantes. A primeira delas é a possibilidade de utilição do foreach, como vemos abaixo:

1 @foreach($products as $product)
2 	<li>$product->name</li>
3 @endforeach

Desta maneira a iteração na coleção de produtos, vindas do banco de dados, será no mesmos moldes do foreach do PHP, e claro, no procesamento desta view essa diretiva se tornará um foreach nativo.

Mas aqui, quero utilizar um foreach não muito convencional, na forma que vamos escrever, mas é claro que com condicionais e combinando com os laços chegaríamos no mesmo resultado.

Mas Nanderson, do que você está falando!?

Por exemplo, poderíamos fazer um controle condicional pro caso de não existirem produtos na base e somente, se existirem, exibissemos a tabela com os produtos.

Por exemplo, veja o trecho abaixo:

1 @if(count($products))
2     @foreach($products as $product)
3 		<li>{{ $product->name }}</li>
4 	@endforeach
5 @else 
6    <h2> Nenhum produto cadastrada!</h2>
7 @endif

Acima te apresento o controle condicional ou como usar os se…senão (if…else) via diretivas do Blade. Primeiramente verificamos se o valor de $products é verdadeiro, se verdadeiro nós realizamos os loops, senão, exibimos uma mensagem padrão. O verdadeiro aqui pra $products é termos produtos na coleção.

Agora podemos melhorar ainda mais essa escrita usando outra diretiva do blade. Com a diretiva de loop chamada de @forelse conseguimos chegar no mesmo resultado acima com pouco esforço e é ela que vamos utilizar, então vamos ao conteúdo do nosso index.blade.php, que não existe ainda, então crie o arquivo index.blade.php lá dentro da pasta das views de produto: resources/views/products/.

Veja seu conteúdo abaixo:

 1 @extends('layouts.app')
 2 
 3 @section('content')
 4     <div class="w-full mb-10 flex justify-between">
 5         <h2 class="font-bold text-xl">Produtos</h2>
 6         <a href="{{ route('products.create') }}"
 7             class="px-4 py-2 bg-green-700 border border-green-900 rounded text-white\
 8  font-thin">Criar Produto</a>
 9     </div>
10     <div class="w-full p-5">
11         <table class="w-full">
12             <thead>
13                 <tr class="border-b border-gray-600">
14                     <th class="px-4 py-2 text-xl text-left">#</th>
15                     <th class="px-4 py-2 text-xl text-left">Produto</th>
16                     <th class="px-4 py-2 text-xl text-left">Status</th>
17                     <th class="px-4 py-2 text-xl text-left">Criado em</th>
18                     <th class="px-4 py-2 text-xl text-left">Ações</th>
19                 </tr>
20             </thead>
21             <tbody>
22                 @forelse($products as $product)
23                     <tr>
24                         <td class="px-4 py-2 text-normal text-left">{{ $product->id \
25 }}</td>
26                         <td class="px-4 py-2 text-normal text-left">{{ $product->nam\
27 e }}</td>
28                         <td class="px-4 py-2 text-normal text-left">
29                             @if ($product->is_active)
30                                 <span class="p-1 rounded bg-green-500 text-green-900\
31 ">Ativo</span>
32                             @else
33                                 <span class="p-1 rounded bg-red-500 text-red-900">In\
34 ativo</span>
35                             @endif
36                         </td>
37                         <td class="px-4 py-2 text-normal text-left">{{ $product->cre\
38 ated_at->format('d/m/Y H:i') }}</td>
39                         <td class="w-[15%] px-4 py-2 text-normal text-left">
40                             <div class="flex justify-around gap-x-2">
41                                 <a href="{{ route('products.show', ['product' => $pr\
42 oduct->id]) }}"
43                                     class="px-4 py-2 bg-blue-700 border border-blue-\
44 900 rounded text-white font-thin">
45                                     Editar
46                                 </a>
47                                 <form action="{{ route('products.destroy', ['product\
48 ' => $product->id]) }}" method="post">
49                                     @csrf
50                                     @method('DELETE')
51                                     <button type="submit"
52                                         class="px-4 py-2 bg-red-700 border border-re\
53 d-900 rounded text-white font-thin">Remover</button>
54                                 </form>
55                             </div>
56                         </td>
57                     </tr>
58                 @empty
59                     <tr>
60                         <td colspan="4">Nada encontrado!</td>
61                     </tr>
62                 @endforelse
63             </tbody>
64         </table>
65     </div>
66 @endsection