2. Un approccio allo sviluppo MVC in web/PHP

Proponiamo qui un approccio per lo sviluppo di applicazioni web/PHP che rispettino l’architettura MVC. Esso ha solo lo scopo di fornire spunti. Il lettore lo adatterà ai propri gusti ed esigenze.

Si inizierà definendo tutte le viste dell’applicazione. Queste sono le pagine web presentate all’utente. Ci si metterà nei panni dell’utente per progettare le viste. Si distinguono tre tipi di viste:
- il modulo di inserimento dati, che serve a ottenere informazioni dall’utente. Di solito è dotato di un pulsante per inviare al server le informazioni inserite.
- la pagina di risposta, che serve esclusivamente a fornire informazioni all’utente. Spesso questa pagina dispone di uno o più link che consentono all’utente di proseguire l’utilizzo dell’applicazione con un’altra pagina.
- la pagina mista: il controller ha inviato al client una pagina contenente informazioni da esso generate. Quella stessa pagina servirà al client per fornire al controller nuove informazioni provenienti dall’utente.

Ogni vista darà origine a una pagina PHP. Per ciascuna di esse:
- si definirà l’aspetto della pagina
- si determineranno quali sono le parti dinamiche della stessa:
  - le informazioni destinate all’utente che dovranno essere fornite dal controller come parametri alla vista PHP. Una soluzione semplice è la seguente:
    - il controller inserisce in un dizionario $dReponse le informazioni che desidera fornire a una vista V
    - il controller fa visualizzare la vista V. Se questa corrisponde al file sorgente V.php, tale visualizzazione si ottiene semplicemente tramite l'istruzione include V.php.
    - L’inclusione precedente è un’inclusione di codice all’interno del controller. Il dizionario $dReponse, compilato da quest’ultimo, è accessibile direttamente tramite il codice di V.php.
  - I dati immessi che dovranno essere trasmessi al programma principale per l’elaborazione. Questi dovranno far parte di un modulo HTML (tag <form>).

È possibile schematizzare gli I/O di ciascuna vista

gli ingressi sono i dati che il controller dovrà fornire alla pagina PHP
le uscite sono i dati che la pagina PHP dovrà fornire al controller dell’applicazione. Fanno parte di un modulo HTML e il controller li recupererà tramite un'operazione del tipo $_GET["param"] (metodo GET) oppure $_POST["param"] (metodo POST).

Spesso la pagina finale inviata al cliente non è una singola vista, ma una composizione di viste. Ad esempio, la pagina inviata a un utente può avere la seguente struttura:

L’area 1 può essere un banner di titolo, l’area 2 un banner di menu, l’area 3 un’area di contenuto. In PHP questa composizione può essere ottenuta tramite il seguente codice HTML/PHP:

<table>
    <tr>
        <td><?php include zone1.php ?></td>
    </tr>
    <tr>
        <td><?php include zone2.php ?></td>
        <td><?php include zone3.php ?></td>
    </tr>
</table>

È possibile rendere questo codice dinamico scrivendo:

<table>
    <tr>
        <td><?php include $dReponse['urlZone1'] ?></td>
    </tr>
    <tr>
        <td><?php include $dReponse['urlZone2'] ?></td>
        <td><?php include $dReponse['urlZone3'] ?></td>
    </tr>
</table>

Questa composizione di viste può costituire l'unico formato della risposta fornita all'utente. In questo caso, ogni risposta al cliente dovrà specificare i tre URL da caricare nelle tre aree prima di visualizzare la pagina di risposta. È possibile generalizzare questo esempio immaginando che esistano diversi modelli possibili per la pagina di risposta. La risposta al cliente dovrà quindi:

specificare il modello da utilizzare
specificare gli elementi da includere in esso
richiedere la visualizzazione del modello

Scriveremo il codice PHP/HTML di ciascun modello di risposta. Il codice è generalmente semplice. Quello dell’esempio sopra riportato potrebbe essere:

<?php
    // inizializzazioni per i test senza controller
...
?>
<html>
    <head>
      <title><?php echo $dReponse['titre'] ?></title>
      <link type="text/css" href="<?php echo $dReponse['style']['url'] ?>" rel="stylesheet" />    
    </head>
  <body>      
    <table>
        <tr>
            <td><?php include $dReponse['urlZone1'] ?></td>
        </tr>
        <tr>
            <td><?php include $dReponse['urlZone2'] ?></td>
            <td><?php include $dReponse['urlZone3'] ?></td>
        </tr>
    </table>
  <body>
</html>

Ogni volta che è possibile, si utilizzerà un foglio di stile per poter modificare l'aspetto della risposta senza dover modificare il codice PHP/HTML.

Si scriverà il codice PHP/HTML per ogni vista elementare. Nella maggior parte dei casi avrà la seguente forma:

<?php
     // eventualmente alcune inizializzazioni, in particolare in fase di debug
    ...
?>

<balise>
...
         // in questa fase si cercherà di ridurre al minimo il codice PHP
</balise>

Si noti che una vista elementare si integra in un modello. Il suo codice HTML viene inserito all'interno del codice del modello stesso. Nella maggior parte dei casi, quest'ultimo include già i tag <html>, <head> e <body>. È quindi piuttosto raro trovare questi tag in una vista elementare.

È possibile procedere al test dei diversi modelli di risposta e delle viste elementari

Ogni modello di risposta viene testato. Se un modello si chiama modele1.php, si richiederà tramite un browser l’URL http://localhost/chemin/modele1.php Il modello attende i valori dal controller. In questo caso lo si chiama direttamente e non tramite il controller. Il modello non riceverà i parametri previsti. Affinché i test siano comunque possibili, si inizializzeranno autonomamente, con delle costanti, i parametri previsti nella pagina PHP del modello.
Ogni modello viene testato insieme a tutte le viste elementari. È anche il momento di elaborare i primi elementi dei fogli di stile utilizzati.

Si procede quindi alla scrittura della logica applicativa dell’applicazione:

Il controller, o programma principale, gestisce in genere diverse azioni. È necessario che nelle richieste che gli pervengono sia definita l’azione da eseguire. Ciò può avvenire tramite un parametro della richiesta che qui chiameremo «azione»:
- se la richiesta proviene da un modulo (<form>), questo parametro può essere un parametro nascosto del modulo:

<form ... action="/C/main.php" method="post"  ...>
<input type="hidden" name="action" value="uneAction">
...
</form>

(continua)
- se la richiesta proviene da un link, è possibile configurarlo:

 <a href="/C/main.php?action=uneAction">lien</a>

Il controller può iniziare leggendo il valore di questo parametro e poi delegare l'elaborazione della richiesta a un modulo incaricato di gestire questo tipo di richiesta. In questo caso abbiamo ipotizzato che tutto fosse controllato da un unico script denominato main.php. Se l'applicazione deve gestire azioni action1, action2, ..., actionx, è possibile creare all’interno del controller una funzione per ciascuna azione. Se le azioni sono numerose, si rischia di ottenere un controller “dinosaurio”. È anche possibile creare script action1.php, action2.php, ...,actionx.php incaricati di gestire ciascuna delle azioni. Il controller che deve gestire l’azione actionx si limiterà a caricare il codice dello script corrispondente tramite un’istruzione del tipo include "actionx.php". Il vantaggio di questo metodo è che si lavora al di fuori del codice del controller. Ogni membro del team di sviluppo può così lavorare sullo script di elaborazione di un'azione actionx in modo relativamente indipendente. L'inclusione del codice dello script actionx.php nel codice del controller al momento dell'esecuzione presenta inoltre il vantaggio di alleggerire il codice caricato in memoria. Viene caricato solo il codice di elaborazione dell’azione in corso. Questa inclusione di codice fa sì che le variabili del controller possano entrare in conflitto con quelle dello script dell’azione. Vedremo che è possibile limitare le variabili del controller a poche variabili ben definite, che dovranno quindi essere evitate negli script.

Si cercherà sistematicamente di isolare il codice di business o il codice di accesso ai dati persistenti in moduli distinti. Il controller è una sorta di caposquadra che riceve le richieste dai propri clienti (utenti web) e le fa eseguire dalle persone più adatte (i moduli di business). Durante la scrittura del controller, si determinerà l’interfaccia dei moduli di business da realizzare. Ciò vale nel caso in cui tali moduli debbano essere sviluppati. Se invece esistono già, il controller si adatterà all’interfaccia di tali moduli esistenti.

Si scriverà lo scheletro dei moduli di business necessari al controller. Ad esempio, se quest’ultimo utilizza un modulo getCodes che restituisce un array di stringhe, in una prima fase ci si può limitare a scrivere:

function getCodes(){
    return array("code1","code2","code3");
}

A questo punto si può passare ai test del controller e degli script PHP associati:

il controller, gli script delle azioni, i modelli, le viste e le risorse necessarie all’applicazione (immagini, ecc.) vengono collocati nella cartella DC associata al contesto C dell’applicazione.
Fatto ciò, l’applicazione viene testata e vengono corretti i primi errori. Se main.php è il controller e C il contesto dell’applicazione, si richiederà l’URL http://localhost/C/main.php. Al termine di questa fase, l’architettura dell’applicazione è operativa. Questa fase di test può risultare complessa, dato che si dispone di pochi strumenti di debug se non si utilizzano ambienti di sviluppo avanzati e, in genere, a pagamento. È possibile avvalersi delle istruzioni echo "messaggio" che scrivono nel flusso HTML inviato al client e che compaiono quindi nella pagina web visualizzata dal browser.

Infine, si scrivono le classi di business necessarie al controller. In questo caso si tratta in genere dello sviluppo classico di una classe PHP, il più delle volte indipendente da qualsiasi applicazione web. Essa verrà innanzitutto testata al di fuori di tale ambiente, ad esempio con un’applicazione da console. Una volta scritta una classe di business, la si integra nell’architettura di distribuzione dell’applicazione web e se ne verifica la corretta integrazione. Si procederà in questo modo per ogni classe di business.