Tutorial Laravel para iniciantes

Laravel foi criado por Taylor Otwell. Desde o seu lançamento inicial em junho de 2011 (versão 1), ele tem crescido cada vez mais popular no setor de frameworks PHP da indústria de desenvolvimento web. Grande parte dessa popularidade pode ser atribuída aos muitos recursos voltados para o desenvolvedor que vem com o estoque.

Por que Laravel?

Por volta de 2000, a maior parte Códigos PHP era processual e podia ser encontrado na forma de “scripts” que teriam uma confusão emaranhada de código espaguete. Mesmo as páginas mais simples não tinham separação de preocupaçõese, portanto, era bastante fácil para um aplicativo se transformar rapidamente em um pesadelo de manutenção. O mundo precisava de algo melhor… Digite o PHP versão 5 e uma variedade de estruturas PHP tentando trazer a resolução necessária e melhores soluções para vários problemas de aplicativos da web.

Desde então, vimos muitos frameworks lançados que abririam caminho para os frameworks populares existentes e empregados hoje. Hoje, os três primeiros seriam (em nossa opinião) Zend Framework, Symfony e, claro, Laravel. Embora cada uma dessas estruturas tenha sido fundada em princípios semelhantes e seja voltada para resolver (basicamente) os mesmos problemas comuns, suas principais diferenças residem em suas implementações. Cada um deles tem suas próprias peculiaridades sobre como resolver problemas. Ao observar o código produzido por cada um deles, você verá que há uma linha bastante sólida que os separa um do outro. Na nossa humilde opinião, o framework Laravel é o melhor.

Saiba mais sobre o Diferença entre Laravel e CodeIgniter

Como baixar e instalar o Laravel com Composer

NOTA Presume-se que você já tenha uma cópia do PHP instalada em seu sistema local. Caso contrário, você pode ler como instalá-lo aqui

Composer é um gerenciador de pacotes e dependências. Para instalá-lo, abra um terminal e faça cd em um novo diretório. Execute este comando:

curl -Ss getcomposer.org/installer | php

Os resultados deste comando serão assim:

Note Para instruções mais extensas sobre como configurar o Laravel, consulte a documentação do Laravel aqui.

Você o verá baixando e compilando o script compositor.phar, que é o que usamos para instalar o Laravel. Embora existam inúmeras maneiras de configurar uma nova aplicação Laravel, faremos isso através do script Laravel Composer. Para instalar este script, execute:

composer global require laravel/installer

Que será parecido com isto:

Isso fará o download e instalará todos os arquivos da estrutura, bem como todas as dependências necessárias. Os pacotes serão salvos no diretório do fornecedor. Depois de baixado e instalado, é tão fácil quanto emitir o seguinte comando:

laravel new uploadApp

Você verá algo como a seguinte saída:

O Composer está instalando todos os pacotes que o Laravel precisa para rodar. Pode demorar alguns minutos, então seja paciente. Após terminar, execute um comando ls -al para ver o que foi instalado.

Aqui está uma breve análise dos diretórios em um aplicativo Laravel comum:

• aplicativo/ : Esta é a pasta de origem onde reside o código do nosso aplicativo. Todos os controladores, políticas e modelos estão dentro desta pasta
• inicialização/ : Contém o script de inicialização do aplicativo e alguns arquivos de mapa de classes
• configuração/ : Contém os arquivos de configuração do aplicativo. Geralmente, eles não são modificados diretamente, mas dependem dos valores configurados no arquivo .env (ambiente) na raiz do aplicativo
• base de dados/ : Abriga os arquivos de banco de dados, incluindo migrações, sementes e fábricas de teste
• público/ : Pasta acessível publicamente contendo ativos compilados e, claro, um arquivo index.php
• recursos/ : Contém ativos de front-end, como arquivos javascript, arquivos de linguagem, arquivos CSS/SASS e todos os modelos usados ​​no aplicativo (chamados de modelos blade)
• rotas/ : Todas as rotas do aplicativo estão aqui. Existem alguns “escopos” diferentes de rotas, mas o que iremos focar é o arquivo web.php
• armazenar/ : Todos os arquivos de cache temporários usados ​​pelo aplicativo, arquivos de sessão, scripts de visualização compilados e arquivos de log
• testes/ : Contém arquivos de teste para o aplicativo, como testes unitários e testes funcionais.
• fornecedor/ : Todos os pacotes de dependência instalados com o compositor

Agora, vamos construir o resto do aplicativo e executá-lo com um comando artesanal especial (para evitar o incômodo de instalar e configurar um servidor web como Apache ou nginx). O arquivo .env contém todos os valores de configuração que os arquivos no diretório /config usam para configurar o aplicativo. Dentro dele você notará o valor de configuração de diversos parâmetros utilizados pelo interior da aplicação.

Design do aplicativo: um rápido resumo de nossos requisitos

Neste tutorial online do Laravel, estaremos construindo um aplicativo muito simples que fará apenas duas coisas:

1. lidar com uploads de arquivos de um formulário da web
2. exibindo os arquivos carregados anteriormente em uma página diferente.

Para este projeto, nosso aplicativo será somente gravação, o que significa que o usuário só poderá gravar arquivos e visualizar a lista de arquivos que carregou. Este aplicativo é extremamente básico, mas deve servir como uma boa prática para você começar a desenvolver suas habilidades e conhecimentos em Laravel. Observe que, por uma questão de brevidade, excluí qualquer modelagem de banco de dados, migrações e autenticação, mas, em uma aplicação do mundo real, essas são coisas adicionais que você deve considerar.

Aqui está uma lista de componentes que precisaremos para fazer o aplicativo funcionar conforme o esperado:

• A estrada que permitirá que o mundo externo (internet) use o aplicativo, bem como especifique o endpoint que apontará para onde está localizada a lógica para salvar o arquivo carregado
• A controlador que lida com a solicitação para o fluxo de resposta
• A modelo que será usado para exibir uma lista de arquivos enviados anteriormente e o próprio formulário de upload
• A solicitar que o controlador usará para validar os dados transmitidos do formulário web

O que é uma rota?

Uma rota no Laravel é basicamente um endpoint especificado por um URI que atua como um “ponteiro” para alguma funcionalidade oferecida pela aplicação. Mais comumente, uma rota simplesmente aponta para um método em um controlador e também determina quais métodos HTTP são capazes de atingir esse URI. Uma rota nem sempre significa método de controlador; ele poderia simplesmente passar a execução do aplicativo para um fechamento definido ou uma função anônima também.

Por que usar o Rota?

As rotas são armazenadas em arquivos na pasta /routes dentro do diretório raiz do projeto. Por padrão, existem alguns arquivos diferentes correspondentes aos diferentes “lados” da aplicação (“lados” vem da metodologia de arquitetura hexagonal). Eles incluem:

• web.php As rotas baseadas em “navegador” voltadas para o público. Estes são os mais comuns e são os que são atingidos pelo navegador. Eles são executados no grupo de middleware da web e também contêm recursos para proteção csrf (que ajuda na defesa contra ataques maliciosos e hacks baseados em formulários) e geralmente contém um certo grau de “estado” (com isso quero dizer que eles utilizam sessões)
• api.php Rotas que correspondem a um grupo de APIs e, portanto, possuem o middleware da API habilitado por padrão. Essas rotas não têm estado e não possuem sessões ou memória de solicitação cruzada (uma solicitação não compartilha dados ou memória com nenhuma outra solicitação – cada uma é autoencapsulada).
• console.php Essas rotas correspondem a comandos artesanais personalizados que você criou para seu aplicativo
• canais.php Registra rotas para transmissão de eventos

O arquivo chave com o qual se preocupar neste momento é aquele específico do navegador, web.php . Já existe uma rota definida por padrão, que é aquela que você acertou ao navegar até a raiz web da sua aplicação (a raiz web está no diretório público). Precisaremos de três rotas diferentes para que nosso aplicativo de upload funcione:

• /upload Este será o URI da página principal que exibe nosso formulário web para upload de arquivos.
• /process Este será o local onde o formulário localizado no URI /upload postará os dados enviados pelo formulário (a “ação” do formulário)
• /list Isso listará todos os arquivos enviados para o site

nota O endpoint /list pode não ser necessário se quisermos colocar toda a lógica para exibir o formulário de upload e a lista de arquivos em uma única página, no entanto, os mantivemos separados por enquanto para adicionar um pouco mais de assunto ao assunto em questão .

//inside routes/web.php
Route::get('/upload', 'UploadController@upload')->name('upload');
Route::get('/download, 'UploadController@download)->name(‘download');
Route::post('/process', 'UploadController@process')->name('process');
Route::get('/list', 'UploadController@list')->name('list');

Neste tutorial do framework Laravel, para cada rota desejada, iremos listá-la explicitamente no arquivo de rotas web.php usando um dos métodos de solicitação específicos de HTTP disponíveis (get(), post(), put() , delete(), patch() ou opções() ). Para uma análise de cada um deles, verifique esse fora. O que esses métodos fazem é especificar quais verbos HTTP têm permissão para acessar determinada rota. Se você precisar que uma rota seja capaz de aceitar mais de um verbo HTTP (o que pode ser o caso se você estiver usando uma única página para exibir os dados iniciais e postar os dados do formulário enviado), você pode usar o método Route::any( ) método.

O segundo argumento para os métodos Route::get() e Route::post() (e qualquer outro método relacionado ao verbo HTTP na fachada Route), é o nome de um controlador específico e método alojado dentro dele. controlador que é executado ao atingir o endpoint da rota com a solicitação HTTP permitida (GET, POST, PATCH, etc.). Estamos usando o UploadController para todas as três rotas e as especificamos da seguinte maneira:

O último método que chamamos em cada rota é a função name(), que aceita uma única string como argumento e é usada para “marcar” mais ou menos uma rota específica com um nome fácil de lembrar (em nossos casos, carregar, processar e listar). Sei que não parece um recurso tão bom dar a cada rota seu próprio nome quando o URL tem exatamente o mesmo nome, mas é realmente útil quando você tem uma rota específica como /users/profile/dashboard/config, que seria mais fácil de lembrar como profile-admin ou user-config.

Uma nota sobre fachadas:

• As fachadas fornecem uma interface “estática” para classes que estão disponíveis no contêiner de serviço da aplicação.”
• Eles fornecem uma sintaxe concisa e memorável que permite usar os recursos do Laravel sem lembrar nomes longos de classes que devem ser injetados ou configurados manualmente.

Nas definições de rota acima neste tutorial do framework Laravel, usamos a fachada Route em vez de instanciar manualmente um novo objeto Illuminate/Routing/Router e chamar os métodos correspondentes nesse objeto. É apenas um atalho que economiza digitação. Fachadas são muito usadas em todo o framework Laravel – você pode e deve se familiarizar mais com elas. A documentação para Fachadas pode ser encontrada aqui.

O que é um Controlador?

Um controlador é o “C” na arquitetura “MVC” (Model-View-Controller), na qual o Laravel é baseado. O trabalho de um controlador pode ser resumido nesta definição simples: Ele recebe a solicitação do cliente e retorna uma resposta ao cliente. Esta é a definição básica e também os requisitos mínimos de qualquer controlador. O que ele faz entre essas duas coisas é geralmente considerado como a “ação” do controlador (ou a “implementação da rota”). Ele atua como o segundo ponto de entrada da aplicação (sendo o primeiro a solicitação) para o cliente, que envia o payload da solicitação (que veremos a seguir) para a aplicação, esperando algum tipo de resposta (na forma de um página de sucesso, redirecionamento, página de erro ou qualquer outro tipo de resposta HTTP).

Um controlador faz (basicamente) a mesma coisa que uma definição de rota com uma função anônima definida como a “ação” quando essa rota é atingida. A diferença é que um controlador suporta bem a separação de interesses enquanto uma rota é definida em linha com a definição de URL real, o que basicamente significa que estamos acoplando o URI atribuído à rota com a implementação da rota, ou o código que é executado quando essa rota é bater.

Por exemplo, os dois trechos de código a seguir alcançarão a mesma coisa:

Exemplo #1: Definição e implementação de rota dentro de uma única chamada de método (no arquivo de rotas web.php)

//inside routes/web.php
<?php
Route::get('/hello-world', function(Request $request) {
   $name = $request->name;
   return response()->make("<h1>Hello World! This is ".$name, 200);
});

Exemplo #2: A definição da rota está dentro de rotas/web.php, mas sua implementação reside dentro da classe /app/Http/Controllers/HelloWorldController

//inside routes/web.php
<?php

Route::get('/hello-world', 'HelloWorldController@index')->name('hello-world');

------------------------------------------------------------------------------------
//inside app/Http/Controllers/HelloWorldController.php
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;

class HelloWorldController extends Controller
{
   public function index(Request $request)
   {
       $name = $request->name;
       return response()->make("<h1>Hello World! This is ".$name, 200);
   }
}

Embora o exemplo 2 do Laravel pareça muito mais trabalhoso (o que não é - apenas um pouco mais de código), observe os benefícios que ganhamos ao colocar nossa lógica de ação para a rota “hello-world” fornecida dentro de um controlador. da definição da rota como uma função de retorno de chamada:

1. Nossa lógica está claramente separada em sua própria classe (separação de interesses)
2. Nosso controlador está configurado para extensão mais tarde se precisarmos adicionar recursos adicionais a ele… Digamos que talvez quiséssemos adicionar um recurso “adeus mundo”… Nesse caso, renomearíamos o controlador para um “HelloController” mais genérico e depois definiríamos dois métodos separados, Olá() e adeus(). Também precisaríamos definir duas rotas separadas que mapeassem o /olá e / adeus URIs para seu método apropriado no controlador. Isso é desejável em comparação com a engorda de um arquivo de rotas com a implementação de cada rota definida como funções de retorno de chamada.
3. O Laravel tem a capacidade integrada de armazenar em cache todas as definições de rota no aplicativo para acelerar o tempo necessário para encontrar uma determinada rota (aumenta o desempenho do aplicativo); Contudo, você só poderá tirar vantagem disso se todas as rotas definidas dentro do aplicativo estiverem configuradas usando mapeamentos específicos do controlador (veja o Exemplo nº 2 acima)

Vamos executar este comando que irá gerar um novo controlador para nós.

// ...inside the project's root directory:
php artisan make:controller UploadController   

Essencialmente, o que este comando faz é gerar um stub para um controlador chamado “UploadController” dentro do diretório principal do controlador em /app/Http/Controllers/UploadController.php. Sinta-se à vontade para abrir esse arquivo e dar uma olhada. É muito simples porque é apenas uma versão fragmentada do controlador, com o caminho correto do namespace e as classes necessárias das quais ele se estende.

Gerando a solicitação

Antes de prosseguirmos neste tutorial do PHP Laravel e fazer algumas alterações no stub gerado pelo UploadController, acho que fará mais sentido criar a classe de solicitação primeiro. Isso ocorre porque o método controlador que trata a solicitação deve digitar hint o objeto da solicitação em sua assinatura, permitindo validar automaticamente os dados do formulário recebido (conforme especificado no método regras(). Mais sobre isso mais tarde…) Por enquanto, vamos usar o comando artesão novamente para gerar nosso stub de solicitação:

php artisan make:request UploadFileRequest

Este comando irá gerar um arquivo chamado UploadFileRequest dentro de app/Http/Requests/UploadFileRequest. Abra o stub e dê uma olhada… Você vai achar muito simples, contendo apenas dois métodos, authorize() e regras.

Criando a lógica de validação

Vamos modificar o stub da solicitação para atender às necessidades da nossa aplicação. Modifique o arquivo para que fique assim:

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UploadFileRequest extends FormRequest
{
   /**
    * Determine if the user is authorized to make this request.
    *
    * @return bool
    */
   public function authorize()
   {
       return true;
   }

   /**
    * Get the validation rules that apply to the request.
    *
    * @return array
    */
   public function rules()
   {
       return [
           'fileName' => 'required|string',
           'userFile' => 'required|file'
       ];
   }
}

Não foram muitas mudanças, mas observe que o método authorize() agora retorna verdadeiro em vez de falso. Este método decide se permite ou não que a solicitação entre no aplicativo. Se for definido como falso, impede que a solicitação entre no sistema (o que normalmente seria um método no controlador). Este seria um local muito útil para colocar qualquer verificação de autorização no usuário ou qualquer outra lógica que possa decidir se a solicitação pode avançar para o controlador. Por enquanto, apenas retornamos true aqui para permitir que tudo e qualquer coisa use a solicitação.

O outro método, regras() é onde toda a mágica entra em ação no que diz respeito à validação. A ideia é simples: retornar um array contendo um conjunto de regras na forma de:

'formFieldName' => 'constraints this field has separated by pipe characters (|)'

Existem muitas restrições de validação diferentes que são suportadas pelo Laravel imediatamente. Para uma lista completa deles, verifique a documentação online aqui. Para nosso aplicativo de upload, haverá dois campos que serão passados ​​via solicitação POST de um formulário no front end. O parâmetro fileName deve ser incluído dentro do corpo do formulário (ou seja, obrigatório) e é usado como o nome do arquivo sob o qual armazenaremos o arquivo no armazenamento (isso é feito no controlador - falaremos disso um pouco mais tarde). Também especificamos que o nome do arquivo deve ser uma string adicionando uma barra vertical (|) e a palavra 'string'. As restrições são sempre delimitadas por barras verticais, permitindo especificar quaisquer critérios adicionais para um determinado campo em uma única linha! Que poder!

O segundo parâmetro, userFile , é o arquivo real que o usuário carrega de um formulário em uma página da web. UserFile também é necessário e devo ser um arquivo. Nota: Se esperássemos que o arquivo enviado fosse uma imagem, usaríamos a restrição de imagem, o que limitaria os tipos de arquivo aceitos a um dos tipos de imagem populares (jpeg, png, bmp, gif ou svg). Como queremos permitir que o usuário faça upload de qualquer tipo de arquivo, seguiremos apenas a restrição de validação de arquivo.

Isso é tudo que existe no objeto de solicitação. Sua principal função é simplesmente manter o conjunto aceitável de critérios (restrições) que os parâmetros do corpo do formulário devem satisfazer para prosseguir mais profundamente na aplicação. Outra coisa a observar é que esses dois campos (userFile e filename) também devem ser especificados dentro do código HTML na forma de campos de entrada (com o nome do campo correspondente ao nome dentro do objeto de solicitação).

Você pode estar se perguntando: claro que isso define as características do que uma solicitação de formulário deve conter, mas onde é feita a verificação real dessas restrições? Entraremos nisso a seguir.

Modificando o controlador

Abra app/Http/Controllers/UploadController e faça as seguintes alterações:

<?php

namespace App\Http\Controllers;

use Illuminate\Contracts\Container\BindingResolutionException;
use Illuminate\Http\Request;
use App\Http\Requests\UploadFileRequest; //our new request class
use Illuminate\Support\Facades\Storage; 

class UploadController extends Controller
{
   /**
    * This is the method that will simply list all the files uploaded by name and provide a
    * link to each one so they may be downloaded
    *
    * @param $request : A standard form request object
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function list(Request $request)
   {
       $uploads = Storage::allFiles('uploads');

       return view('list', ['files' => $uploads]);
   }

   /**
    * @param $file
    * @return \Symfony\Component\HttpFoundation\BinaryFileResponse
    * @throws BindingResolutionException
    */
   public function download($file)
   {
       return response()->download(storage_path('app/'.$file));
   }

   /**
    * @return \Illuminate\Contracts\View\Factory|\Illuminate\View\View
    * @throws BindingResolutionException
    */
   public function upload()
   {
       return view('upload');
   }

   /**
    * This method will handle the file uploads. Notice that the parameter's typehint
    * is the exact request class we generated in the last step. There is a reason for this!
    *
    * @param $request : The special form request for our upload application
    * @return array|\Illuminate\Http\UploadedFile|\Illuminate\Http\UploadedFile[]|null
    * @throws BindingResolutionException
    */
   public function store(UploadFileRequest $request)
   {
       //At this point, the parameters passed into the $request (from form) are
       //valid--they satisfy each of the conditions inside the rules() method

       $filename = $request->fileName;    //parameters have already been validated
       $file = $request->file('userFile'); //that we don't need any additional isset()

       $extension = $file->getClientOriginalExtension(); //grab the file extension
       $saveAs = $filename . "." . $extension; //filename to save file under

       $file->storeAs('uploads', $saveAs, 'local'); //save the file to local folder

       return response()->json(['success' => true]); //return a success message
   }
}

Portanto, é uma abordagem bastante simples para salvar os arquivos enviados em disco. Aqui está um detalhamento do método upload() acima:

• Digite a classe de solicitação no método do controlador que está executando a funcionalidade 'carne e batatas' para que possamos validar automaticamente os dados recebidos
• Pegue o arquivo do objeto de solicitação (agora validado) dentro do método do controlador (neste caso, nós o chamamos de upload(), mas também poderia ter sido nomeado com um nome mais padronizado, como store()).
• Pegue o nome do arquivo da solicitação
• Gere o nome do arquivo final que será usado para salvar o arquivo. O método getClientOriginalExtension() simplesmente captura a extensão original do arquivo carregado.
• Armazene o arquivo no sistema de arquivos local usando seu método storeAs(), passando o caminho nomeado dentro do diretório /storage como o primeiro argumento e o nome do arquivo para salvá-lo como o segundo.
• Retornar uma resposta JSON indicando que a solicitação foi bem-sucedida

O modelo de lâmina

A última peça importante deste quebra-cabeça é o modelo blade, que conterá todo HTML, CSS e javascript para nosso aplicativo simples. Aqui está o código – explicaremos mais tarde.

<body>
   <h1>Upload a file</h1>
   <form id="uploadForm" name="uploadForm" action="{{route('upload')}}" enctype="multipart/form-data">
       @csrf
       <label for="fileName">File Name:</label>
       <input type="text" name="fileName" id="fileName" required /><br />
       <label for="userFile">Select a File</label>
       <input type="file" name="userFile" id="userFile" required />
       <button type="submit" name="submit">Submit</button>
   </form>
   <h2 id="success" style="color:green;display:none">Successfully uploaded file</h2>
   <h2 id="error" style="color:red;display:none">Error Submitting File</h2>
   <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>
   <script>
        $('#uploadForm').on('submit', function(e) {
            e.preventDefault();
            var form = $(this);
            var url = form.attr('action');
            $.ajax({
                url: url,
                type: "POST",
                data: new FormData(this),
                processData: false,
                contentType: false,
                dataType: "JSON",
                success: function(data) {
                    $("#fileName").val("");
                    $("#userFile").val("");
                }
            }).done(function() {
                $('#success').css('display', 'block');
                window.setTimeout(()=>($("#success").css('display', 'none')), 5000);
            }).fail(function() {
                $('#error').css('display', 'block');
                window.setTimeout(()=>($("#error").css('display', 'none')), 5000);
            });
        });
   </script>
</body>
</html>

Aqui está o que nosso / Envio página parece com:

Este é um exemplo muito típico de arquivo blade contendo um formulário HTML e javascript/jQuery para adicionar funcionalidade assíncrona (para que a página não seja atualizada). Existe um básico tag sem nenhum atributo de método (que explicarei em apenas um segundo) e com um curioso atributo de ação com o valor {{route('file.upload')}}. Na lâmina, isso é conhecido como Directiva. Uma diretiva é apenas um nome sofisticado para função – são funções específicas para modelos blade que executam diferentes operações comuns à construção de páginas e aplicativos da web. Para uma melhor compreensão de todas as coisas legais que o blade pode fazer, confira a documentação aqui. No caso acima, estamos usando a diretiva route para gerar uma URL para o envio do nosso formulário.

Lembre-se que definimos nossas rotas anteriormente na aplicação dentro do arquivo web.php, especificando um nome fácil de lembrar para cada uma delas. A diretiva {{route()}} aceita o nome de uma rota, procura-o na lista de rotas armazenadas em cache internamente e gera uma URL completa com base na definição dessa rota no arquivo web.php. Para este primeiro caso, estamos especificando que queremos que o formulário envie os dados submetidos para a URL /process da nossa aplicação, que é definida como um POST rota.

A próxima coisa estranha que você deve ter notado é a tag @csrf logo abaixo da tag do formulário de abertura. No blade, essa tag gera um parâmetro _token no formulário, que é verificado dentro do aplicativo antes que os dados do formulário possam ser processados. Isso garante que os dados dentro do formulário sejam de origem válida e evita ataques de falsificação de solicitação entre sites. Para mais informações sobre isso, consulte o docs.

Depois disso definimos nosso formulário como normal, porém observe que os nomes dos parâmetros do nosso formulário, userFile e fileName são os exatamente o mesmo conforme definido em nosso objeto de solicitação. Se esquecermos de incluir uma entrada para um determinado parâmetro que foi definido no objeto de solicitação (ou digitá-lo incorretamente), a solicitação falhará e um erro será retornado, evitando que a solicitação do formulário original atinja o método do controlador localizado em UploadController@ processo .

Experimente e envie alguns arquivos para o aplicativo usando este formulário. Depois, navegue até o /Lista página para ver o conteúdo da pasta de upload, com os arquivos que você enviou listados em uma tabela:

The Bigger Picture

Vamos dar um passo atrás e ver o que fizemos neste tutorial do Laravel.

Este diagrama descreve o aplicativo como está no momento (excluindo detalhes de alto nível):

Você deve se lembrar que o objeto de solicitação que construímos no início deste tutorial do Laravel deve ter os mesmos parâmetros definidos em seu método de regras que estão no formulário no modelo blade (se não, releia a seção “Criando a Lógica de Validação”) . O usuário insere o formulário em uma página da web que é renderizada por meio de um mecanismo de modelo blade (é claro que esse processo está no piloto automático, então não precisamos nem pensar nisso) e envia o formulário. O código jQuery do modelo na parte inferior interrompe o envio padrão (que redirecionaria automaticamente para uma página separada), cria uma solicitação ajax, carrega a solicitação com os dados do formulário e carrega o arquivo, e envia tudo para a primeira camada do nosso aplicação: o pedido.

O objeto de solicitação é preenchido associando os parâmetros dentro do método regras() aos parâmetros do formulário enviado e, em seguida, valida os dados de acordo com cada regra especificada. Se todas as regras forem satisfeitas, a solicitação será repassada para qualquer método do controlador que corresponda aos valores definidos no arquivo de rota web.php. Nesse caso, é o método process() do UploadController que faz o trabalho. Assim que atingimos o controlador, já sabemos que a solicitação passou na validação, então não precisamos testar novamente se o nome do arquivo fornecido é, de fato, uma string ou se o parâmetro userFile realmente contém algum tipo de arquivo… Podemos continuar como normal.

O método do controlador então pega os parâmetros validados do objeto de solicitação, gera um nome de arquivo completo concatenando o parâmetro fileName passado com a extensão original do userFile, armazena o arquivo dentro de um diretório em nosso aplicativo e retorna um arquivo simples codificado em JSON resposta verificando se a solicitação foi bem-sucedida. A resposta é recebida pela lógica jQuery, que realiza mais algumas tarefas relacionadas à UI, como exibir a mensagem de sucesso (ou erro) por 5 segundos e depois ocultá-la, bem como limpar as entradas anteriores do formulário… isso é para que o usuário saiba ter certeza de que a solicitação foi bem-sucedida e poderá fazer upload de outro arquivo, se desejar.

Além disso, observe no diagrama acima exatamente onde a linha é traçada entre o cliente e o servidor. Este conceito é absolutamente crítico para você entender e irá ajudá-lo a resolver problemas e questões que você possa ter no futuro ao lidar, por exemplo, com múltiplas solicitações assíncronas que podem ocorrer a qualquer momento. A separação está bem no limite do objeto de solicitação. O próprio objeto de solicitação pode ser considerado o “gateway” para o resto da aplicação… Ele faz a validação inicial e o registro dos valores do formulário transmitidos pelo navegador da web. Se forem considerados válidos, o processo continua para o controlador. Tudo antes disso está no front-end (o “cliente” significa literalmente “no computador do usuário”). A resposta é retornada do aplicativo de volta para o lado do cliente, onde nosso código jQuery escuta pacientemente sua chegada e executa algumas tarefas simples de UI assim que a recebe.

Cobrimos quase 90 perguntas importantes e frequentes Perguntas da entrevista relacionadas ao Laravel e PHP para calouros e também para candidatos experientes conseguirem o emprego certo.