Symfony 4: come creare nuove pagine

Vediamo come creare nuove pagine in Symfony, cercando di capire qualcosa di più riguardo a Controller, Routing e Templating

Creare nuove pagine Symfony

Finalmente entriamo nel vivo! Nell’ultimo articolo abbiamo capito come Symfony è strutturato e gestisce una richiesta. È importante sapere cosa c’è dietro le quinte, ma nella pratica è tutto molto più semplice, perché lo sviluppatore deve occuparsi solo dell’essenziale. Man mano che andiamo avanti, vi consiglio di affiancare il vostro editor (o IDE) preferito e provare in prima persona.

Controller

Creiamo il file /src/Controller/DefaultController.php, ed inseriamo il seguente codice:

Cosa gli stiamo dicendo?

Con poche righe abbiamo creato il Controller DefaultController, contenente l’Action homepage(). Un Controller, dal punto di vista del codice, è una classe che estende una utility del framework (Symfony\Bundle\FrameworkBundle\Controller\Controller) contenente molti metodi utili, che vedremo lungo la strada. Potete vedere un Controller come un contenitore di Action, ossia metodi che in linea di massima corrispondono ad una URL. Quindi, per creare una nuova pagina, creiamo una nuova Action.

In un progetto possono esistere più Controller e ognuno può contenere più Action.

Le rotte

Come potete vedere nell’esempio precedente, nelle annotation (che ricordiamo, non sono dei semplici commenti, ma contengono microdata utili al framework) è definita una rotta di nome home e corrispondente al path /. Perciò andiamo col browser su http://127.0.0.1:8000/ et voilà, dovremmo vedere il testo Zombie World sullo schermo.

Dare un nome ad ogni rotta è importante, perché rende il sistema di routing di Symfony estremamente potente. Provate ad immaginare un sito enorme, con tantissime pagine e con molti link. Immaginate ora che ci sia la necessità di cambiare un indirizzo: è un suicidio pensare di modificarlo manualmente nell’intero progetto. Con il sistema delle rotte, invece, questo probema non c’è, perché nel codice facciamo riferimento al nome della rotta, non al path. Chiaramente, se si tratta di pagine indicizzate, bisogna gestire questa cosa anche lato SEO (redirect, segnalazione a Google, eccetera).

Request e Response

Nel precedente articolo abbiamo parlato di due oggetti molto importanti nell’ecosistema Symfony, Request e Response. Ogni volta che visitiamo una pagina, Symfony crea un oggetto Request e trova la Action da eseguire, che ritorna un oggetto Response. Quindi l’Action rappresenta (indicativamente) la prima porzione di codice scritta dall’utente sviluppatore e ritorna sempre un oggetto Response.

Per capire meglio come stanno le cose, vi consiglio di dare un’occhiata attraverso la fantastica funzione dump, con la quale debuggare diventa un piacere. Comparirà a video un box nero con cui potete esplorare il contenuto di oggetti, array, qualunque cosa. Provateci:

In questo caso, vedrete che l’oggetto Request contiene parametri tipici di una richiesta HTTP, come l’URL, la lingua del client, cookie ed header di vario genere.

L’oggetto Response, invece, contiene parametri tipici di una risposta HTTP, come lo status code (200 per una risorsa trovata, 404 per una non trovata, 301 per un redirect, eccetera) e il contenuto, ossia l’HTML (o altro formato). A partire dall’oggetto Response (PHP, server side), verrà poi generata la vera risposta HTTP da mandare al client.

I template

L’argomento dell’oggetto Response non è semplice testo, ma è HTML che il browser dovrà renderizzare. Avrete capito che il codice client side va tutto lì dentro. Bello no? A dire il vero no, noi vogliamo usare i template e riempirli di CSS, quindi vediamo come fare.

Sia chiaro, innanzitutto, che la gestione del front-end può avvenire in diversi modi. Quello più semplice, più documentato e più diffuso vede al centro di tutto Twig, un componente che si occupa di gestire il lato presentazionale della webapp attraverso funzionalità decisamente interessanti. Proviamolo. Aggiungiamo una nuova pagina, quindi aggiungiamo una nuova Action al nostro DefaultController, e poi creiamo il file /templates/Default/pizza.html.twig:

Andiamo su http://127.0.0.1:8000/pizza…

Ciao, sono Antonio! La mia pizza preferita è la Margherita
Torna alla home

Forte, no? Con il minimo impegno capirete che il primo argomento del metodo render specifica il template, mentre il secondo è un array utilizzato per passare dati a Twig. Con le doppie parentesi graffe, nel template, facciamo una stampa delle variabili. Da notare che per inserire un link alla home abbiamo usato la funzione di Twig path, che riceve come argomento il nome della rotta (come dicevamo prima, per sfruttare il sistema di routing) e ritorna l’indirizzo reale, che verrà inserito nell’HTML generato.

Quindi, il metodo render non fa altro che ritornare lo stesso oggetto Response di sempre (con lo status HTTP e il contenuto HTML), ma sta volta il codice per il client è generato da Twig a partire da un template. Non vorrei essere banale, ma è bene mettere in chiaro che Twig è PHP sotto mentite spoglie, perciò il motore Twig, estremamente potente e ricco di funzionalità, gira sul server: si tratta Server Side Rendering.

In questo breve articolo abbiamo visto piccole pillole di un mondo molto vasto, ma con cui è facile apprezzare la potenza di questo framework. Nel prossimo articolo vedremo più da vicino cosa può offrire un template engine potetente come Twig.

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