giovedì 8 ottobre 2009

symfony, struttura progetto

Prima di proseguire penso sia utile fare il punto su quanto sviluppato fino ad ora. Questo ci consente tra l'altro di spendere qualche parola su come è strutturato un progetto symfony.

Il progetto

La prima fase dello sviluppo (a parte l'installazione del framework che però si risolve semplicemente in un'operazione di copia di file) è stata la generazione della struttura del progetto. È quello che abbiamo fatto in Creazione progetto e applicazione.

Le applicazioni

Il progetto è diviso in una o più applicazioni. Per Lyra abbiamo iniziato lo sviluppo dell'applicazione di frontend, esisterà anche un'applicazione di backend.

Model View Controller

Un progetto symfony è strutturato secondo la logica del design pattern Model View Controller in base al quale un'applicazione può essere suddivisa in tre parti fondamentali.

La parte Model offre un'interfaccia verso il database e determina la logica applicativa. In symfony è costituita da una serie di classi in lib/model: alcune di queste sono generate dal framework in base alle informazioni contenute nel file config/doctrine/schema.yml (che abbiamo creato in Creazione schema database) e non devono essere modificate, altre possono essere personalizzate secondo le esigenze specifiche. Ne abbiamo parlato nell'articolo Generazione del Modello.

In un progetto come Lyra queste classi offrono i metodi per eseguire interrogazioni del database e compiere le operazioni di creazione, modifica, validazione e salvataggio dei dati.

La parte View si occupa della rappresentazione dei dati. In symfony è costituita da una serie di template scritti in PHP + HTML che si integrano con il layout globale di cui abbiamo parlato nell'articolo creazione modulo frontend e layout

La parte Controller elabora le richieste dell'utente. A seconda della richiesta specifica, se necessario viene invocato un metodo di un oggetto Model e restituita una risposta. La risposta tipica, anche se non l'unica possibile, è un documento HTML il cui aspetto è determinato dal layout e da un template. In symfony il Controller è costituito da un front controller ed una serie di action.

Front controller

Sono generati dal framework e suddivisi per applicazione ed ambiente; di ambienti non ho avuto occasione di parlare, per semplificare con riguardo a Lyra, abbiamo per il momento un ambiente di sviluppo e un ambiente di produzione.

Il front controller per l'ambiente di produzione della prima applicazione generata nel progetto (in Lyra, come di solito accade, il frontend) è chiamato index.php, gli altri front controller prendono il nome dell'applicazione più, per tutti gli ambienti diversi da produzione, un suffisso determinato in base all'ambiente.

I front controller costituiscono il punto di ingresso di ogni applicazione e devono poter essere invocati direttamente dal browser dell'utente: sono quindi collocati nella cartella web che come abbiamo visto (configurazione host virtuale in Creazione progetto e applicazione) è impostata come Document Root di Apache.

In Lyra questa cartella al momento contiene:

  • index.php - front controller di produzione dell'applicazione frontend.
  • frontend_dev.php - front controller di sviluppo dell'applicazione frontend.

In seguito saranno generati anche:

  • backend.php - front controller di produzione dell'applicazione backend.
  • backend_dev.php - front controller di sviluppo dell'applicazione backend.

Aprendo con un editor uno dei front controller notiamo che contiene poche righe di codice standard, che di regola non è necessario modificare, la cui funzione è quella di dare il via ad un processo che determina l'azione richiesta dall'utente.

Actions

Sono raggruppate in moduli. Ad ogni azione corrisponde di regola un template utilizzato per la risposta.

Ad esempio quando abbiamo creato il modulo article per il frontend di Lyra (vedi creazione modulo frontend e layout) è stato generato un file actions.class.php in apps/frontend/modules/article/actions.

Se apriamo il file noteremo una serie di metodi pubblici il cui nome inizia per execute: ne esiste uno per ogni azione elaborata dal controller. In apps/frontend/modules/article/templates troviamo i template corrispondenti.

Ad esempio l'azione show è processata da

class articleActions extends sfActions
{
  public function executeShow(sfWebRequest $request)
  {
      ...
  }
}

e il template corrispondente è showSuccess.php.

URL e routing

Gli utenti interagiscono con una applicazione web in diversi modi. Ad esempio:

  • digitando un indirizzo nel browser;
  • navigando un link;
  • inviando dati attraverso un form;
  • iniziando una richiesta AJAX.

Ognuna di queste modalità implica ricevere o inviare dati da/a una determinata URL. Quindi è attraverso la URL che si può determinare l'azione che l'utente richiede all'applicazione. In symfony le URL seguono un formato standard predefinito che come vedremo può però essere personalizzato:

front_controller.php/modulo/azione/parametri

dove i parametri sono costituiti da coppie di chiavi/valori separate da '/'. Poniamo di digitare il seguente indirizzo nel browser:

http://www.example.com/index.php/article/show/id/1

Assumendo che index.php sia il front controller dell'applicazione frontend nell'ambiente produzione (abbiamo visto sopra che di solito è così), stiamo eseguendo l'azione show del modulo article. Il framework eseguirà il metodo executeShow() della classe articleActions (apps/frontend/modules/article/actions/actions.class.php), all'interno del quale potremo accedere ai parametri della richiesta in questo modo:

class articleActions extends sfActions
{
  public function executeShow(sfWebRequest $request)
  {
      $id = $request->getParameter('id');
      ...
  }
}

Se la richiesta ha successo la risposta sarà data dal template showSuccess.php in apps/frontend/modules/article/templates, che ricordo verrà incorporato nel layout (apps/frontend/templates/layout.php).

Quindi una URL costituisce una rotta verso una determinata azione di un modulo. Le informazioni relative alle diverse rotte utilizzabili dall'applicazione si trovano in file in formato YAML (apps/frontend/config/routing.yml e i file omologhi per il backend ed eventuali altre applicazioni del progetto) che avremo modo di modificare più volte nel corso dello sviluppo.

La prossima volta si riprenderà il lavoro sull'applicazione, un quadro riassuntivo mi è sembrato utile per capire le operazioni che svolgeremo da ora in poi.

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.