Symfony 2: il framework PHP per il Web moderno

Questo articolo fa parte di una serie dedicata alla comparazione di Framework PHP.

Introduzione

Symfony si presenta come un framework php che consente agli sviluppatori di realizzare applicazioni web complesse in modo facile e veloce. Nel momento in cui scrivo la versione stabile è la 2.0.5 che supporta PHP a partire dalla versione 5.3.2, una delle versioni più recenti del linguaggio. Penso che questa richiesta sia eccessiva. In pratica chi non dispone si un server dedicato o di un buon hosting, è impedito nell’utilizzare il framework.

Installazione

È possibile utilizzare diverse versioni di Symfony. In questo articolo utilizzeremo la versione standard 2.0.5 che è possibile scaricare dalla pagina di download del sito ufficiale, lasciando ai lettori la curiosità di provare le altre versioni. La prima cosa da fare dopo aver caricato il contenuto del framework sul nostro server è quello di verificare se sono rispettati tutti i pre-requisiti. Il link per farlo, da modificare a secondo del vostro server, è http://localhost/Symfony/web/config.php.

Symfony, nel mio caso, ha presentato come problema da risolvere l’abilitazione di una delle librerie SQLite3 o PDO_SQLite. È una cosa estremamente fastidiosa: e se volessi usare solo Mysql? Abilitate le librerie, se vi è possibile, dovrebbe comparire il link Salta configurazione e vai alla pagina di benvenuto. I file di configurazione del framework, presenti sotto la directory app/config/, sono dei file di tipo yml. Non condivido la scelta. Avrei preferito un file di configurazione php costituito da un semplice array.

Pattern MVC

Come nella versione precedente del framework esistono due front controller: uno usato in fase di sviluppo e uno usato in fase di produzione. Questi sono presenti all’interno della cartella /web della nostra applicazione e sono chiamati, rispettivamente, app_dev.php e app.php. In essi si nota l’uso, perdonate il gioco di parole, della direttiva use. Quindi se non avete l’ultima versione del php non potete andare avanti! Nella guida di Symfony si enfatizza molto questa cosa. Sinceramente penso che si poteva ottenere lo stesso risultato utilizzando strumenti che consentissero di utilizzare anche versioni precedenti del php.

Ora scendiamo nell’"orrido". Seguendo la guida in linea il nostro controller si troverà nella posizione:

src/Acme/HelloBundle/Controller/

Il nome del file sarà ovviamente helloController.php. In esso si deve fare riferimento al namespace e all’uso della classe base controller:

namespace AcmeHelloBundleController;
use SymfonyComponentHttpFoundationResponse;

La classe del controller estende quindi la classe base il cui nome è costituito dal nome della classe con il suffisso controller. Le iniziali scritte in maiuscolo. Le azioni costituiscono i metodi della classe stessa e il loro nome è costituito dal nome dell’azione con il suffisso action. In questo caso si usa la notazione "CamelCase" (unione di parole con le iniziali maiuscole). Gli autori specificano chiaramente che il nostro controller non è rappresentato dalla classe ma bensì dai suoi metodi. La classe quindi sarebbe solo un contenitore di controller simili. Se fosse tutto qui sarebbe una lieta notizia. Ma non è così.  Affinché tutto funzioni , e quindi possiate utilizzare il controller, gli autori hanno ben pensato di utilizzare una mappatura dei controller all’interno di un file di configurazione di routing.

A nostro parere ciò è un punto a sfavore nella scelta di Symfony come framework. “Symfony - si può leggere online - non si propone come un framework MVC” ma come un framework Reuquest / Response. Posso anche accettarlo. Ma perché fare una pessima implementazione di MVC? Secondo me era meglio non farla proprio. I metodi delle classi controller restituiscono sempre un oggetto di tipo Response. Per renderizzare una vista ci sono due possibili soluzioni. Utilizzare il metodo renderView, che restituisce un contenuto, o usare il metodo render che restituisce un oggetto response. Nel primo caso si deve passare il contenuto restituito dalla vista al costruttore della classe response:

return new Response($content);

In Symfony le viste sono discusse sotto la voce templates. I template sono dei semplici file di testo che permettono di rappresentare i file più comuni: html, xml e csv. In Symfony si fa distinzione tra due diversi tipi di template: il classico php template, cioè una pagina che contiene codice php che sarà interpretato dal web server, o un template di tipo twing. Twig rappresenta, secondo gli autori della guida ufficiale del framework, il punto di forza del sistema di template.

Personalmente preferisco l’utilizzo del classico sistema a template php anche perché, se decido di utilizzare un framework, è per velocizzare lo sviluppo. Studiare un sistema di templating esterno, per quanto possa essere interessante, allungherebbe i tempi che occorrono per lavorare con Symfony. Il tipo di templating che si desidera utilizzare deve essere specificato nel file di configurazione dell’applicazione. Di default è impostato, come si può ben immaginare, twig. Infine una nota positiva:è possibile mostrare a video un response senza utilizzare un template.

Database

A differenza della precedente versione in cui si faceva uso di Propel, Symfony 2 utilizza per la manipolazione dei dati il conosciuto ORM Doctrine.  Prima di avere i nostri model dobbiamo ovviamente configurare l’applicazione per interagire con il database. I dati di configurazione si trovano nel già citato file config.yml. A seguito di ciò conviene utilizzare la “comoda" possibilità offerta dal framework di auto generare i file che occorrono. Prima bisogna inviare un comando che ispezioni il database, e scriva quindi un file di metadati contenente tutte le informazioni sulla struttura della nostra base di dati, e, dopo, ci si può occupare di scrivere i file delle nostre classi.

La domanda è ovviamente: perché il doppio passaggio? Sinceramente preferisco il sistema adottato dal framework Yii in cui basta passare il nome della tabella per avere la classe pronta da utilizzare.  Le classi , ma anche i file, utili per lavorare con il database, meglio definite come entità dagli autori, possono essere realizzate anche in modo manuale. È chiaro che fare tutto il lavoro a mano sarebbe poco conveniente sia in termini di tempo che di utilità. Utilizzare il model in Symfony è tanto facile quanto usare l’orm Doctrine in quanto, come già detto, l’accesso e la manipolazione dei dati è gestita attraverso di esso. Proprio per questo Symfony esprime tutta la sua forza nella manipolazione dei dati.

Validazione

Symfony fa uso del componente validator che si appoggia su una specifica java (JSR303 Bean Validation specification), per la validazione dei dati. L’uso è molto semplice. È infatti sufficiente richiamare il metodo isValid su un oggetto form, o il metodo validate su un'entità, per verificare la correttezza dei dati. La nota dolente è che anche in questo caso le regole di validazione devono essere inserite all’interno del famoso file di configurazione. La validazione dei dati quindi si riduce a scrivere correttamente le regole nel file di configurazione.

Ajax

Una cosa che non dovrebbe mancare in un framework 2.0 è il supporto ad Ajax. Con questo termine intendo la possibilità, mediante il richiamo di un metodo di una apposita classe, di inserire in una pagina il codice necessario per effettuare semplici chiamate Ajax. Non ho riscontrato nessuna classe adatta a questo scopo. Ciononostante il framework integra perfettamente Ajax tradizionale. Considerando che quest’ opzione sarebbe un plus per il framework, non me la sento di considerarlo come aspetto negativo.

Caching

Una delle caratteristiche più interessanti di Symfony riguarda senza dubbio la cache. Questo framework sfrutta una tecnologia denominata Edge Side Includes (ESI). In pratica Symfony sfrutta la normale gateway cache ma, inserendo all’interno delle pagine servite dalla cache degli appositi tag che identificano la tecnologia ESI, consente di prelevare dal server esclusivamente quella porzione di codice invece che tutta la pagina. Questa soluzione è ovviamente utile in caso di siti dinamici.

Autenticazione

Symfony, come tutti gli altri framework analizzati, dispone di un sistema per la gestione dell’autenticazione e delle autorizzazioni. L’autenticazione può essere effettuata sia sfruttando l’autenticazione http sia utilizzando un classico modulo di login. Per fare questo è sufficiente configurare opportunamente il framework modificando i file di configurazione. In questo caso gli autori consigliano di inserire le configurazioni relative all’autenticazione in un file separato e in particolare nel file security.yml. Nulla vieta, in accoppiata con il componente per l’ACL, di realizzare un sistema di autenticazione e autorizzazione personalizzato.

Internazionalizzazione e localizzazione

Anche in questo campo Symfony è riuscito a sorprendermi positivamente. Ha decisamente un'ottima gestione dell’internazionalizzazione. La cosa interessante è la personalizzazione degli url in base alla cultura. In pratica suggerisce di inserire negli url sempre la cultura in modo da avere prestazioni superiori nel campo dell’indicizzazione sui motori di ricerca. Addirittura seguendo i consigli della guida, si scopre che è incredibilmente semplice recuperare i dati dal database in funzione della cultura dell’utente.

Supporto e guide

Nella pagina della documentazione di Symfony si trovano svariati link tra i quali quelli della cosiddetta “Bibbia” sul framework e una serie di piccoli articoli sui principali argomenti. Nel menu in alto, proprio alla sinistra del link documentation, c’è il famoso pulsante get started. Tornando alla pagina della documentazione spiccano il glossario, reference documents e per finire la guida alle api. La community è composta da forum, mailing list, blog e chat. Il forum è abbastanza frequentato ma, così come per la guida, è esclusivamente in lingua inglese.

Ulteriori caratteristiche

Per gli amanti del genere Symfony fornisce una graziosa toolbar che consente di effettuare il debug delle pagine in modo facile e veloce. Non è una cosa necessaria per un framework ma è pur sempre un qualcosa in più rispetto agli altri.  Inoltre fa uso di monolog per la scrittura dei log.