Impariamo ad usare The Play Framework - II parte

Submitted by dimitri on Mar, 02/03/2010 - 16:17

Nella scorsa puntata abbiamo impostato la struttura del progetto GymTrack usando Play Framework, e abbiamo cominciato a prendere confidenza con il comando play; questa volta invece vedremo in concreto come funzionano i controller e le view, creando un primo prototipo della nostra applicazione.

Model-View-Controller

Ormai praticamente tutti i framework per lo sviluppo di web application (e non solo) utilizzano l'ormai arcinoto design pattern denominato Model-View-Controller (MVC),e per delle buone ragioni! Questo pattern consente di suddividere l'applicazione in livelli logici che ne facilitano lo sviluppo, la manutenzione (leggi: bugfix!) e l'estensione. A dire il vero non c'è una vera e propria "specifica" e ogni implementazione decide autonomamente dov'è il confine fra i vari attori di questo pattern, ma questa ampia libertà di scelta ha fatto sì che venissero creati diversi framework adatti ai diversi "gusti" ed esigenze. Play in particolare è uno di quelli più "minimalisti" e le sue scelte sono orientate principalmente alla semplicità e rapidità di sviluppo:

  • Model:
    • sono classi Java che mappano direttamente le tabelle del database;
    • contengono i metodi di interrogazione e aggiornamento del database;
    • sfruttano Java Persistence API (JPA) tramite Hibernate;
  • Controller:
    • rispondono alle richieste HTTP;
    • implementano la logica applicativa (ad esempio manipolando i dati del Model) ma sono comunque liberi di delegare ad altri componenti;
    • instradano il flusso di esecuzione verso le View più appropriata;
  • View:
    • sono i template HTML da mostrare all'utente;
    • non contengono logica applicativa, ma solo di presentazione (loop, condizioni, formattazione, internazionalizzazione).

I Controller

I controller in Play vanno creati nella directory app/controllers, estendendo la classe play.mvc.Controller. Il comando play new, eseguito nello scorso articolo, ha creato un controller standard in app/controllers/Application.java:

package controllers;

import play.mvc.*;

public class Application extends Controller {
    public static void index() {
        render();
    }
}

Il metodo index() è l'azione di default che viene invocata sul controller, ed ha la particolarità di essere dichiarato con i modificatori public static; di fatto i controller di Play sono "stateless", questo per impedire un errore che veniva commesso spesso con i primi framework MVC come Struts o Spring MVC: l'utilizzo di variabili di istanza per gestire i flussi di esecuzione dei controller, un vero disastro in situazioni di multi-utente (leggi: dati di utenti diversi... mescolati!).

Questo controller non esegue alcuna azione ma si limita semplicemente a invocare il metodo render(), comando che ordina a Play di mostrare la View associata all'azione corrente.

Le view

Le view si trovano in app/views:

  • la posizione di default segue questa convenzione:

    app/views/[nome controller]/[nome metodo]

  • in alternativa, è sempre possibile specificare un percorso differente.

Nel caso dell'azione di default vista sopra, cioè Application.index(), la view selezionata sarà:

app/views/Application/index

La pagina esiste già, ed ha questo sorgente:

#{extends 'main.html' /}
#{set title:'Home' /}

#{welcome /}

I template sono basati su Groovy, ma non è necessario conoscere questo linguaggio per utilizzarli, e la sintassi è piuttosto semplice e sintetica. Il tag #{welcome /} non fa altro che riempire la pagina di default con le istruzioni per configurare un IDE e un database.

Il tag #{extends} significa che il template estende un altro template, contenuto nel file app/views/main.html. Se apriamo quest'ultimo file possiamo notare che definisce una pagina HTML minimale, dove nel <body> c'è solo il comando #{doLayout /}; questo comando appunto serve per dire a Play di prendere i contenuti della nostra view e inserirli in quel punto preciso del template. Questo modo di procedere consente di "riciclare" molto del codice ripetitivo e concentrarsi solo sul contenuto vero e proprio delle View, molto comodo!

Proviamo ora a modificare ora la nostra view, quella cioè in app/views/Application/index.html , sostituendo al tag #{welcome /} il più classico dei messaggi di benvenuto:

#{extends 'main.html' /}
#{set title:'Home' /}

Ciao Mondo!

Ricaricando la pagina sul browser (solitamente tasto F5) vedremo il nuovo messaggio al posto della "welcome page" solita.

Passaggio di variabili alle view

Il metodo render() utilizza una caratteristica di Java 5 denominata "Variable Argument List" o più semplicemente "Varargs": è possibile cioè invocare il metodo con una lista arbitraria di argomenti, che verranno quindi messi a disposizione della view.

Ad esempio, modificando il metodo Application.index() in questo modo:

public static void index() {
    java.util.Date now = new java.util.Date();
    render(now);
}

e aggiungendo questa linea in view app/views/Application/index.html:

<br /> Data: ${now.toGMTString()}

La similitudine con Expression Language (EL) di JSP e JSF nel template è evidente, con l'importante differenza che quiè possibile invocare direttamente metodi Java, senza le rigide limitazioni di EL.

Il nuovo aspetto della pagina sarà simile a questo:

Come potete notare il nome della variabile rimane immutato sia nel controller che nella view, facilitando la comprensione del codice. È comunque possibile dare esplicitamente un nome alle variabili utilizzando l'oggetto renderArgs messo a disposizione dei controller:

public static void index() {
    java.util.Date now = new java.util.Date();
    renderArgs.put("now", now);
    render(now);
}

Sviluppi

Prima di procedere con lo sviluppo del nostro progetto vi consigliamo di fare un po' di pratica con i controller e le view, tenendo sotto mano la documentazione ufficiale sul sito ufficiale di Play.

Potresti essere interessato anche a...