Laravel

Laravel è un framework PHP che negli ultimi anni ha avuto un discreto successo. Insieme a Symfony rappresenta una delle soluzioni più consolidate del momento per lo sviluppo di applicazioni Web in PHP.

Qualche mese fa è stata rilasciata la versione 5 di Laravel mentre quella attuale è la 5.1.11 e la minor release 5.1 è stata nominata come Long Time Support. E’ la prima volta che una release di Laravel riceve un supporto del genere quindi è opportuno considerare questa versione come il punto di riferimento dei framework PHP per i prossimi anni. La 5.1 segue lo standard PSR-2 che definisce una style guide nella scrittura del codice: i file del framework e tutti i file creati dai generatori di Laravel seguono questo standard e il consiglio degli sviluppatori è quello di mantenere tale convenzione anche per il codice delle proprie applicazioni.

Laravel presenta tutti i canoni dei framework Web moderni: ha una architettura interna basata su MVC (Model-View-Controller), si interfaccia con database relazionali tramite ORM (Object Relational Mapper) e ha un sistema di routing estremamente flessibile e configurabile.

Dalla versione 5, gli sviluppatori di Laravel hanno introdotto un nuovo progetto collaterale: Lumen. Quest’ultimo rappresenta un microframework che utilizza alcune caratteristiche di Laravel ma in un contesto più snello e leggero che premia ovviamente le performance. Non tutti i componenti di Laravel sono presenti in Lumen, ma solo i principali. I requisiti software sono praticamente i medesimi. La versione attuale è la 5.1.0 e ricalca le funzionalità della versione 5.1 di Laravel.

Laravel incorpora molti componenti di Symfony e li estende in base alle proprie necessità e al proprio pattern di sviluppo. A questo indirizzo sono disponibili le API (Application Programming Interface) e la relativa documentazione. Il namespace di default di tutti i componenti è Illuminate. Tutti i componenti sono a disposizione anche su GitHub, scomposti in diversi progetti ciascuno per ogni macrocategoria.

La presente guida prenderà come riferimento la versione completa Laravel. L’applicazione che verrà realizzata sarà un gestionale per biblioteche e i sorgenti verranno rilasciati capitolo per capitolo in modo da offrire le diverse versioni implementate.

Laravel presenta un processo di installazione abbastanza snello basato su Composer e un elenco di requisiti preciso:

• PHP versione 5.5.9 o successive;
• L’estensione PHP OpenSSL per generare e verificare messaggi criptati;
• L’estensione PHP PDO per la persistenza dei dati;
• L’estensione PHP Mbstring per la gestione avanzata delle stringhe;
• L’estensione PHP Tokenizer.

Nonostante sembrino estensioni particolari, esse sono relativamente molto comuni anche negli ambienti hosting più economici.

Composer si è imposto come standard industriale per gestire le dipendenze in PHP. Prima del suo avvento, il panorama PHP era molto disomogeneo, esistevano moltissime librerie ma trovare quelle più adatte al proprio progetto non era sempre facile, come non lo era l’integrazione in un’applicazione esistente.

Oltre a gestire le dipendenze, Composer permette anche il setup e la generazione di ambienti. Laravel si presenta come un framework altamente interoperabile con Composer, quindi una sua comprensione, seppur non approfondita, risulta quasi obbligatoria. Prima quindi di creare un nuovo progetto Laravel, è necessario avere Composer installato sul proprio ambiente.

Una volta installato il tool, possiamo inizializzare la nostra applicazione utilizzando due diverse strategie: tramite l’installer di Laravel o tramite il generatore di Composer. Nel primo caso sarò necessario scaricare l’installer come pacchetto globale sulla nostra macchina

composer global require "laravel/installer=~1.1"

e lanciare l’eseguibile appena installato

laravel new ${applicationName}

Nel secondo caso basterà invece un semplicissimo

composer create-project laravel/laravel ${applicationName} --prefer-dist

In entrambi i casi i generatori creeranno la struttura base dell’applicazione nella cartella ${applicationName}.

Non esiste un metodo preferibile, ma secondo la documentazione ufficiale il primo risulta essere più veloce in quanto il download viene effettuato solamente nel momento dell’esecuzione dell’installer.

L’applicazione appena installata, oltre alle folder di struttura definite da Laravel, presenta la cartella vendor che raccoglie le dipendenze di terze parti. Al momento dell’inizializzazione del progetto essa conterrà esclusivamente Laravel ma successivamente potrà contenere ulteriori dipendenze.

In caso di utilizzo di un sistema per il versioning (GIT o SVN), tale cartella non dovrebbe essere condivisa, questo per non appesantire la gestione del progetto con file che possono essere scaricati dalla Rete. Una volta ricevuto un progetto già esistente basterà eseguire un

composer update

per ottenere tutte le dipendenze dalla Rete.

L’applicazione di esempio seguirà questo approccio, quindi per avviarla, sarà necessario installare preventivamente le dipendenze.

Oltre a rendere il processo di installazione e setup il più semplice possibile, gli sviluppatori di Laravel non si sono fermati qua. Un’alternativa rispetto a quella di creare un ambiente di sviluppo completo, può essere quella di usare Homestead.

Homestead è una macchina virtuale Vagrant già configurata con tutto il software necessario per lavorare con Laravel, ovvero:

• l’OS Ubuntu;
• PHP;
• la virtual machine HHMV;
• il server engine Nginx:
• i DBMS MySQL e Postgres;
• Node per eventuali tool per progetti clientside (bower, grunt, gulp…);
• Redis e Memcached.

Questo significa che è possibile lavorare con Laravel, in un ambiente simile a quello finale di produzione, senza dover di fatto installare nulla sul proprio Pc. Vagrant si basa su VirtualBox o su VMWare per la virtualizzazione quindi richiede che almeno uno di questi strumenti sia installato. L’installazione non è banale e non è tema di questa guida quindi rimando alla guida di Homestead sul sito di Laravel e al sito ufficiale di Vagrant nel caso si verificassero particolari problemi.

L’idea di Homestead è sicuramente interessante. La prima installazione richiede un po’ di tempo in più, soprattutto per chi non conosce Vagrant, ma a lungo termine e se i progetti presentano aspetti non banali i vantaggi nell’utilizzare un sistema simile non tarderanno a palesarsi.

Dopo l’approfondimento incentrato sull’installazione del framework, concludiamo la parte di questa trattazione dedicata all’introduzione di Laravel con un contributo riguardante il più importante schema progettuale presente nel framework: il Facade Pattern. In pratica, questo design pattern viene utilizzato per tutte le funzionalità principali del framework e rappresenta la modalità più rilevante per creare componenti condivisi; per questa ragione, prima di procedere sarà necessario comprendere appieno il suo funzionamento.

Il Facade Pattern è un design pattern strutturale diffusamente utilizzato nella programmazione ad oggetti. Il termine “Facade” può essere tradotto come “facciata”, presto capiremo il perché. Questo pattern prevede la creazione un oggetto, il facade object, che fornisce un’API (Application Programming Interface) semplificata per una porzione di codice di dimensioni maggiori.

Tale meccanismo semplifica notevolmente le sessioni di sviluppo perchè permette di realizzare software caratterizzati da codici più facili da leggere e da utilizzare, riduce la catena delle dipendenze e facilita i test unitari in quanto esiste un unico componente aggregato. Il Facade Pattern è adottato frequentemente anche nei sistemi particolarmente complessi e quando i vari componenti software presentano parecchie interdipendenze tra di loro.

Esistono due altri pattern per molti versi simili al Facade che spesso vengono confusi con esso: l’Adapter Pattern e il Decorator Pattern. Nel primo caso, l’oggetto Adapter converte un’interfaccia per la programmazione in un’altra in base a cosa il consumer o l’utilizzatore si aspetta; nel secondo caso l’API originale viene arricchita o decorata per aggiungerne funzionalità avanzate o mancanti.

Spostando l’attenzione su Laravel, gli oggetti facade permettono di accedere, da qualsiasi punto dell’applicazione, a quasi tutti gli oggetti disponibili nel container applicativo dei componenti, il ServiceContainer. Questo container permette al core di Laravel di gestire la dependency injection in maniera trasparente e funge da collante tra i vari componenti.

Per utilizzare una classe facade quando disponibile basterà invocarne staticamente i metodi dopo la necessaria inclusione. Non è obbligatorio specificare il namespace completo delle classi facade in quanto Laravel sfrutta degli alias per rimappare i percorsi completi in nomi più facili da ricordare. Di seguito viene proposto un esempio di utilizzo di una delle facade più importanti: Request:

<?php
namespace App\Http\Controller
 
use Request;
 
class TestController extends Controller
{
    public function testMethod() {
        echo Request::method(); 
        echo Request::url();
    }
}

In questo breve esempio sfruttiamo la classe Request, mappata tramite alias verso Illuminate\Support\Facades\Request, per recuperare metodo HTTP e URL della richiesta. E’ interessate però sapere che all’interno del file relativo (presente nella cartella vendor), non è presente nessun metodo statico method() o url().

L’unico metodo disponibile è getFacadeAccessor che determina il nome dell’oggetto presente nel ServiceContainer sul quale invocare il metodo relativo. Grazie al magic method di PHP __callStaticMethod è infatti possibile invocare il metodo sull’istanza dell’oggetto relativo che nel caso di Request è Illuminate\Http\Request.

Consultando questa pagina sarà possibile reperire l’elenco dei facade disponibili in Laravel e dei quali verrà fatto largo uso nei prossimi articoli.

Nel corso della guida e negli esempi che mano a mano allegheremo, faremo ricorso a tali oggetti con una certa regolarità e utilizzeremo questo pattern per creare una classe Facade da utilizzare più volte.

Dopo alcuni articoli introduttivi sul framework Laravel, è arrivato il momento di mettere in pratica quanto appreso e concentrarsi sugli aspetti più tecnici. Questo e i prossimi articoli saranno divisi in due parti; nella prima introdurremo le varie funzionalità di Laravel mentre nella seconda arricchiremo passo passo la nostra applicazione.

Una volta creata la nostra applicazione con la metodologia che preferiamo (tramite installer o tramite composer come da primo articolo della guida), quello che ci si presenta è una struttura di folder abbastanza complessa per chi si avvicina per la prima volta a questo strumento. La struttura può sembrare parecchio dispersiva e ridondante, ma una volta appresi gli scopi di ciascuna cartella tutto sembrerà più sensato. La struttura di un progetto Laravel è la seguente:

Analizziamo più nel dettaglio le diverse cartelle:

Nella root del progetto sono presenti alcuni file descrittori da utilizzare con git, composer, gulp, npm, phpunit, l’eseguibile artisan e il file di configurazione dotenv.

La prima cartella che richiede la nostra attenzione, è config. In questa directory sono presenti tutte le configurazioni dell’applicazione e di eventuali moduli aggiuntivi installati. I diversi contesti dell’applicazione sono configurati tramite file differenti in modo da offrire maggior manutenibilità: per esempio le configurazioni legate al database si troveranno in database.php mentre quelle per l’invio delle email in mail.php.

Spesso però alcune configurazioni possono differire tra i diversi ambienti; Laravel gestisce questa possibilità tramite la libreria DotEnv. Questa prevede la creazione di un file di configurazione .env nella root del progetto. Tutti i settaggi presenti verranno caricati all’interno dell’array globale $_ENV e grazie alla funzione env di Laravel è possibile impostarli all’interno del framework.

Una configurazione particolare è l’applicationKey. Questa permette di garantire un livello di sicurezza maggiore in quanto rappresenta la chiave di criptazione di sessioni e altri dati sensibili.

La regola generale quindi rimane quella di utilizzare DotEnv per quelle variabili che possono differire tra i diversi ambienti e di utilizzare direttamente i file nella cartella config per le configurazioni che non possono variare.

E’ buona norma non condividere il file .env con i vari membri del team o tramite git o svn. La miglior pratica è invece quella di mantenere un file .env.example con una configurazione base ma lasciare al singolo sviluppatore l’onere di definire il proprio file. Per questo motivo il file .env viene inserito di default dentro il file .gitignore autogenerato da Laravel in fase di setup iniziale.

Una volta appresi i concetti teorici, iniziamo a lavorare sulla nostra applicazione denominata “Biblios”. Tramite il comando:

composer create-project laravel/laravel biblios --prefer-dist

installiamo l’applicazione. Una volta scaricati i sorgenti grazie a composer dedichiamoci alla definizione dell’applicationKey tramite:

artisan key:generate

L’applicazione è ora pronta! Dal prossimo articolo ci addentreremo nei vari moduli del Framework. Ricordate di eseguire un composer update e di creare un file .env basandovi su .env.example.

I framework moderni per la realizzazione di applicazioni Web supportano il meccanismo del routing, un termine con il quale ci si riferisce alla gestione delle URL e il mapping tra esse e le funzionalità offerte dall'applicazione stessa. Nonostante possa sembrare una tematica di scarso interesse, avere delle URL ben formattate, leggibili e ricche di informazioni è un aspetto fondamentale per il SEO.Google e gli altri motori di ricerca premiano quei siti che offrono una navigazione parlante e, al contrario, svantaggiano i siti con URL dinamiche caratterizzate da parecchi parametri in querystring. La tendenza attuale è quella di spostare i parametri dalla querystring all'URL stesso. Per esempio un URL di questo tipo:

http://www.sito.it/post.php?idPost=1234

Potrebbe essere tradotto in:

http://www.sito.it/post/1234

o meglio ancora in

http://www.sito.it/post/titolo-del-post-normalizzato/1234

Nonostante questa opera di conversione possa sembrare complicata, utilizzando Laravel e il suo modulo di routing saranno sufficienti delle semplici operazioni.

Per convenzione, le rotte di una applicazione Laravel sono definite all'interno del file app/Http/routes.php utilizzando il facade Route, automaticamente reso disponibile dal framework in questo file. Tale oggetto espone dei metodi che condividono il loro nome con i metodi HTTP standard (GET, POST, PUT, DELETE..) in modo da poter identificare non solo la URL ma anche il metodo che il client deve utilizzare per poter scatenare la funzionalità. Ecco alcuni esempi:

Route::get('/', function() {
    return 'Hello World';
});
Route::post('/post-url', function() {
    return 'Post is a beautiful method';
});

Nel caso fosse necessario mappare alcune URL su più di un metodo, possiamo usare i metodi match o any:

Route::match(['get', 'post'], '/', function() {
     return 'This is a GET or POST request';
});
Route::any('/any', function() {
    return 'I can respond to any http method';
});

Nonostante i form HTML non possano utilizzare metodi diversi da GET e POST, è comunque possibile invocare anche gli altri metodi utilizzando il parametro speciale _method.

Una delle funzionalità più comode del modulo di routing di Laravel, è la possibilità di definire rotte parametriche esattamente come descritto nell'introduzione. Possiamo infatti scrivere:

Route::get('/post/{id}', function($id) {
    return "You requested post with ID = " . $id;
});

o, nel caso di parametri opzionali:

Route::get('/post/{id?}, function($id = 1) {
      return "You requested post with ID = " . $id;
});

Oltre ai parametri è impossibile impostare delle espressioni regolari di validazione sui parametri:

Route::get('/post/{id?}, function($id = 1) {
      return "You requested post with ID = " . $id;
})->where(['id' => '[0-9]+']);

Le applicazioni di una certa complessità richiedono un elevato numero di rotte. Per non perdersi tra tutte queste configurazioni è possibile dare un nome alle rotte in modo da poterle riutilizzare facilmente anche all'interno di altri componenti, come per esempio nelle viste.

Route::get('/post/{id?}, ['postDetail', function($id = 1) {
     [...]
});

Grazie alla funzione di utilità route è possibile infine recuperare una rotta senza la necessità di scriverla e mantenendo intatto il pattern DRY (Don't Repeat Yourself).

$route = route('postDetail', ['id' => 1]);

Spesso può capitare di dover impostare alcune configurazioni comuni a più rotte. Pensiamo eventualmente a prefissi di URL comuni o a meccanismi di localizzazione basati sulle URL. Laravel ci viene incontro grazie ai gruppi. Tramite questi ultimi è possibile “racchiudere” le rotte in uno o più insiemi configurabili; le configurazioni impostate a livello di gruppo saranno ovviamente rese disponibili a tutte le rotte presenti. In questo caso riusciamo a recuperare il terzo livello di un dominio per gestirne eventualmente la localizzazione.

Route::group(['domain' => '{locale}.site.com'], function () {
    Route::get('user/{id}', function ($locale, $id) {
       //
    });
});

Oppure possiamo anteporre un prefisso a tutte le URL:

Route::group(['prefix' => 'admin'], function () {
    Route::get('users', function ()    {
       // Matches The "/admin/users" URL
    });
});

Sono disponibili altre configurazioni a livello di gruppo (in particolare middleware e namespace), ma verranno introdotte successivamente, quando si parlerà degli altri componenti presenti in Laravel.

In questa seconda parte di implementazione della nostra applicazione denominata “Biblios” possiamo concentrarci sulle prime rotte. Al momento, dato che non abbiamo ancora introdotto i controller, definiremo temporaneamente la logica all'interno del file routes.php.

Apriamo quindi il file e aggiungiamo:

Route::get('/', [ 'as' => 'home', function () { //nomino la rotta 'home'
       return "Benvenuti in Biblios";
}]);
Route::get('/home', function () {
       return redirect(route('home'));
});

Per poter testare le rotte, utilizziamo il server HTTP integrato in Laravel. Apriamo quindi una console e, partendo dalla root del progetto, digitiamo:

php artisan serve 

(approfondiremo i comandi successivamente). Così facendo abbiamo avviato un server HTTP sulla porta 8000. Apriamo quindi il browser per navigare all'indirizzo

http://localhost:8000

In questo modo dovremmo visualizzare il nostro messaggio, mentre se puntiamo verso:

http://localhost:8000/home

dovremmo essere redirezionati sulla root del progetto.

Nonostante Laravel permetta di definire alcuni comportamenti direttamente nel fileroutes.php, questo approccio non è scalabile. La soluzione perfetta per gestire i vari entry point delle nostre applicazioni è invece l'utilizzo deicontroller. Laravel ha previsto per questa tipologia di componente una cartella dedicata:app/Http/Controllerse una classe da estendereIlluminate\Routing\Controller. Un controller è una semplice classe che presenta diversi metodi pubblici. Ciascuno di questi ultimi viene associato ad una URL e ad un metodo HTTP. Per associare una URL ad un determinato controller si usa la sintassi NomeController@nomeMetodo. Per esempio:

//routes.php
Route::get('/users', 'UserController@getList');
//UserController.php
class UserController extends BaseController {
    public function getList() {
        return 'User1, User2, User3';
    }
}

In questo caso abbiamo associato la URL /users al metodo getList dello UserController. Come per le rotte tradizionali, anche quando utilizziamo un controller è possibile dare ad esso un nome specifico:

Route::get('/users', [ 'uses' => 'UserController@getList', 'as' => 'userList' ]);

Eventuali parametri presenti nelle rotte verranno tradotti in parametri del metodo del controller invocato.

In caso di creazione di API restful, è possibile mappare automaticamente i metodi di una classe con le URL. Grazie al metodo resource, Laravel definirà al nostro posto tutte le rotte disponibili:

Route::resource('photo', 'PhotoController');

Le URL verranno create secondo questa tabella: Figura 1. Creazione delle URL.

Tramite il comando da console php artisan make:controller PhotoController è possibile creare uno scheletro di controller con i metodi già definiti.

Un'ulteriore funzionalità interessante è quella offerta dal metodo controller. In questo caso non sarà necessario mappare tutte le URL nel file routes.php, infatti, tramite una convenzione, Laravel creerà automaticamente le rotte in base ai metodi pubblici della classe. La convenzione prevede che i nomi del metodo siano composti dal nome del metodo HTTP seguiti dall'azione in camelCase e le rotte avranno come prefisso il nome del controller. Ad esempio il metodo getIndex del BookController verrà tradotto in una rotta GET all'URL /book (dato che “index” rappresenta la root) mentre il metodo postCreate verrà tradotto in una rotta POST all'URL /book/create.

Se l'applicazione fa largo uso di rotte dinamiche definite tramite i metodi resource e controller, è buona norma quella di creare un file di cache per velocizzare il tempo di setup dell'applicazione (sulla documentazione ufficiale si parla addirittura di un risparmio di 100x). Basterà eseguire un php artisan route:cache per staticizzare la configurazione.

Una delle responsabilità dei controller è quella di agire sull'oggetto request. La miglior strategia per ottenere l'oggetto in questione è quella utilizzare la dependency injection di Laravel definendo un parametro tipizzato tra i parametri del metodo:

class DemoController extends BaseController
    public function dumpRequest(Illuminate\Http\Request $request) {
        var_dump($request);
    }
}

Una volta ottenuto l'oggetto, le funzionalità disponibili saranno molteplici.

Il metodo input dell'oggetto request permette appunto di leggere i parametri in ingresso. E' possibile passargli il nome del field da leggere ed eventualmente un parametro di default nel caso il parametro mancasse. Grazie invece al metodo all è possibile ottenere tutti i parametri.

$name = $request->input('name');
$email = $request->input('email', 'mail@domain.com');
$allParameters = $request->all();

Per ottenere un valore salvato in un cookie utilizziamo invece il metodo cookie:

$value = $request->cookie('cookieName');

La controparte dell'oggetto request è l'oggetto response. Quest'ultimo rappresenta appunto la risposta che il server invia al client. Normalmente i vari metodi mappati nel file delle rotte dovrebbero restituire un oggetto response, ma solitamente Laravel esegue il lavoro più complesso: quando restituiamo una semplice stringa, essa viene convertita automaticamente dal framework. Il seguente entrypoint:

Route::get('/', function () {
    return 'Hello World';
});

Potrà essere scritto anche come:

use Illuminate\Http\Response;
Route::get('home', function () {
    return new Response('Hello World');
});

o, utilizzando l'helper response:

Route::get('home', function () {
    return response('Hello World');
});

Il vantaggio di utilizzare l'oggetto response è però quello di poter agire anche su altre proprietà come ad esempio gli header o i cookie:

return response('Hello World)
  ->header('Content-Type', 'text/plain')
  ->withCookie('myCookieName', 'myCookieValue');

Oltre agli header è possibile personalizzare il tipo di response. Possiamo per esempio restituire una view (che analizzeremo nel dettaglio nel prossimo articolo):

return response()->view('viewName', array('name' => 'Alberto'));

o un listato in notazione JSON:

return response()->json(array('name' => 'Alberto', 'skills' => array('PHP')));

o ancora restituire un listato in notazione JSON in modalità JSONP:

return response()->json(...)->setCallback($request->input('cb'));

o un file in modalità download:

return response()->download('file.pdf');

L'ultima responsabilità della response è quella di rispondere con una redirect. In questo caso si utilizza l'helper redirect. Nel primo esempio scriviamo l'URL manualmente:

return redirect('home/dashboard');

mentre in quest'altro utilizzeremo una rotta particolare:

return redirect(route('myRoute'));

In questa terza parte relativa all'implementazione dell'applicazione Biblios svilupperemo alcuni controller di base. La loro implementazione sarà ancora una bozza in quanto per la versione definitiva dovremo prima parlare delle view. Modifichiamo quindi il comportamento della rotta / facendola puntare ad un metodo del nostro FrontendController:

Route::get('/', [ 'as' => 'home', 'uses' => 'FrontendController@getHome']);

Dato che la nostra applicazione conterrà un elenco di libri, possiamo già definire la seconda rotta parametrica che si occuperà di mostrare il dettaglio di un libro.

Route::get('/book/{id}', [ 'as' => 'bookDetail', 'uses' => 'FrontendController@getBookDetail']);

Implementiamo il nostro controller inserendo, temporaneamente, il contenuto direttamente nel codice in attesa del refactoring. Dato che stiamo per scrivere la nostra prima classe è necessario prima di tutto definire il namespace. Laravel ci offre un comando per impostare il namespace all'interno sia della applicazione che di Composer. Lanciamo quindi:

php artisan app:name Biblios

Una volta definito il nostro scope, creiamo il controller:

namespace Biblios\Http\Controllers;
class FrontendController extends Controller {
	public function getHome() {
		return "Io sono la homepage";
	}
	public function getBookDetail($id) {
		return "Io sono il dettaglio del libro " . $id;
	}
}

I controller sono come al solito testabili tramite il comando php artisan serve. Una volta avviato sarà possibile navigare su http://localhost:8000 e http://localhost:8000/book/123.