Symfony 4: installazione e novità della nuova edizione

Il 30 novembre 2017 è stata rilasciata la prima versione stabile della quarta edizione, vedremo come installarla e quali sono le novità

Installazione Symfony 4

Siamo al secondo appuntamento di questo corso su Symfony 4. Nell’articolo introduttivo abbiamo visto innazitutto cos’è un framework e abbiamo appena sbirciato nel mondo che si cela dietro questo nome, complesso, ma molto flessibile. È giunto il momento di sederci al PC e muovere i primi passi.

Sono su una macchina Linux, perciò farò riferimento ad una shell Unix per i comandi da terminale.

Aggiornare PHP

Symfony 4 richiede almeno PHP 7.1, perciò, se siete rimasti indietro (nonostante PHP sia attualmente alla versione 7.2), è ora di fare un upgrade:

sudo add-apt-repository ppa:ondrej/php
sudo apt-get update
sudo apt-get install php7.1

Una suite di extension generica può essere la seguente:

sudo apt-get install php7.1-cli php7.1-common php7.1-json php7.1-opcache php7.1-mysql php7.1-mbstring php7.1-mcrypt php7.1-zip php7.1-fpm php7.1-xml

Riavviamo PHP:

sudo service php7.1-fpm restart

Installare Symfony 4

Partire è semplicissimo, basta aver già installato Composer. Per scaricare la versione consigliata, basta digitare:

composer create-project symfony/skeleton my-project

Se siete interessati ad installare una versione in particolare, potete specificarla come ulteriore argomento; ad esempio per utilizzare Symfony 3.4 (se siete confusi riguardo al significato di quei numeri, leggete come funziona il versionamento di un software):

composer create-project symfony/skeleton my-project "3.4.*"

Il comando di installazione scaricherà tutte le librerie appena necessarie per far funzionare il framework:

Termine dell’installazione di Symfony 4

In questo momento abbiamo già un sito funzionante. Dal terminale entrate in my-project e digitate:

php -S 127.0.0.1:8000 -t public

In questo modo abbiamo avviato il webserver interno di PHP (mi raccomando, da non utilizzare in produzione). Se avete mai installato un’edizione precedente di Symfony, potreste storcere un po’ il naso, perché ricorderete che il server si avviava con un elegantissimo e verboso:

bin/console server:run

Il package per fare questa cosa è opzionale e basta aggiungerlo al progetto con Composer:

composer require server --dev

In realtà, ad essere opzionali sono molti package che nelle versioni precedenti venivano installati di default. La ragione è molto semplice. La parola d’ordine col nuovo framework è flessibilità. Vale a dire che SF4 è stato pensato per poter essere un framework molto potente, oppure un micro-framework snello ed efficace. Perciò è chiaro che tutto ciò che è superfluo viene eliminato, tant’è che una nuova installazione contiene il 70% di codice in meno rispetto a Symfony 3. C’è solo lo stretto indispensabile per far galleggiare la barca. E lasciatemelo dire, adoro questa filosofia.

L’uscita di Symfony 4 praticamente coincide con l’elogio funebre di Silex, il micro-framework basato sui Symfony Components, che a questo punto non ha più senso di esistere. Inoltre, pensate a chi si avvicina per la prima volta ad un framework PHP. Può cominciare con qualcosa di piccolo e man mano che la confidenza aumenta può aggiungere nuovi elementi al progetto, fino ad arrivare alla versione “Super Sayan”, senza dover rifare tutto da capo. L’esperienza didattica ne giova parecchio e sono sicuro che il successo di Symfony dipenderà anche da questo.

Torniamo a noi. Dopo aver avviato il server, con il browser andiamo su http://127.0.0.1:8000 e vedremo qualcosa del genere:

A differenza delle edizioni precedenti, il file che renderizza questa schermata è da qualche parte nei vendor, cioè tra le dipendenze, che non dobbiamo toccare. Questo vale a dire che abbiamo un progetto nuovo di zecca e ready-to-use.

Come dicevamo poco fa, sono molti i package che mancano e che prima trovavamo di default, come Twig e Doctrine, che vedremo tra un attimo. Gestire questi package è semplicissimo grazie ad un’importante novità: Flex. Si tratta di un plugin di Composer che permette principalmente di fare due cose:

  • Rendere le installazioni più friendly, attraverso gli alias;
  • Abilitare e preconfigurare i package al posto vostro;

Package più importanti

Se avete già utilizzato un’edizione precedente di Symfony, conoscerete bene il sistema dei bundle, concettualmente molto simili a dei plugin. In Symfony 4 il concetto di bundle un po’ svanisce e si parla di package. Ce ne sono alcuni che ritengo fondamentali, perché cambiano totalmente l’esperienza di sviluppo. Vediamone alcuni e come installarli:

Profiler

Dove saremmo senza questo componente? Si tratta di una toolbar da utilizzare in modalità di sviluppo, la quale ci dà importanti indicazioni sulla salute della nostra webapp, come il tempo di esecuzione della richiesta, il contenuto di una richiesta e della relativa risposta, il numero e il tempo di esecuzione delle query in quella pagina e così via. Assolutamente immancabile, perciò eseguiamo subito:

composer require profiler

Twig

Twig è un template engine molto potente, grazie al concetto di estensione e di inclusione dei template e trovo anche questo package immancabile, specie in progetti con serverside rendering (altrimenti si presuppone che ci sia una gestione dei template lato front-end, ma varia di caso in caso). A dirla tutta, Twig è una dipendenza di Profiler, perciò, se abbiamo già installato il componente precedente, abbiamo già Twig, altrimenti questo è il comando per l’installazione:

composer require twig

Doctrine

Doctrine è un ORM (Object-Relational Mapping) PHP. In pratica consente di mappare un database in una collezione di oggetti, e di trattare le informazioni come tali. Non ragioneremo più in termini di tabelle, righe e colonne, ma in termini di oggetti, linkati tra di loro. È interessante sapere che si adatta al DBMS che utilizziamo, quindi può essere utilizzato con MySql, PostgreSQL, MongoDB.

composer require doctrine

Annotation

Le annotation sono delle metadata (cioè delle informazioni) embeddate nei commenti formattati in un certo modo. Esempi tipici possono riguardare la rotta (cioè l’URL) da seguire, o il template da renderizzare. Non si tratta di un package immancabile come gli altri, c’è chi li ama e chi li detesta. Si portano dietro una serie di vantaggi e svantaggi, da considerare soprattutto in ambito di manutenibilità e capita che perfino Symfony, nella documentazione, ne sconsigli l’utilizzo. D’altra parte possono essere molto comode in alcuni contesti. A voler essere brevi, tutto sta nel valutare se è meglio avere un’organizzazione dei metadati centralizzata o distribuita. Lascio a voi approfondire, nel caso questo è il comando per l’installazione:

composer require annotation

Security

Inserirei anche questo package tra gli immancabili, perché aiuta a gestire due aspetti fondamentali della cyber security: authentication e authorization. Cioè aiuta a stabilire chi può accedere alla web app e chi può eseguire una determinata azione.

composer require security

A questo punto dovreste avere una base piuttosto comune, ma chiaramente varia di caso in caso. È da notare che nelle scorse edizioni, a questo punto, avevamo ancora da configurare tutti i package, aggiungendo il setup in un file di configurazione globale e dichiarando esplicitamente il package installato al kernel. Grazie a Flex, invece, tutto questo avviene in automatico e siamo già pronti per sporcarci le mani sul serio.

Nel prossimo articolo del corso vedremo com’è strutturato un progetto Symfony e come viene processata una nuova richiesta HTTP.

L'autore

Ciao, sono Antonio D'Amore, e sono un ingegnere informatico con la forte passione per il web. Sguazzo nell'ambiente startup, grazie a Tobevy, di cui sono co-founder e CTO, e adoro la divulgazione, ragion per cui ho creato questo blog