Symfony 4: installazione e novità della nuova edizione

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, è ora di fare un upgrade. È sempre meglio stare in una versione stabile e duratura, perciò consiglio di consultare la panoramica del versionamento di PHP e scegliere una versione con supporto attivo (in verde). Se non hai la minima idea di cosa stiamo parlando, leggi come funziona il versionamento di un software. In questo momento (giugno 2019), la versione più idonea è la 7.3, supportata fino a dicembre 2020:

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

Una suite di extension generica può essere la seguente:

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

Al termine, riavviamo PHP:

sudo service php7.3-fpm restart

Installare Symfony 4

Partire è semplicissimo, basta aver già installato Composer, un gestore delle dipendenze di PHP, con cui potete installare librerie e framework con un semplice comando da terminale. Per scaricare la versione consigliata di Symfony, scegliete un nome per il vostro progetto (nel mio caso è zombie-blog) e poi digitate:

composer create-project symfony/skeleton zombie-blog
cd zombie-blog

Aspettate lo scaricamento dei file, che terminerà con una schermata del genere:

In questo momento abbiamo un sito già funzionante. Per vederlo in azione ora serve solo un webserver! In ambiente di produzione ci toccherà impostare uno dei tanti, come Apache2 o Nginx, mentre in fase di sviluppo (e solo in fase di sviluppo) possiamo benissimo farne a meno e sfruttare il webserver interno di PHP. Per avviarlo potremmo semplicemente digitare php -S 127.0.0.1:8000 -t public, ma vi consiglio di agire in un altro modo, per usare dei comandi più friendly e che possono darci qualche informazione in più. Installiamo il package server di Symfony:

composer require server --dev

Con l’opzione --dev abbiamo detto a Composer che vogliamo questo package solo per la fase di sviluppo (in produzione non ce ne faremmo niente). Al termine dell’installazione lanciamo il webserver:

bin/console server:run

La finestra di terminale corrente servirà a comunicarvi un po’ quello che sta succedendo: le richieste HTTP effettuate, se ci sono errori e così via. Non avete più interattività, quindi aprite una nuova scheda (tipicamente con CTRL + T) per poter digitare altri comandi.

Ad ogni modo, apriamo 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 installate da Composer e che non dobbiamo mai toccare. Questo vale a dire che abbiamo un progetto nuovo di zecca e ready-to-use. Appena cominceremo a mettere le mani sul progetto, installando package (che vedremo fra poco) o aggiungendo file, questa schermata scomparirà come per magia.

Parola d’ordine: flessibilità

Quella di installare package sarà una prassi di ogni progetto, più delle edizioni precedenti di Symfony, dove c’era già molta roba pre-installata. La ragione è molto semplice. Adesso la parola d’ordine è flessibilità. Vale a dire che SF4 è stato pensato per poter essere un framework molto potente, oppure un micro-framework snello ed efficace. Tutto ciò che è superfluo è stato 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. Significa che questo framework si adatta facilmente ad ogni contesto: potete realizzare siti piccoli, siti grandi, librerie, API, costruire un backend o un’app full-stack.

Flex

Se avete già utilizzato un’edizione precedente di Symfony, conoscerete bene il sistema dei cosiddetti bundle, concettualmente molto simili a dei plugin. In Symfony 4 questo termine è stato praticamente abbandonato e si parla di package. Una delle principali novità di quest’edizione è che gestire questi package è diventato semplicissimo, grazie a Flex. Si tratta di un plugin di Composer che in sostanza permette di fare due cose:

• Usare comandi più friendly nelle installazioni, attraverso gli alias
  In passato, per installare il package server, avremmo dovuto digitare composer require symfony/web-server-bundle --dev, ma è evidente che ricordare un comando del genere risulta un po’ ostico. Grazie a Flex, Composer è in grado di capire che siamo all’interno di un’app Symfony ed è in grado di usare degli alias, permettendoci di utilizzare il più elegante composer require server --dev.
• Abilitare e preconfigurare i package al posto vostro
  In generale, ad ogni package corrisponde sempre una configurazione da effettuare. In passato bisognava impostarla manualmente e ogni installazione era un bagno di sangue, soprattutto agli inizi. Flex, grazie alle recipes, ha reso questo step (quasi) un ricordo.

Package più importanti

Come abbiamo già detto, la nuova edizione di Symfony ha reso la maggior parte dei package opzionali. Di seguito illustro una carrellata di quelli più importanti.

Profiler

Dove saremmo senza? Si tratta di una toolbar di sviluppo in grado di fornirci dei parametri importanti per la salute delle nostre webapp, come il numero di chiamate al database, gli errori, la catena di redirect, tempi di esecuzione e così via. Assolutamente immancabile!

composer require profiler --dev

In futuro parleremo della funzione dump(), una variante sofisticata della var_dump() di PHP. Anche se non è strettamente necessario, vi consiglio il seguente package, che anziché stampare a video il risultato della dump, lo mostra nel profiler. È più comodo e supera alcune limitazioni – vi dico per esperienza – in situazioni particolari (ad esempio nelle chiamate Ajax).

composer require debug --dev

Twig

Twig è un template engine molto potente (vai alla puntata), immancabile in progetti fullstack. Molto usato anche al di fuori di Symfony, permette di estendere e includere template, di definire filtri, macro, funzioni e molto altro.

composer require twig

Doctrine

Doctrine (ORM/ODM) consente di mappare un database in una collezione di oggetti e di trattare le informazioni come tali (vai alla puntata). Non ragioneremo più in termini di tabelle, righe e colonne, ma in termini di oggetti, presumibilmente linkati tra di loro. È interessante sapere che si adatta al DBMS che utilizziamo, che sia MySql, PostgreSQL, MongoDB o altro. L’installazione richiede una piccola configurazione, per cui consiglio di seguire l’apposita puntata di questo corso.

composer require doctrine

Annotation

Le annotation sono dei metadata (cioè delle informazioni) contenute nei commenti. Un utilizzo tipico all’interno di Symfony è quello per definire la rotta (cioè l’URL) di una pagina. Non si tratta di un package immancabile come altri e se ne può fare a meno, ma risulta molto comodo se si vuole un’organizzazione dei metadati distribuita. Io ne faccio uso nei miei progetti e li userò anche in questo corso.

composer require annotation

Security

Inseririsco 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

---

Siamo arrivati al termine della puntata, ma ora si fa sul serio! Nel prossimo articolo del corso vedremo com’è strutturato un progetto Symfony e come viene processata una nuova richiesta HTTP.