Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti

Nel numero:

99 settembre
, anno 2005

Spring Web Flow in un esempio pratico

Il Jug Avis Web (aka MagicBox)

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.

MokaByte

Spring Web Flow in un esempio pratico

Il Jug Avis Web (aka MagicBox)

Picture of Giovanni Puliti

Giovanni Puliti

  • Questo articolo parla di: Frameworks & Tools, Programmazione & Linguaggi

Spring Web Flow :Web Page Flow con Spring e l‘ Inversion of Control.

Introduzione

In alcune situazioni, nella realizzazione di Web application, si presenta la necessità  di suddividere una elaborazione in un flusso di elaborazione logica composto da più step, normalmente chiamato Page Flow.
Un esempio, può essere il caso in cui si debba effettuare una registrazione, laddove un utente debba fornire molti dati via web, in questo caso, si possono suddividere i dati per raggruppamenti logici e richiederli in pagine diverse.
Un altro esempio può essere una applicazione avente come dominio applicativo l‘elaborazione dei work flow.

Soluzioni

Un framework come Struts permette una elaborazione stile wizard, ma al prezzo di legare nel codice e nello struts-config i passi del flusso, rendendo non riutilizzabili i singoli passi di cui è composto il flusso e non isolando chiaramente i flussi stessi.
Spring fornisce appositamente per questo tipo di problematica un modulo chiamato Spring Web Flow (che farà  parte della distribuzione dalla versione 1.3).
Esso permette una configurazione da file (anche da codice se si preferisce) dei passi di cui è composto ogni singolo flusso.
Questo approccio “Spring-Ioc Style” risulta molto più maneggevole, flessibile, chiaro, testabile, riutilizzabile ed elegante.
Vedremo come si utilizza Spring Web Flow, prendendo come esempio una applicazione usa la versione PR3.
L‘applicazione è una Web App realizzata per l‘AVIS (Associazione Donatori Sangue) dal Jug Sardegna, sotto licenza Apache.

Schema flusso logico

Il primo passo da compiere quando si usa Spring Web Flow, è disegnare lo schema del funzionamento desiderato, sotto forma di transizioni tra i vari stati di funzionamento desiderati.

Si passa da uno ad un altro in base alla mappatura nel file di descrizione del flusso.
Lo StartState è il punto di partenza, il flusso si pone in un ViewState, dove viene semplicemente visualizzata una pagina, e viene atteso il submit da parte dell‘ utente .
La view di questa pagina, è una JSP che seleziona un file di cui fare l‘ upload.
Lo stato successivo è bindAndValidate (ActionState), dove viene fatto il bind del file di cui si è fatto l‘upload, nel caso ci sia un errore, l‘ utente viene riportato allo stato iniziale per ritentare l‘upload in maniera corretta.
Un ActionState è quindi uno stato in cui vengono fatte delle elaborazioni.
Se invece non ci sono stati errori il flusso si porta allo stato insert.donors dove viene valorizzata una List con gli oggetti di dominio Donor.
Se qualcosa è andato male (il file è vuoto) si viene riportati allo stato iniziale in cui viene richiesto il file.
Proseguendo, in caso nella insert.donors sia andato tutto bene, si arriva allo stato confirmation.viewTest, dove vengono mostrati i dati estratti dal file, e dove viene richiesto il messaggio da spedire via sms alle persone elencate, quando si procede con la spedizione dell‘ sms, il flusso passa allo stato sendSms (ActionState) dove viene effettuata la spedizione dell‘ sms.
Il flusso passa allo statao exit (viewState) dove viene mostrato un messaggio che comunica la buona riuscita o il fallimento della spedizione dell‘ sms.

Funzionamento e altre caratteristiche

Oltre agli stati ViewState e ActionState illustrati in precedenza, Web Flow fornisce anche uno stato “decisionale” , da utilizzare ad esempio, nel caso si debba incanalare un flusso in un eventuale sotto flusso, oppure nel caso si debba prendere una decisione rispetto al contesto nel quale si può trovare il flusso.

Es. mappatura decision-state:

Es. mappatura Sotto Flusso:

Possono essere definiti anche uno o più stati finali End-State con il quale il flusso viene terminato

Nel caso dell‘ esempio ciò non è stato fatto perché l‘ utente deve avere la possibilità  di mandare più sms di seguito.
Invece nel caso di una registrazione uno stato finale avrebbe senso.

File di configurazione sms-flow.xml

In questo file viene definita la composizione del flusso attraverso gli stati, identificando il flusso stesso con l‘ id upload.
Come si vede, tutti i componenti del flusso sono dei POJO, che sono definiti in un altro file di configurazione, compreso il componente principale che agisce da factory per i flussi, vediamo questo file.

jug-servlet.xml

Questo file contiene i bean del Web Tier

/WEB-INF/sms-flow.xml/WEB-INF/jsp/.jsp......

Il primo bean che vediamo è flowFrontController, il controller (il corrispondente delle action in Struts) che mappa l‘ URL /upload.htm (.htm negli url usati da Spring è una convenzione come il .do in Struts), e al quale viene iniettato il bean smsFlow che è una XmlFlowFactoryBean che provvede a creare il flusso dal file dei bean.
Nella parte delle action troviamo i bean che vengono usati nel flusso, poi troviamo il bean usato nell‘ upload del file, e per ultimo il bean viewResolver che si occupa di far corrispondere i nomi logici delle view(in questo esempio quelle dei viewState)a delle JSP.

Dettagli di funzionamento

Vediamo alcuni dettagli che permettono al flusso di funzionare.
Vediamo la JSP iniziale (selectFile.view) per spiegare gli elementi fondamentali.

<%@ page session="false" %><%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
(Passo 1 di 3) Scegli il file contenente i numeri di telefono delle persone a cui inviare l‘sms

">

Per prima cosa, diciamo che l‘url che viene utilizzato in tutto il flusso è upload.htm, ed è sempre lo stesso, quindi in tutte le JSP lo ritoveremo come url del form action.
Di seguito troviamo ciò che permette al flusso di sapere in quale punto si trova.

_flowExecutionId, è l‘ id che permette all‘ oggetto che contiene il page flow (nella sessione tipicamente) di identificare il flusso tra le varie richieste al server, esso deve essere presente in tutte le pagine tranne quella iniziale e quella finale ed è associato allo stesso flusso su uno stesso client.
La sua funzione si comprende soprattutto alla luce del fatto che il flusso nei ViewState è “in pausa”.

_eventId, invece serve per sapere quale transizione deve essere effettuata, nel nostro caso sul submit.

_currentState, serve per sapere in quale stato ci si trova nel caso che l‘ utente invece di usare i link o i pulsanti per la navigazione, utilizzi il back del browser.
Le action estendono tutte MultiAction di Web Flow.

A tutte le action viene fornito un RequestContext(Non corrispondente alla HttpRequest), i dati possono essere letti e messi con visibilità  a livello di request o di flow.
Altra carattersitiche non illustrata nell‘ articolo è il binding e il supporto per le portlet.

Testabilità , Code Coverage e metriche:

Come detto all‘ inizio dell‘ articolo, la costruzione di un flusso in maniera Ioc Style porta il beneficio di rendere fortemente disaccopiati tutti gli oggetti, rendendo facile la testabilità , il Code Coverage e la “misurazione” della qualità  del codice che viene prodotto, fornendo degli indicatori su dove eventualmente migliorare il codice.
Se sui test non ci dovrebbe ormai essere bisogno di spiegarne i benefici, vediamo in cosa ci aiuta invece il Code Coverage.
Per il Jug Avis viene usato Clover , che segnala nell‘ ambiente di sviluppo ( anche con Ant volendo, e genera dei report per la documentazione sui punti in cui il codice non viene eseguito), segnalando codice non usato, o non adeguatamente coperto da test.


Metrics invece come dice il nome stesso, misura il codice scritto , fornendo dati che possono rivelare molte cose sul “come” si stà  scrivendo il codice e fornisce anche dei grafi interattivi sulle dipendenze fra le classi.


Conclusioni

Nell‘ articolo è stata mostrata solo la superficie di questo modulo di Spring che è arrivato alla versione PR5 e ritoveremo nelle prossime versioni di Spring, magari con qualche modifica.
Infatti oltre a supportare il Page flow, è il modulo deputato alla integrazione con le Portlet (con specifica JSR 168).

Riferimenti bibliografici

Rod Johnson, Juergen Hoeller, “J2EE Development without EJB”, Wrox

Craig Walls and Ryan Breidenbach, “Spring in Action”, Manning

Rod Johnson, Juergen Hoeller, Alef Arendsen, Thomas Risberg, Colin Sampaleanu, “Professional Java Development with the Spring Framework”, Wrox

Rob Harrop, Jan Machacek, “Pro Spring”, Apress

[1]
Spring Web Flow
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home

[2]
Forum Spring Framework
http://forum.springframework.org/

[3]
Presentazione Jug Avis Web
http://www.jugsardegna.org/vqwiki/jsp/Wiki?action=action_view_attachment&attachment=Spring_webflowJug16Luglio2005.pdf

[4]
Jug Avis
http://www.jugsardegna.org/vqwiki/jsp/Wiki?JugAvis

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.

Facebook
Twitter
LinkedIn
Picture of Giovanni Puliti

Giovanni Puliti

Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.
Tutti gli articoli
Nello stesso numero
Loading...

Soluzioni Oracle per la scalabilità

Come rendere scalabili le applicazioni Oracle

Il nome della cosa

Sun rivede e uniforma i nomi delle proprie piattaforme

Il networking in Java

II parte: il TCP e i socket

Validare il codice Java

Preveniamo lo spaghetti code

Multimedialità su J2ME

IV parte: riproduzione, registrazione e transcodifica video

Autenticazione password crittografata

Una semplice applicazione Struts

Integrazione di applicazioni Enterprise

Parte VIII: l‘Enterprise Integration Component Server di Librados

MokaCMS – Open Source per il Web Content Management

VII parte: Da XML ad PDF utilizzando XSLT e FO (seconda puntata)

Pratiche di sviluppo del software

VI - Code Coverage

Nella stessa serie
Loading...

Il dilemma del prigioniero

Un “gioco serio” per comprendere la cooperazione

Accessibilità in team di prodotto: sfide, normative e best practice

II parte: Analisi di un caso reale

Adattare l’agilità ai contesti: una chiave di lettura

I parte: Un caso di studio con le sue peculiarità

Talento, performance, carriera: uno sguardo d’insieme

I parte: Che cosa è il talento?

Accessibilità in team di prodotto: sfide, normative e best practice

I parte: Cosa è l’accessibilità e perché implementarla

Il web al tempo della GEO (Generative Engine Optimization)

II parte: Strategie per strutturare i contenuti

Un backlog non tanto buono

II parte: Caratteristiche e ruolo del backlog.

FIWARE: Open APIs for Open Minds

V parte: Implementazione del sistema di ricarica

Il web al tempo della GEO (Generative Engine Optimization)

I parte: Struttura e ricerca delle informazioni

Un backlog non tanto buono

I parte: Un progetto con qualche difficoltà

DDD, microservizi e architetture evolutive: uno sguardo d’insieme

X parte: Il ruolo del Software Architect

FIWARE: Open APIs for Open Minds

IV parte: Sistema di ricarica intelligente per veicoli elettrici

Tra Play14 e serious gaming

Un ponte tra gioco e apprendimento

DDD, microservizi e architetture evolutive: uno sguardo d’insieme

IX parte: Event Sourcing is not Event Streaming

FIWARE: Open APIs for Open Minds

III parte: Tecnologie e implementazione

Agilità organizzativa

II parte: Qualche caso d’esempio

Agilità organizzativa

I parte: Individui e interazioni nelle aziende moderne

FIWARE: Open APIs for Open Minds

II parte: Generic Enablers per costruire ecosistemi smart

Intelligenza artificiale e industria

Riflessioni sull’uomo e sulla macchina

Effetto Forrester e dinamiche dei sistemi di produzione

La storiella di una birra per comprendere il Lean

DDD, microservizi e architetture evolutive: uno sguardo d’insieme

VIII parte: La filosofia dell’architettura del software

Digital revolution: trasformare le aziende in ecosistemi digitali

XVIII parte: Una piattaforma comune a tutti gli eventi

Scene dalla “neolingua”

Panoramica semiseria dell’incomunicabilità aziendale

Autenticazione schede elettorali… lean!

Simulazione lean nella gestione di un seggio

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte