Tutorial Laravel per principianti

Laravel è stato creato da Taylor Otwell. Dalla sua prima release nel giugno 2011 (versione 1), è diventato sempre più popolare nel settore dei framework PHP dell'industria dello sviluppo web. Gran parte di questa popolarità può essere attribuita alle numerose funzionalità pensate per gli sviluppatori fornite in stock.

Perchè Laravel?

Circa 2000, quasi Codici PHP era procedurale e poteva essere trovato sotto forma di "script" che avrebbero avuto un intricato groviglio di codici spaghetti. Anche le pagine più semplici non avevano separazione degli interessi, e quindi era abbastanza facile che un'applicazione si trasformasse rapidamente in un incubo di manutenzione. Il mondo aveva bisogno di qualcosa di meglio... Inserisci la versione 5 di PHP e una varietà di framework PHP che tentano di portare la risoluzione tanto necessaria e soluzioni migliori a vari problemi delle applicazioni web.

Da allora abbiamo visto molti framework rilasciati che avrebbero aperto la strada ai framework popolari esistenti e utilizzati oggi. Oggi i primi tre sarebbero (secondo noi) Zend Framework, Symfony e ovviamente Laravel. Sebbene ciascuno di questi framework sia fondato su principi simili e sia orientato a risolvere (sostanzialmente) gli stessi problemi comuni, le differenze principali risiedono nelle loro implementazioni. Ognuno di loro ha le proprie stranezze su come risolvere i problemi. Quando guardi il codice prodotto da ciascuno di essi, vedrai che c'è una linea piuttosto continua che li separa l'uno dall'altro. A nostro modesto parere, il framework Laravel è il migliore.

Scopri Differenza tra Laravel e CodeIgniter

Come scaricare e installare Laravel con Composer

NOTA Si presuppone che tu abbia già una copia di PHP installata sul tuo sistema locale. In caso contrario, puoi leggere come installarlo qui

Composer è sia un pacchetto che un gestore di dipendenze. Per installarlo, apri un terminale e inserisci il cd in una nuova directory. Esegui questo comando:

curl -Ss getcomposer.org/installer | php

I risultati di questo comando saranno simili a questi:

Note: Per istruzioni più dettagliate sulla configurazione di Laravel, fare riferimento alla documentazione di Laravel qui.

Lo vedrai scaricare e compilare lo script compositer.phar, che è quello che usiamo per installare Laravel. Sebbene esistano numerosi modi per configurare una nuova applicazione Laravel, lo faremo tramite lo script del compositore Laravel. Per installare questo script, esegui:

composer global require laravel/installer

Che sarà simile a questo:

Questo scaricherà e installerà tutti i file del framework e tutte le dipendenze che richiede. I pacchetti saranno salvati all'interno della directory vendor. Una volta scaricato e installato, è facile come dare il seguente comando:

laravel new uploadApp

Vedrai un output simile al seguente:

Composer sta installando tutti i pacchetti di cui Laravel ha bisogno per funzionare. Potrebbero essere necessari alcuni minuti, quindi sii paziente. Al termine, esegui il comando ls -al per dare un'occhiata a cosa è stato installato.

Ecco una breve ripartizione delle directory in una comune applicazione Laravel:

• app/: Questa è la cartella di origine in cui risiede il codice dell'applicazione. Tutti i controller, le policy e i modelli si trovano all'interno di questa cartella
• bootstrap/: Contiene lo script di avvio dell'applicazione e alcuni file della mappa di classi
• configurazione/: Contiene i file di configurazione dell'app. Questi di solito non vengono modificati direttamente ma si basano invece sui valori impostati nel file .env (ambiente) nella radice dell'app
• Banca dati/ : Ospita i file del database, comprese le migrazioni, i seed e le fabbriche di test
• pubblico/: Cartella accessibile al pubblico contenente risorse compilate e, naturalmente, un file index.php
• risorse/: Contiene risorse front-end come file JavaScript, file di lingua, file CSS/SASS e tutti i modelli utilizzati nell'applicazione (chiamati modelli blade)
• itinerari/ : Tutti i percorsi nell'applicazione sono qui dentro. Esistono diversi “ambiti” di percorsi, ma quello su cui ci concentreremo è il file web.php
• magazzinaggio/ : Tutti i file di cache temporanei utilizzati dall'applicazione, file di sessione, script di visualizzazione compilati e file di registro
• prove/: Contiene file di test per l'applicazione come test unitari e test funzionali.
• venditore/: Tutti i pacchetti di dipendenze installati con Composer

Ora quindi, creiamo il resto dell'app ed eseguiamolo con uno speciale comando artigianale (per risparmiarci il fastidio di installare e configurare un server web come Apache o nginx). Il file .env contiene tutti i valori di configurazione utilizzati dai file nella directory /config per configurare l'applicazione. Al suo interno noterai che il valore di configurazione per vari parametri utilizzati dagli interni dell'applicazione.

Progettazione dell'applicazione: un rapido elenco dei nostri requisiti

In questo tutorial online di Laravel, costruiremo un'applicazione molto semplice che farà solo due cose:

1. gestire i caricamenti di file da un modulo Web
2. visualizzando i file caricati in precedenza su una pagina diversa.

Per questo progetto, la nostra applicazione sarà di sola scrittura, il che significa che l'utente potrà solo scrivere file e visualizzare l'elenco dei file che ha caricato. Questa applicazione è estremamente semplice ma dovrebbe servire come buona pratica su cui iniziare a sviluppare le tue abilità e conoscenze su Laravel. Tieni presente che, per brevità, ho escluso qualsiasi modellazione, migrazione e autenticazione del database ma, in un'applicazione reale, queste sono cose aggiuntive che dovresti considerare.

Ecco un elenco dei componenti di cui avremo bisogno per far funzionare l'applicazione come previsto:

• A route che consentirà al mondo esterno (internet) di utilizzare l'applicazione oltre a specificare l'endpoint che indicherà dove si trova la logica per il salvataggio del file caricato
• A controllore che gestisce il flusso di richiesta-risposta
• A modello che verrà utilizzato per visualizzare un elenco di file caricati in precedenza e il modulo di caricamento stesso
• A richiesta che il titolare utilizzerà per validare i dati inseriti dal modulo web

Cos'è un percorso?

Una rotta in Laravel è fondamentalmente un endpoint specificato da un URI che funge da "puntatore" ad alcune funzionalità offerte dall'applicazione. Più comunemente, una route punta semplicemente a un metodo su un controller e determina anche quali metodi HTTP sono in grado di raggiungere quell'URI. Un percorso non significa sempre nemmeno un metodo di controllo; potrebbe semplicemente passare l'esecuzione dell'applicazione a una chiusura definita o anche a una funzione anonima.

Perché utilizzare Percorso?

Le rotte sono archiviate all'interno di file nella cartella /routes all'interno della directory principale del progetto. Di default, ci sono alcuni file diversi corrispondenti ai diversi "lati" dell'applicazione ("lati" deriva dalla metodologia dell'architettura esagonale). Includono:

• web.php I percorsi basati sul "browser" rivolti al pubblico. Questi sono i più comuni e sono quelli che vengono colpiti dal browser web. Corrono attraverso il gruppo middleware web e contengono anche funzionalità per protezione CSRF (che aiuta a difendersi da attacchi dannosi e hack basati su moduli) e generalmente contengono un certo grado di "stato" (con questo intendo che utilizzano sessioni)
• api.php Route che corrispondono a un gruppo API e quindi hanno il middleware API abilitato per impostazione predefinita. Questi percorsi sono senza stato e non hanno sessioni o memoria per richieste incrociate (una richiesta non condivide dati o memoria con nessun'altra richiesta: ognuna è auto-incapsulata).
• console.php Questi percorsi corrispondono ai comandi artigiani personalizzati che hai creato per la tua app
• channels.php Registra i percorsi per la trasmissione degli eventi

Il file chiave di cui preoccuparsi in questo momento è quello specifico del browser, web.php . Esiste già un percorso definito per impostazione predefinita, che è quello che premi correttamente quando navighi verso la radice web della tua applicazione (la radice web si trova nella directory pubblica). Avremo bisogno di tre percorsi diversi affinché la nostra applicazione di caricamento funzioni:

• /upload Questo sarà l'URI della pagina principale che visualizza il nostro modulo web per caricare i file.
• /process Questo sarà il punto in cui il modulo situato nell'URI /upload invia i dati inviati dal modulo (l'"azione") del modulo
• /list Questo elencherà tutti i file caricati sul sito

Nota L'endpoint /list potrebbe non essere necessario se volessimo mettere tutta la logica per visualizzare il modulo di caricamento e l'elenco dei file su un'unica pagina, tuttavia, per ora li abbiamo tenuti separati per aggiungere un po' più di materia all'argomento in questione .

//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');

In questo tutorial sul framework Laravel, per ogni percorso desiderato, lo elencheremo esplicitamente nel file dei percorsi web.php utilizzando uno dei metodi di richiesta specifici HTTP disponibili (get(), post(), put() , delete(), patch() o opzioni() ). Per una ripartizione di ciascuno di questi, controlla questo fuori. Ciò che fanno questi metodi è specificare quali verbi HTTP sono autorizzati ad accedere a quel determinato percorso. Se hai bisogno di una route per poter accettare più di un verbo HTTP (che potrebbe essere il caso se stai utilizzando una singola pagina per visualizzare sia i dati iniziali che i dati del modulo inviato), puoi utilizzare Route::any( ) metodo.

Il secondo argomento per i metodi Route::get() e Route::post() (e per tutti gli altri metodi correlati ai verbi HTTP nella facciata Route) è il nome di un Controller specifico e del metodo ospitato all'interno di tale controller che viene eseguito quando si raggiunge l'endpoint della route con la richiesta HTTP consentita (GET, POST, PATCH, ecc.). Stiamo utilizzando UploadController per tutte e tre le route e le abbiamo specificate nel modo seguente:

L'ultimo metodo che chiamiamo su ogni percorso è la sua funzione name(), che accetta una singola stringa come argomento e viene utilizzata per "taggare" più o meno un percorso particolare con un nome facile da ricordare (nei nostri casi, caricare, elaborare ed elencare). Mi rendo conto che non sembra una funzionalità così eccezionale dare a ogni percorso il proprio nome quando l'URL ha esattamente lo stesso nome, ma è davvero utile quando hai un percorso specifico come /users/profile/dashboard/config, che sarebbe più facile da ricordare come profile-admin o user-config.

Una nota sulle facciate:

• Le facciate forniscono un'interfaccia "statica" alle classi disponibili nel contenitore di servizi dell'applicazione."
• Forniscono una sintassi concisa e memorabile che consente di utilizzare le funzionalità di Laravel senza ricordare nomi di classi lunghi che devono essere inseriti o configurati manualmente.

Le definizioni di percorso di cui sopra in questo tutorial del framework Laravel, utilizziamo la facciata Route invece di istanziare manualmente un nuovo oggetto Illuminate/Routing/Router e chiamare i metodi corrispondenti su quell'oggetto. È solo una scorciatoia che salva la digitazione. Le facciate sono ampiamente utilizzate in tutto il framework Laravel: puoi e dovresti acquisire maggiore familiarità con esse. È possibile trovare la documentazione per Facades qui.

Cos'è un controllore?

Un controller è la "C" nell'architettura "MVC" (Model-View-Controller), su cui si basa Laravel. Il lavoro di un controller può essere ridotto a questa semplice definizione: Riceve la richiesta dal client e restituisce una risposta al client. Questa è la definizione essenziale e rappresenta anche i requisiti minimi di qualsiasi controller. Ciò che fa tra queste due cose è generalmente considerato come l'“azione” del titolare del trattamento (o l'“implementazione del percorso”). Funziona come secondo punto di ingresso nell'applicazione (il primo è la richiesta) per il client, che invia il payload della richiesta (di cui parleremo in seguito) all'applicazione, aspettandosi un qualche tipo di risposta (sotto forma di pagina di successo, reindirizzamento, pagina di errore o qualsiasi altro tipo di risposta HTTP).

Un controller fa (sostanzialmente) la stessa cosa di una definizione di percorso con una funzione anonima impostata come “azione” quando viene raggiunta quella rotta. La differenza è che un controller regge bene la separazione delle preoccupazioni mentre una rotta è definita in linea con la definizione effettiva dell'URL, il che significa sostanzialmente che stiamo accoppiando l'URI assegnato alla rotta con l'implementazione della rotta, o il codice che viene eseguito quando quella rotta è colpo.

Ad esempio, i due seguenti pezzi di codice otterranno lo stesso risultato:

Esempio n. 1: definizione e implementazione della rotta all'interno di una singola chiamata al metodo (nel file delle rotte 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);
});

Esempio n.2: la definizione del percorso è all'interno di Routes/web.php, ma la sua implementazione risiede all'interno della 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);
   }
}

Anche se l'esempio n. 2 di Laravel sembra molto più impegnativo (cosa che non è: solo un po' più di codice, tutto qui), guarda i vantaggi che otteniamo inserendo invece la nostra logica di azione per il percorso "hello-world" specificato all'interno di un controller di con la definizione del percorso come funzione di callback:

1. La nostra logica è nettamente separata nella propria classe (separazione delle preoccupazioni)
2. Il nostro controller è impostato per l'estensione in seguito se dovessimo aggiungere funzionalità aggiuntive... Diciamo che forse volessimo aggiungere una funzionalità "goodbye-world"... In questo caso rinomineremmo il controller in un "HelloController" più generico, quindi definiremmo due metodi separati, Ciao() e arrivederci(). Avremmo anche bisogno di definire due percorsi separati che mappassero il file /Ciao e / Arrivederci URI al metodo appropriato sul controller. Ciò è auspicabile rispetto all'ingrossamento di un file di percorsi con l'implementazione di ogni percorso definita come funzioni di callback.
3. Laravel ha la capacità integrata di memorizzare nella cache tutte le definizioni di percorso nell'applicazione in modo da accelerare il tempo necessario per trovare un determinato percorso (aumenta le prestazioni dell'applicazione); tuttavia, potrai trarne vantaggio solo se tutti i percorsi definiti all'interno dell'applicazione sono configurati utilizzando mappature specifiche del controller (vedi Esempio n. 2 sopra)

Eseguiamo questo comando che genererà un nuovo controller per noi.

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

In sostanza, ciò che fa questo comando è generare uno stub per un controller denominato "UploadController" all'interno della directory principale del controller in /app/Http/Controllers/UploadController.php. Sentiti libero di aprire quel file e dare un'occhiata. È molto semplice perché è solo una versione interrotta del controller, con il percorso dello spazio dei nomi corretto e le classi richieste da cui si estende.

Generazione della richiesta

Prima di procedere con questo tutorial PHP Laravel e apportare alcune modifiche allo stub generato da UploadController, penso che avrebbe più senso creare prima la classe di richiesta. Questo perché il metodo controller che gestisce la richiesta deve suggerire il tipo dell'oggetto richiesta nella sua firma, consentendogli di convalidare automaticamente i dati del modulo in arrivo (come specificato nel metodo rules(). Ne parleremo più avanti...) Per ora, utilizziamo di nuovo il comando artisan per generare il nostro stub di richiesta:

php artisan make:request UploadFileRequest

Questo comando genererà un file chiamato UploadFileRequest all'interno di app/Http/Requests/UploadFileRequest. Apri lo stub e dai un'occhiata... Lo troverai molto semplice, contenente solo due metodi, autorizzare() e regole.

Creazione della logica di validazione

Modifichiamo lo stub della richiesta per soddisfare le esigenze della nostra applicazione. Modificare il file in modo che assomigli a questo:

<?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'
       ];
   }
}

Non ci sono molti cambiamenti, ma notate che il metodo Authorize() ora restituisce true invece di false. Questo metodo decide se consentire o meno l'ingresso della richiesta nell'applicazione. Se è impostato su false, impedisce alla richiesta di entrare nel sistema (che normalmente sarebbe un metodo sul controller). Questo sarebbe un posto molto utile per effettuare eventuali controlli di autorizzazione sull'utente o qualsiasi altra logica che possa decidere se la richiesta può essere inoltrata al controller. Per ora, restituiamo semplicemente true qui per consentire a qualsiasi cosa di utilizzare la richiesta.

L'altro metodo, rule(), è quello in cui entra in gioco tutta la magia per quanto riguarda la validazione. L'idea è semplice: restituire un array contenente un insieme di regole sotto forma di:

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

Ci sono molti diversi vincoli di convalida supportati da Laravel fin da subito. Per un elenco completo, consulta la documentazione online qui. Per la nostra applicazione di caricamento, ci saranno due campi che vengono passati tramite richiesta POST da un modulo sul front-end. Il parametro fileName deve essere incluso all'interno del corpo del modulo (ad esempio obbligatorio) e viene utilizzato come nome file con cui memorizzeremo il file nell'archivio (ciò avviene nel controller, ne parleremo più avanti). Specifichiamo inoltre che il nome file deve essere una stringa aggiungendo un carattere pipe (|) e la parola "string". I vincoli sono sempre delimitati da pipe, consentendo di specificare qualsiasi criterio aggiuntivo per il campo dato in una singola riga! Che potenza!

Il secondo parametro, userFile , è il file effettivo che l'utente carica da un modulo su una pagina web. È richiesto anche UserFile e devono obbligatoriamente: essere un file. Nota: Se ci aspettassimo che il file caricato sia un'immagine, utilizzeremmo invece il vincolo immagine, che limiterebbe i tipi di file accettati a essere uno dei tipi di immagine più diffusi (jpeg, png, bmp, gif o svg). Poiché vogliamo consentire all'utente di caricare qualsiasi tipo di file, ci atterremo semplicemente al vincolo di convalida del file.

Questo è tutto quello che c'è da sapere sull'oggetto request. Il suo compito principale è semplicemente quello di mantenere l'insieme accettabile di criteri (vincoli) che i parametri del corpo del modulo devono soddisfare per procedere più in profondità nell'applicazione. Un'altra cosa da notare è che questi due campi (userFile e filename) devono essere specificati anche all'interno del codice HTML sotto forma di campi di input (con il nome del campo corrispondente al nome all'interno dell'oggetto di richiesta).

Potresti chiederti: certo questo definisce le caratteristiche di cosa dovrebbe contenere una richiesta di modulo, ma dove viene effettuato il controllo effettivo di questi vincoli? Ne parleremo dopo.

Modifica del controller

Aprire app/Http/Controllers/UploadController e apportare le seguenti modifiche:

<?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
   }
}

Quindi è un approccio abbastanza semplice per salvare i file caricati su disco. Ecco una ripartizione del metodo upload() sopra:

• Digita il suggerimento della classe di richiesta nel metodo del controller che sta eseguendo la funzionalità "carne e patate" in modo da poter convalidare automaticamente i dati in entrata
• Prendi il file dall'oggetto request (ora convalidato) all'interno del metodo del controller (in questo caso lo abbiamo chiamato upload() ma avrebbe potuto anche essere nominato con un nome più standardizzato come store()).
• Prendi il nome del file dalla richiesta
• Genera il nome file finale che verrà utilizzato per salvare il file. Il metodo getClientOriginalExtension() cattura semplicemente l'estensione originale del file caricato.
• Memorizza il file nel filesystem locale utilizzando il suo metodo storeAs(), passando il percorso denominato all'interno della directory /storage come primo argomento e il nome del file in cui salvarlo come secondo.
• Restituisce una risposta JSON che indica che la richiesta ha avuto successo

Il modello della lama

L'ultimo pezzo importante di questo puzzle è il modello blade, che conterrà tutto l'HTML, CSS e javascript per la nostra semplice applicazione. Ecco il codice: lo spiegheremo più avanti.

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

Ecco cosa il nostro / caricamento la pagina assomiglia a:

Questo è un esempio molto tipico di un file blade contenente un modulo HTML e javascript/jQuery per aggiungere funzionalità asincrone (in modo che la pagina non si aggiorni). C'è una base tag senza attributo method (che spiegherò tra un secondo) e con un curioso attributo action con il valore {{route('file.upload')}}. In blade, questo è ciò che è noto come un Direttiva. Una direttiva è solo un nome di fantasia per una funzione: sono funzioni specifiche dei modelli di blade che eseguono diverse operazioni comuni alla costruzione di pagine Web e applicazioni Web. Per una migliore comprensione di tutte le cose interessanti che Blade può fare, controlla la documentazione qui. Nel caso precedente, stiamo utilizzando la direttiva route per generare un URL per l'invio del modulo.

Ricorda che abbiamo definito i nostri percorsi in precedenza nell'applicazione all'interno del file web.php, specificando per ciascuno di essi un nome facile da ricordare. La direttiva {{route()}} accetta il nome di una rotta, lo cerca all'interno dell'elenco delle rotte memorizzate nella cache interna e genera un URL completo in base alla definizione di quella rotta nel file web.php. Per questo primo caso, specifichiamo che vogliamo che il modulo invii i dati inviati all'URL /process della nostra applicazione, che è definito come POST percorso.

La prossima cosa strana che potresti aver notato è il tag @csrf proprio sotto il tag del modulo di apertura. Nel blade, questo tag genera un parametro _token sul modulo, che viene controllato all'interno dell'applicazione prima che i dati del modulo possano essere elaborati. Ciò garantisce che i dati all'interno del modulo abbiano un'origine valida e previene attacchi di falsificazione di richieste tra siti. Per ulteriori informazioni su questo, vedere il docs.

Dopodiché definiamo il nostro modulo come normale, tuttavia, tieni presente che i nomi dei nostri parametri del modulo, userFile e fileName sono i esattamente lo stesso come definito all'interno del nostro oggetto di richiesta. Se ci dimenticassimo di includere un input per un dato parametro che è stato definito nell'oggetto della richiesta (o lo abbiamo scritto in modo errato), la richiesta fallirebbe e verrebbe restituito un errore, impedendo alla richiesta del modulo originale di raggiungere il metodo del controller situato in UploadController@ processi .

Vai avanti, provalo e invia alcuni file all'applicazione utilizzando questo modulo. Successivamente, vai a /elenco pagina per vedere il contenuto della cartella di caricamento, con i file caricati elencati in una tabella:

The Bigger Picture

Facciamo un passo indietro e guardiamo cosa abbiamo fatto in questo tutorial di Laravel.

Questo diagramma illustra l'applicazione così com'è adesso (esclusi i dettagli di alto livello):

Dovresti ricordare che l'oggetto richiesta che abbiamo costruito all'inizio di questo tutorial di Laravel dovrebbe avere gli stessi parametri definiti nel suo metodo delle regole come nel modulo nel modello del blade (in caso contrario rileggi la sezione "Creazione della logica di convalida") . L'utente inserisce il modulo in una pagina Web renderizzata tramite un motore di template blade (questo processo è ovviamente con il pilota automatico, quindi non dobbiamo nemmeno pensarci) e invia il modulo. Il codice jQuery del modello in basso interrompe l'invio predefinito (che reindirizzerebbe automaticamente a una pagina separata), crea una richiesta ajax, carica la richiesta con i dati del modulo e carica il file e invia il tutto al primo livello del nostro domanda: la richiesta.

L'oggetto della richiesta viene popolato associando i parametri all'interno del metodo rule() con i parametri del modulo inviato, quindi convalida i dati in base a ciascuna regola specificata. Se tutte le regole sono soddisfatte, la richiesta viene passata a qualunque metodo del controller che corrisponda ai valori definiti nel file di instradamento web.php. In questo caso, è il metodo process() di UploadController a svolgere il lavoro. Una volta raggiunto il controller, sappiamo già che la richiesta ha superato la convalida, quindi non dobbiamo ripetere il test se il nome file fornito è, in effetti, una stringa o se il parametro userFile contiene effettivamente qualche tipo di file... Possiamo continuare come normale.

Il metodo del controller quindi preleva i parametri convalidati dall'oggetto della richiesta, genera un nome file completo concatenando il parametro fileName passato con l'estensione originale di userFile, memorizza il file all'interno di una directory nella nostra applicazione, quindi restituisce un semplice file con codifica JSON risposta verificando che la richiesta sia andata a buon fine. La risposta viene ricevuta dalla logica jQuery, che esegue alcune altre attività relative all'interfaccia utente come visualizzare il messaggio di successo (o errore) per 5 secondi, quindi nasconderlo e cancellare le voci del modulo precedente... in modo che l'utente lo sappia per essere sicuro che la richiesta sia andata a buon fine e potrà caricare un altro file, se lo desidera.

Inoltre, prendi nota nel diagramma sopra dove viene tracciata la linea tra il client e il server. Questo concetto è assolutamente fondamentale da comprendere e ti aiuterà a risolvere problemi e questioni che potresti avere in futuro quando gestisci, ad esempio, più richieste asincrone che possono verificarsi in qualsiasi momento. La separazione è proprio al confine dell'oggetto richiesta. L'oggetto richiesta stesso può essere pensato come il "gateway" per il resto dell'applicazione... Esegue la convalida iniziale e la registrazione dei valori del modulo passati dal browser Web. Se sono considerati validi, allora continua al controller. Tutto ciò che precede è sul front-end (il "client" significa letteralmente "sul computer dell'utente"). La risposta viene restituita dall'app al lato client, dove il nostro codice jQuery ascolta pazientemente il suo arrivo ed esegue alcune semplici attività dell'interfaccia utente una volta che lo riceve.

Abbiamo coperto quasi 90+ ​​importanti domande frequenti Domande di intervista relative a Laravel e PHP per matricole e candidati esperti per ottenere il lavoro giusto.