Tutorial Laravel per principianti

Cos'è Laravel?

laravel è un framework MVC web open source per PHP. Laravel è un framework robusto che fornisce un facile sviluppo di applicazioni Web PHP con funzionalità come un sistema di packaging modulare con un gestore delle dipendenze dedicato, accesso a database relazionali e altre utilità per la distribuzione e la manutenzione delle applicazioni.

Laravel è stato creato da Taylor Otwell. Dalla sua prima versione, rilasciata nel giugno 2011 (versione 1), ha guadagnato costantemente popolarità nel settore dei framework PHP per lo sviluppo web. Gran parte di questa popolarità è attribuibile alle numerose funzionalità pensate per gli sviluppatori che offre di default.

Perchè Laravel?

Circa 2000, quasi Codice 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 interessiE così, era piuttosto facile che un'applicazione si trasformasse rapidamente in un incubo di manutenzione. Il mondo aveva bisogno di qualcosa di meglio. Ecco che arriva PHP versione 5 e una varietà di framework PHP che cercano di fornire la struttura necessaria e soluzioni migliori a diverse problematiche delle applicazioni web.

Da allora abbiamo assistito al rilascio di molti framework che hanno spianato la strada ai framework più popolari oggi in uso. Oggi, i tre migliori (a nostro parere) sono Zend Framework, Symfony e, naturalmente, Laravel. Sebbene ognuno di questi framework sia stato fondato su principi simili e sia orientato a risolvere (essenzialmente) gli stessi problemi comuni, le loro differenze principali risiedono nelle implementazioni. Ognuno ha le proprie peculiarità nel modo in cui affronta i problemi. Quando si esamina il codice prodotto da ciascuno di essi, si nota una netta differenza tra di loro. A nostro modesto parere, il framework Laravel è il migliore.

Scopri di più differenza tra Laravel e CodeAccenditore.

Come scaricare e installare Laravel con Composer

Nota: Questo tutorial è stato scritto per Laravel 5.8, ma i concetti relativi a routing, controller, request e Blade rimangono validi anche nelle versioni più recenti. A partire dal 2026, l'ultima versione disponibile è Laravel 13 (rilasciata a marzo 2026), che richiede PHP 8.3 o versioni successive, mentre Laravel 12 richiede PHP 8.2.

Nota: Si presume che tu abbia già una copia di PHP installata sul tuo sistema locale. In caso contrario, puoi leggere come installarla. 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:

Nota: Per istruzioni più dettagliate sulla configurazione di Laravel, consultare la documentazione di Laravel. Qui..

Vedrai il download e la compilazione dello script composer.phar, che è quello che usiamo per installare Laravel. Sebbene esistano numerosi modi per configurare una nuova applicazione Laravel, lo faremo tramite lo script Composer di Laravel. Per installare questo script, esegui:

composer global require laravel/installer

Che sarà simile a questo:

Questo comando scaricherà e installerà tutti i file del framework, nonché tutte le dipendenze necessarie. I pacchetti verranno salvati nella directory vendor. Una volta scaricati e installati, basterà eseguire il seguente comando:

laravel new uploadApp

Vedrai un output simile al seguente:

Composer sta installando tutti i pacchetti necessari a Laravel per funzionare. L'operazione potrebbe richiedere alcuni minuti, quindi abbi pazienza. Al termine, esegui il comando `ls -al` per visualizzare l'elenco dei pacchetti installati.

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

• app/: Questa è la cartella sorgente in cui risiede il codice della nostra 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 di mappatura delle classi.
• configurazione/: Contiene i file di configurazione dell'app. Questi file in genere non vengono modificati direttamente, ma si basano sui valori impostati nel file .env (ambiente) nella directory principale dell'app.
• Banca dati/ : Contiene i file del database, inclusi quelli relativi alle migrazioni, ai seed e alle factory di test.
• pubblico/: Cartella accessibile pubblicamente contenente le risorse compilate e, naturalmente, un file index.php.
• risorse/: Contiene risorse front-end come JavaFile di script, file di lingua, file CSS/SASS e tutti i modelli utilizzati nell'applicazione (chiamati modelli Blade).
• itinerari/ : Tutte le route dell'applicazione si trovano qui. Esistono diversi "ambiti" di route, ma quello su cui ci concentreremo è il file web.php.
• magazzinaggio/ : Tutti i file di cache temporanei utilizzati dall'applicazione, i file di sessione, gli script di visualizzazione compilati e i file di registro.
• prove/: Contiene i file di test per l'applicazione, come i test unitari e i test funzionali.
• venditore/: Tutti i pacchetti di dipendenza sono stati installati tramite Composer.

Ora, completiamo l'applicazione e avviamola con un comando Artisan specifico (per risparmiarci la fatica di installare e configurare un server web come Apache o nginx). Il file .env contiene tutti i valori di configurazione che i file nella directory /config utilizzano per configurare l'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. visualizzare 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 caricati. Questa applicazione è estremamente semplice, ma dovrebbe servire come buon esercizio per iniziare a sviluppare le tue competenze e conoscenze di Laravel. Tieni presente che, per brevità, abbiamo omesso la modellazione del database, le migrazioni e l'autenticazione, ma in un'applicazione reale, questi sono aspetti aggiuntivi che dovresti considerare.

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

• A route Ciò consentirà al mondo esterno (internet) di utilizzare l'applicazione, nonché di specificare l'endpoint che indicherà la posizione in cui si trova la logica per il salvataggio del file caricato.
• A controllore che gestisce il flusso dalla richiesta alla risposta.
• A modello che verrà utilizzato per visualizzare un elenco dei file caricati in precedenza e il modulo di caricamento vero e proprio.
• A richiesta che il controller utilizzerà per convalidare i dati trasmessi dal modulo web.

Cos'è un percorso?

In Laravel, una route è essenzialmente un endpoint specificato da un URI che funge da "puntatore" a una funzionalità offerta dall'applicazione. Nella maggior parte dei casi, una route punta semplicemente a un metodo di un controller e definisce anche quali metodi HTTP possono accedere a quell'URI. Una route non si riferisce necessariamente a un metodo del controller; potrebbe anche semplicemente indirizzare l'esecuzione dell'applicazione a una Closure o a una funzione anonima definita.

Perché utilizzare un 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: le rotte pubbliche basate sul "browser". Queste sono le più comuni e sono quelle che vengono raggiunte dal browser web. Vengono eseguite tramite il gruppo di middleware web e contengono anche funzionalità per Protezione CSRF (che aiuta a difendersi dagli attacchi dannosi basati sui moduli) e generalmente contengono un certo grado di "stato" (con questo intendiamo che utilizzano le sessioni).
• api.php: percorsi che corrispondono a un gruppo API e che quindi hanno il middleware API abilitato per impostazione predefinita. Questi percorsi sono stateless e non hanno sessioni né memoria tra richieste (una richiesta non condivide dati o memoria con nessun'altra richiesta; ognuna è auto-incapsulata).
• console.php: questi percorsi corrispondono ai comandi Artisan personalizzati che hai creato per la tua app.
• channels.php: registra i percorsi per la trasmissione degli eventi.

Il file chiave su cui concentrarsi in questo momento è quello specifico del browser, web.php. Esiste già un percorso predefinito, che è quello che si trova nella directory principale dell'applicazione (la directory principale si trova nella directory pubblica). Per far funzionare la nostra applicazione di caricamento, avremo bisogno di tre percorsi diversi:

• /upload: questo sarà l'URI della pagina principale che visualizza il nostro modulo web per il caricamento dei file.
• /process: questo è il luogo in cui il modulo situato all'URI /upload invierà i dati ricevuti (l'"azione" del modulo).
• /list: questo comando elenca tutti i file caricati sul sito.

Nota: L'endpoint /list potrebbe non essere necessario se volessimo inserire tutta la logica per la visualizzazione del modulo di caricamento e dell'elenco dei file in un'unica pagina; tuttavia, per ora li abbiamo mantenuti separati per aggiungere un po' più di contenuto 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 delle rotte web.php utilizzando uno dei metodi di richiesta HTTP specifici disponibili (get(), post(), put(), delete(), patch() o options()). Per una spiegazione dettagliata di ciascuno di questi, consultare questo Questi metodi specificano quali verbi HTTP sono autorizzati ad accedere a quella determinata rotta. Se una rotta deve poter accettare più di un verbo HTTP (il che potrebbe accadere se si utilizza una singola pagina sia per visualizzare i dati iniziali che per inviare i dati del modulo), è possibile utilizzare il metodo Route::any().

Il secondo argomento dei metodi Route::get() e Route::post() (e di tutti gli altri metodi relativi ai verbi HTTP sulla facciata Route) è il nome di uno specifico controller e il metodo contenuto in tale controller che viene eseguito quando si accede all'endpoint della rotta con la richiesta HTTP consentita (GET, POST, PATCH, ecc.). Stiamo utilizzando UploadController per tutte le rotte e le abbiamo specificate nel seguente modo:

L'ultimo metodo che chiamiamo su ogni percorso è la sua funzione name(), che accetta una singola stringa come argomento e viene utilizzata per "etichettare" più o meno un particolare percorso con un nome facile da ricordare (nei nostri casi, upload, process e list). Potrebbe non sembrare una grande funzionalità dare a ogni percorso il proprio nome quando URL ha esattamente lo stesso nome, ma è davvero utile quando si ha 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 Facade forniscono un'interfaccia "statica" alle classi disponibili nel contenitore dei 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.

Nelle definizioni di percorso sopra riportate, utilizziamo la facciata Route invece di istanziare manualmente un nuovo oggetto Illuminate/Routing/Router e chiamare i metodi corrispondenti su tale oggetto. È semplicemente una scorciatoia che consente di risparmiare tempo.pingLe Facades sono ampiamente utilizzate nel framework Laravel; è possibile e consigliabile familiarizzare con esse. La documentazione relativa alle Facades è disponibile qui. 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 ed è anche il requisito minimo di qualsiasi controller. Ciò che fa tra questi due elementi è generalmente considerato l'"azione" del controller (o l'"implementazione della rotta"). Agisce come secondo punto di ingresso nell'applicazione (il primo è la richiesta) per il client, che invia il payload della richiesta (che analizzeremo 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 (essenzialmente) la stessa cosa di una definizione di percorso con una funzione anonima impostata come "azione" quando quel percorso viene raggiunto. La differenza è che un controller si presta bene alla separazione delle responsabilità, mentre un percorso è definito in linea con l'effettiva URL definizione, che in sostanza significa che stiamo collegando l'URI assegnato al percorso con l'implementazione del percorso, ovvero il codice che viene eseguito quando si accede a quel percorso.

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 della rotta si trova 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);
}
}

Sebbene l'esempio Laravel n. 2 sembri richiedere molto più lavoro (cosa che non è, solo un po' di codice in più), guarda i vantaggi che otteniamo inserendo la logica di azione per la rotta "hello-world" all'interno di un controller anziché con la definizione della rotta come funzione di callback:

1. La nostra logica è nettamente separata in una classe a sé stante (separazione delle responsabilità).
2. Il nostro controller è predisposto per essere esteso in seguito, qualora avessimo bisogno di aggiungere ulteriori funzionalità. Supponiamo di voler aggiungere una funzionalità "addio mondo". In questo caso rinomineremmo il controller in un nome più generico "HelloController", quindi definiremmo due metodi separati, Ciao() and arrivederci(). Avremmo anche bisogno di definire due percorsi separati che mappassero il file /Ciao and / Arrivederci URI al metodo appropriato sul controller. Questo è preferibile rispetto all'ingombrare un file di route con l'implementazione di ogni route definita come funzione 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 sfruttare questa funzionalità solo se tutti i percorsi definiti all'interno dell'applicazione sono configurati utilizzando la mappa specifica del controller.pings (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, questo comando genera uno stub per un controller chiamato "UploadController" all'interno della directory principale dei controller, nel file /app/Http/Controllers/UploadController.php. Sentiti libero di aprire quel file e dargli un'occhiata. È molto semplice perché si tratta solo di una versione stub del controller, con il percorso del namespace corretto e le classi necessarie da cui eredita.

Generazione della richiesta

Prima di procedere con questo tutorial PHP Laravel e apportare alcune modifiche allo stub generato da UploadController, è più opportuno creare prima la classe request. Questo perché il metodo del controller che gestisce la richiesta deve specificare il tipo dell'oggetto request nella sua firma, consentendogli di convalidare automaticamente i dati del modulo in ingresso (come specificato nel metodo rules(); ne parleremo più avanti). Per ora, utilizziamo nuovamente 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 il file e dai un'occhiata. Lo troverai molto semplice, contenente solo due metodi: authorize() e rules().

Creazione della logica di validazione

Modifichiamo lo stub della richiesta per adattarlo alle esigenze della nostra applicazione. Modifichiamo il file in modo che appaia così:

<?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 grandi cambiamenti, ma notate che il metodo authorize() ora restituisce true invece di false. Questo metodo decide se consentire o meno alla richiesta di entrare nell'applicazione. Se è impostato su false, impedisce alla richiesta di entrare nel sistema. Questo sarebbe un punto molto utile per inserire 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 per consentire a chiunque di utilizzare la richiesta.

L'altro metodo, rules(), è dove entra in gioco tutta la magia per quanto riguarda la validazione. L'idea è semplice: restituire un array contenente un insieme di regole nella 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 verranno passati tramite una richiesta POST da un modulo sul front-end. Il parametro fileName deve essere incluso nel corpo del modulo (ovvero è obbligatorio) e viene utilizzato come nome del file con cui memorizzeremo il file nello storage (questo viene fatto nel controller; lo vedremo più avanti). Specifichiamo inoltre che il nome del file deve essere una stringa aggiungendo il carattere barra verticale (|) e la parola 'stringa'. I vincoli sono sempre delimitati da barre verticali, consentendo di specificare qualsiasi criterio aggiuntivo per il campo in una singola riga.

Il secondo parametro, userFile, è il file effettivo che l'utente carica da un modulo su una pagina web. userFile è anche obbligatorio e devono obbligatoriamente: essere un file. Nota: Se ci aspettassimo che il file caricato sia un'immagine, useremmo il vincolo "immagine", che limiterebbe i tipi di file accettati a uno dei formati immagine più comuni (jpeg, png, bmp, gif o svg). Dato che vogliamo consentire all'utente di caricare qualsiasi tipo di file, ci atterremo al vincolo di validazione del file.

Questo è praticamente tutto ciò che c'è da sapere sull'oggetto request. Il suo compito principale è semplicemente quello di contenere l'insieme accettabile di criteri (vincoli) che i parametri del corpo del modulo devono soddisfare per poter procedere ulteriormente nell'applicazione. Un altro aspetto 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 presente nell'oggetto request).

Potreste chiedervi: questo definisce le caratteristiche di ciò che una richiesta di modulo dovrebbe contenere, ma dove viene effettivamente verificato il rispetto di questi vincoli? Lo vedremo tra poco.

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 process(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'); //so 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
}
}

Si tratta quindi di un approccio piuttosto semplice per salvare i file caricati su disco. Ecco una spiegazione dettagliata del metodo process() descritto sopra:

• Aggiungi un suggerimento di tipo alla classe della richiesta nel metodo del controller che esegue la funzionalità principale, in modo da poter convalidare automaticamente i dati in ingresso.
• Recupera il file dall'oggetto richiesta (ora convalidato) all'interno del metodo del controller.
• Estrai 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.
• Restituisci una risposta JSON che indica che la richiesta è andata a buon fine.

Il modello della lama

L'ultimo pezzo importante di questo puzzle è il modello blade, che conterrà tutto 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('process')}}" 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 spiegheremo tra un attimo) e con un curioso attributo action con il valore {{route('process')}}. In blade, questo è ciò che è noto come un Direttiva. Una direttiva è semplicemente un nome più elegante per una funzione; si tratta di funzioni specifiche dei template Blade che eseguono diverse operazioni comuni alla creazione di pagine web e applicazioni web. Per una migliore comprensione di tutte le funzionalità utili di Blade, consulta la documentazione. Qui.. Nel caso sopra, stiamo usando la direttiva route per generare un URL per l'invio del nostro modulo.

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

La prossima cosa che potresti aver notato è il tag @csrf subito sotto il tag di apertura del modulo. In 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 siano di un'origine valida e previene gli attacchi di cross-site request forgery. Per ulteriori informazioni su questo, vedere la docs.

Dopodiché definiamo il nostro modulo come di consueto; tuttavia, si noti che i nomi dei nostri parametri del modulo, userFile e fileName, sono i esattamente lo stesso come definito all'interno del nostro oggetto richiesta. Se dimenticassimo di includere un input per un determinato parametro definito nell'oggetto richiesta (o lo scrivessimo 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@process.

Vai avanti e provalo, e invia alcuni file all'applicazione usando questo modulo. Dopodiché, 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 analizziamo ciò che abbiamo fatto in questo tutorial su Laravel.

Questo diagramma illustra l'applicazione così come si presenta attualmente (esclusi i dettagli di alto livello):

È importante ricordare che l'oggetto request che abbiamo creato all'inizio di questo tutorial su Laravel dovrebbe avere gli stessi parametri definiti nel suo metodo rules che sono presenti nel modulo del template Blade (in caso contrario, rileggere la sezione "Creazione della logica di validazione"). L'utente inserisce il modulo in una pagina web renderizzata tramite il motore di template Blade e lo invia. Il codice jQuery del template in fondo alla pagina blocca l'invio predefinito (che reindirizzerebbe automaticamente a una pagina separata), crea una richiesta AJAX, carica la richiesta con i dati del modulo e il file caricato e invia il tutto al primo livello della nostra applicazione: la richiesta.

L'oggetto request viene popolato associando i parametri all'interno del metodo rules() ai parametri del modulo inviato, quindi convalida i dati in base a ciascuna regola specificata. Se tutte le regole sono soddisfatte, la richiesta viene passata al metodo del controller corrispondente ai valori definiti nel file di routing web.php. In questo caso, è il metodo process() dell'UploadController a svolgere il lavoro. Una volta raggiunto il controller, sappiamo già che la richiesta ha superato la convalida, quindi non è necessario verificare nuovamente se il nome del file fornito è effettivamente una stringa o se il parametro userFile contiene effettivamente un file. Possiamo procedere normalmente.

Il metodo del controller recupera quindi i parametri validati dall'oggetto request, genera un nome file completo concatenando il parametro fileName passato con l'estensione originale del file utente, memorizza il file in una directory della nostra applicazione e restituisce una semplice risposta codificata in JSON che conferma l'avvenuta richiesta. La risposta viene ricevuta dalla logica jQuery, che esegue alcune operazioni relative all'interfaccia utente, come la visualizzazione del messaggio di successo (o di errore) per 5 secondi, la sua successiva scomparsa e la cancellazione dei dati inseriti nel modulo. In questo modo, l'utente ha la certezza che la richiesta sia andata a buon fine e può caricare un altro file, se lo desidera.

Inoltre, osservate attentamente il diagramma qui sopra per individuare il punto esatto in cui viene tracciata la linea di demarcazione tra client e server. È fondamentale comprendere questo concetto, in quanto vi aiuterà a risolvere eventuali problemi futuri, ad esempio, nella gestione di più richieste asincrone che possono verificarsi contemporaneamente. La separazione avviene proprio al confine dell'oggetto request. L'oggetto request può essere considerato come il "gateway" verso il resto dell'applicazione. Si occupa della validazione e della registrazione iniziale dei valori del modulo inviati dal browser web. Se i valori sono considerati validi, la richiesta prosegue verso il controller. Tutto ciò che precede si trova sul front-end (il termine "client" significa letteralmente "sul computer dell'utente"). La risposta viene restituita dall'applicazione al lato client, dove il nostro codice jQuery attende pazientemente il suo arrivo ed esegue alcune semplici operazioni sull'interfaccia utente una volta ricevuta.

Abbiamo anche trattato molte domande importanti frequenti Domande di intervista relative a Laravel e PHP per matricole e candidati esperti per ottenere il lavoro giusto.

DOMANDE FREQUENTI