Il Controller: gli URL

All'inizio della lezione precedente abbiamo visto come le action vengano richiamate dalle URL in base ad un meccanismo di routing. Questo meccanismo garantisce un'applicazione user-friendly e sicura. Alla base del meccanismo di routing c'è l'idea di considerare l'URL come parte dell'interfaccia: l'applicazione può formattare l'URL per fornire informazioni all'utente e l'utente può utilizzare l'URL per accedere alle risorse delle applicazioni.

In Symfony l'URL non è direttamente collegata con le istruzioni del server necessarie per fornire una risposta alla richiesta dell'utente ma è legata invece con la risorsa richiesta. Un esempio chiarirà meglio questo concetto. Prendiamo in considerazione il seguente URL (che non rispetta le convenzioni utilizzate da Symfony): http://www.biblioteca.it/web/controller/libri.php?type=5&year=2009.

Si nota subito che questo link fornisce all'utente informazioni a lui non necessarie e che rendono vulnerabile, dal punto di vista della sicurezza, l'applicazione. Infatti si legge chiaramente nell'URL l'architettura dell'applicativo e valori contenuti nel database ("5" e "2009").

Lo stesso risultato si può ottenere con il seguente URL che invece rispetta le convenzioni utilizzate da Symfony: http://www.biblioteca.it/libri/informatica/2009/lista-libri.html

Questo modo di scrivere l'URL offre numerosi vantaggi rispetto al primo: è più significativo (parlante), più facilmente memorizzabile e intuitivo (ad esempio si capisce che se si vuole ottenere la lista dei libri di narrativa anziché di informatica basta semplicemente sostituire la parola "informatica" contenuta nell'URL), più sicuro.

Ma come fa Symfony ad associare l'URL del secondo tipo con quello del primo tipo che, seppur con molti più svantaggi, sembrerebbe più vicino al modo di ragionare di un web-server? Symfony in realtà lavora con un sistema di routing che considera due tipi di indirizzi: una URL esterna (libri/lista-libri?type=informatica&year=2009) e un URI interna (<module>/<action>[?param1=value1][¶m2=value2]) che ha una sintassi molto simile a quella dell'URL classico

Figura 3: URI interna e URL esterna

Un file di configurazione, denominato routing.yml e contenuto all'interno della directory config di ogni singola applicazione definisce le regole di routing. Ad esempio nel Listato 5 possiamo considerare un file routing.yml adatto per l'esempio che stiamo trattando.

archivio_libri:
             url: libri/:type/:year/:title.html
             param: { module: libri, action: lista-libri }

Ogni regola di routing (archivio_libri) contiene una descrizione della sintassi (url) con una parte principale che identifica in sostanza il modulo (libri) da richiamare e una serie di eventuali parametri preceduti da /: (slash e due punti). Una seconda riga (param) serve per individuare modulo e action relativi associati al tipo di URL che ha quella sintassi.

Il sistema di routing analizza la richiesta pervenuta all'applicazione e cerca una corrispondenza tra l'URL e le definizioni contenute in routing.yml. Nell'esempio riportato, l'utente digita l'URL http://www.biblioteca.it/libri/informatica/2009/lista-libri.html. Il front controller si accorge che la sintassi dell'URL combacia con quella descritta dalla regola archivio_libri e il sistema di routing associa allora i seguenti parametri:

La richiesta viene quindi passata all'action lista-libri del modulo libri che (libri/lista-libri?type=informatica&year=2009), in base ai parametri passati, restituisce la lista di libri da mostrare.