Strutturalmente, alla base di un'applicazione realizzata utilizzando il framework Symfony abbiamo quello che viene definito un modulo, quest'elemento ha il compito di raggruppare pagine; ogni pagina consiste a sua volta in un'azione e in un template rispettando la logica del pattern MVC su cui si basa il framework.
I templates sono destinati al contenere i vari elementi presentati all'interno di una pagina (testi, collegamenti ipertestuali, form per l'invio di input etc.); l'azione ha invece il compito di gestire questi elementi sulla base delle finalità previste dallo sviluppatore. In questo breve articolo vedremo quali strumenti sono necessari per la creazione di un modulo completo di pagine con templates e azioni.
Generazione di un modulo tramite linea di comando
Symfony suddivide le pagine di un sito Web in moduli differenti, quindi una pagina non potrà prescindere da un modulo che la contenga; un modulo potrà invece anche essere vuoto purché la sua struttura interna sia coerente con la disposizione dei file richiesta dal framework
Uno dei grandi vantaggi nell'utilizzo di symfony sta nel fatto che la generazione dei moduli può essere automatizzata tramite semplici istruzioni inviate da linea di comando. Per far questo sarà necessario richiamare il comando apposito, denominato init-module che dovrà essere seguito dal nome dell'applicazione e da quello del modulo che dovrà essere creato:
> cd ~/nome_progetto > symfony init-module nome_applicazione nome_modulo >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/actions >> file+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/actions/actions.class.php >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/config >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/lib >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/templates >> file+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/templates/indexSuccess.php >> dir+ ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/validate >> file+ ~/nome_progetto/test/functional/nome_applicazione/nome_moduloActionsTest.php >> tokens ~/nome_progetto/test/functional/nome_applicazione/nome_moduloActionsTest.php >> tokens ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/actions/actions.class.php >> tokens ~/nome_progetto/apps/nome_applicazione/modules/nome_modulo/templates/indexSuccess.php
Dall'azione del comando appena lanciato abbiamo come risultato la creazione di 3 file:
- test/nome_moduloActionsTest.php utile per le unità di test dell'applicazione;
- templates/indexSuccess.php che symfony restituisce senza alcun contenuto
- actions/actions.class.php che ha il compito di rindirizzare alla pagina di benvenuto del framework;
Osservando il codice contenuto all'interno della pagina actions/actions.class.php possiamo osservare infatti il seguente listato:
class nome_moduloActions extends sfActions
{
public function executeIndex()
{
$this->forward('default', 'module');
}
}
Questo codice è necessario perché in Symfony per ogni modulo deve essere definita un'azione index; come è facile osservare questa azione è ottenuta attraverso la chiamata ad un metodo denominato executeIndex e da un template che è poi il file indexSuccess.php.
Riepilogando, possiamo dire che le azioni non sono altro che metodi chiamati execute(Nome_Azione) appartenenti alla classe (nomeModulo)Actions che a sua eredita da un'altra classe denominata sfActions il cui compito è quello di eseguire la logica della richiesta corrente. Le azioni di una classe (raggruppate per moduli) vengono archiviate nel file actions/actions.class.php interno al modulo.
Per comodità dello sviluppatore è bene precisare che anche se i nomi riferiti ai metodi non sono case-sensitive per PHP, lo sono invece per il framework; quindi è necessario che il nome di un'azione cominci con il preffisso execute scritto in minuscolo e seguito dal nome completo dell'azione specificata con la prima lettera maiuscola.
Inserimento di pagine ed azioni
Come abbiamo sottolineato in precedenza, i moduli in Symfony sono destinati a contenere pagine, i comportamenti che le pagine sono destinate a creare vengono archiviati tramite azioni, per quanto riguarda invece la presentazione della pagine, questa verrà affidata ai template. È possibile che un pagina non sia destinata a produrre comportamenti e che non partecipi alla logica dell'applicazione, per essere riconosciuta dal framework essa dovrà in ogni caso contenere almeno un'azione vuota.
Le azioni disponibili per lo sviluppo non sono dettate da Symfony, l'utilizzatore avrà la possibilità di inserire azioni proprie semplicemente rispettando la sintassi richiesta (nome dell'azione con la prima lettera maiuscola), per il resto il cuore di un'azione rimane il metodo execute. Per cui la creazione di un'azione consiste semplicemente nell'inserimento di un nuovo metodo con suffisso execute all'interno della classe definita al momento della generazione del modulo:
class nome_moduloActions extends sfActions
{
public function executeNomeAction()
{
}
}
Il comportamento generato da questa azione non sarà immediatamente eseguibile, ora abbiamo infatti un'azione ma la nostra pagina non è completa in quanto Symfony impone la presenza di un template, una logica di presentazione che nel nostro caso dovrà essere fornita dal file nomeActionSuccess.php.
Inserimento di un template
Una volta generati progetto, applicazione e modulo per avere una prima pagina con Symfony è necessario associare ad essa un'azione ed un template; azione e template sono due entità strutturalmente indipendenti ma funzionalmente complementari.
Fisicamente un template è individuabile come un semplice file archiviato all'interno della cartella templates/ di un modulo; questo file avrà come nome il nome dell'azione che verrà rindirizzata da esso, per cui all'azione nomeAction corrisponderà un template nomeActionSuccess.php.
Il suffisso Success è un altro elemento molto ricorrente nelle pagine di Symfony insieme al prefisso execute che abbiamo visto in precedenza, esso non è altro che il termine utilizzato di default dal framework per identificare un'azione.
Concettualmente per Symfony (e non solo) un template corrisponde ad un insieme di tag per la formattazione di contenuti, il classico markup HTML per la presentazione di testi e immagini. Per cui potremmo avere un esempio di template simile al seguente:
<p>La mia prima pagina creata con <strong>Symfony</strong>. <em>Claudio</em>.</p>
Dove la stringa "La mia prima pagina creata con Symfony. Claudio." è il contenuto da presentare in un modo desiderato e definito attraverso il markup HTML che costituisce il template. Dato che uno degli obiettivi nell'utilizzo di questo framework è quello di separare nettamente il codice di presentazione da quello dell'applicazione, è bene che nel template sia presente quanto meno codice PHP possibile.
Se però è necessario aggiungere qualche riga di PHP al semplice HTML questo dovrà essere fatto rispettando una sintassi in grado di separare gli elementi dinamici da quelli statici. Sarà per esempio possibile generare un template in entrambi i modi seguenti:
<p>La mia prima pagina creata con <strong>Symfony</strong>. <em>Claudio</em>.</p>
<?php
if ($test)
{
echo "<p>".time()."</p>";
}
?>
oppure:
<p>La mia prima pagina creata con <strong>Symfony</strong>. <em>Claudio</em>.</p> <?php if ($test): ?> <p><?php echo time(); ?></p> <?php endif; ?>
La prima sintassi, che potremmo definire standard, va bene per le azioni ma non per la creazione di template; la seconda, che potremmo definire alternativa, è invece accettabile per i template perché rispetta 3 semplici regole:
- non contiene parentesi graffe;
- il codice HTML non viene prodotto come output da PHP;
- le istruzioni PHP sono contenute in una sola riga.
In questo modo il lavoro del webdesigner sarà estremamente facilitato dal fatto di poter individuare immediatamente gli elementi di presentazione e potrà agire solo su quelli senza dovere intaccare la parte applicativa della pagina.
Variabili e attributi
Un discorso a parte è quello relativo alle variabili, il framework infatti da la possibilità di accesso diretto ad esse una volta che queste vengono definite all'interno di un'azione, in pratica ciò che avviene non è altro che un passaggio di informazioni tra azione e template.
Il semplice codice seguente definisce un attributo la cui informazione sarà contenuta all'interno di una variabile:
class nome_moduloActions extends sfActions
{
public function executeNomeAction()
{
$data = getdate();
$this->anno = $data['year'];
}
}
L'attributo $this->anno diventa così disponibile all'interno del namespace globale è potrà essere riutilizzato all'interno di un template tramite la variabile $anno:
<p>Siamo nell'anno <?php echo $anno ?>.</p>
I dati relativi a contesto, richiesta, parametri di richiesta e sessioni correnti sono contenuti negli oggetti $sf_context, $sf_request, $sf_params, e $sf_user e possono essere utilizzati attraverso una semplice chiamata ai relativi metodi, si tratta di vere e proprie variabili d'ambiente messe a disposizione dal framework. I template hanno un accesso nativo a questi attributi che non devono essere quindi definiti all'interno di alcuna azione.
Conclusioni
In questo capitolo abbiamo analizzato il ruolo fondamentale svolto dalle diverse componenti che costituiscono un'applicazione realizzata tramite il framework Symfony: moduli, pagine, azioni e template.
Particolare attenzione è stata data alla sintassi da associare a ciascun elemento e ai metodi più ricorrenti durante la definizione delle diverse parti e alla separazione tra presentazione e codice dinamico.
Il nostro prossimo passo sarà quello di creare una prima applicazione con symfony; per approfondimenti si consiglia di consultare il Wiki in Italiano dedicato a symfony, utile fonte di informazioni per la stesura di questo articolo.
