Posts tagged: spring

SWF: Model Data Validation

spring-webflowDopo aver visto come SWF realizza il mapping tra i dati di un modello e i campi di un form, vediamo ora come creare il meccanismo di validazione che consente di verificare il valore di ciascun campo inserito all’interno di un form. In questo articolo abbiamo visto come viene realizzata il binding dei dati e teniamolo come punto di partenza per iniziare a vedere il meccanismo della validazione.
Riprendiamo il codice sorgente del file di configurazione del flow e la pagina HTML all’interno della quale è presente il form:

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow
        http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
 
    <var name="flight" class="it.devme.flight.Flight" />
 
    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" />
    </view-state>
 
    <view-state id="confirm" view="flight/showFlightInfo" />
 
</flow>
<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>DevMe - SWF Flight info test - </title>
  </head>
 
<body>
  <h1>Flight information </h1>
  <p>Inserisci le informazioni sul volo:</p>
    <form:form id="flightDetails" modelAttribute="flight">
      <table>
        <tr>
          <td>Numero del volo: </td>
         <td><form:input path="number"/></td>
        </tr>
 
        <tr>
          <td>Ora di partenza: </td>
          <td><form:input path="time"/></td>
        </tr>
 
        <tr>
         <td>Gate: </td>
         <td><form:input path="gate"/></td>
        </tr>
 
        <tr>
          <td>Volo in ritardo: </td>
          <td><form:radiobutton path="isDelayed" value="false" />
  	      <form:radiobutton path="isDelayed" value="true" /></td>
        </tr>
 
        <tr>
          <td><input type="submit" name="_eventId" value="next"></td>
        </tr>
    </table>
    </form:form>
  </body>
</html>

Bene. Come già ampiamente discusso, il flow definito dal file XML di sopra è molto semplice. Abbiamo una sola transizione da uno stato all’altro, ovvero si naviga da una pagina ad un altra pagina. Supponiamo ora, di voler validare i dati del form della pagina di partenza, e spostarsi nella pagina di arrivo, solo se non esistono errori di validazione secondo il nostro personale schema di validazione. Il nostro schema, prevede per semplicità che almeno uno dei tre campi presenti nel form sia indicato, e che se indicato il numero del volo questi dovrà essere un valore numero e eventuali caratteri alfabetici verranno rigettati.

Iniziamo con la modifica del file XML di definizione del flow:

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow
        http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
 
    <var name="flight" class="it.devme.flight.Flight" />
 
    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" >
          <action method="bindAndValidate" bean="flightAction" />
      </transition>
    </view-state>
 
    <view-state id="confirm" view="flight/showFlightInfo" />
 
</flow>

Il metodo bindAndValidate in sostanza richiama la nostra classe validator, la quale effettua i controlli che andremo a definire. Da notare che il riferimento nel tag action, punta ad un metodo all’interno della nostra classe Action che in realtà non esiste, ma che viene ereditato dalla superclasse FormAction. Definendo all’interno del file XML di definizione del bean il riferimento alla nostra classe Validatore, autormaticamente verrà richiamata all’invocazione del metodo bindAndValidate. Il codice della classe che si occupa di effettuare la validazione è il seguente: 

package it.devme.flight;
 
public class FlightValidator implements Validator {
 
	public boolean supports(Class clazz) {
		return clazz.equals(Flight.class);
	}
 
	public void validate(Object target, Errors errors) {
                Flight flight = (Flight) target;
                if (flight.getNumber()==0 && flight.getTime()==null && flight.getGate.equals("")) {
                    errors.rejectValue("gate", "Attenzione, &egrave; necessario specificare almeno 1 tra: numero del volo, ora di partenza, Gate");
                }
 
                if (errors.getErrorCount()==0) {
                    ValidationUtils.rejectIfEmptyOrWhitespace(errors, "gate", "Il campo gate non pu&ograve; essere vuoto.");
                }
	}
 
}

Vediamo cosa è stato fatto. Intanto osserviamo che FlightValidator implementa la classe Validator, quindi definisce alcuni metodi essenziali che sono supports e validate. Il primo assicura il supporto al Bean indicato al suo interno. Il secondo implmenta la logica di validazione. Nel nostro caso vogliamo che almeno uno dei tre campi venga inserito, e che il campo Gate sia diverso da vuoto. Il primo controllo verifica la prima delle nostre condizioni; il secondo if, verifica prima che non ci siano stati errori in precedenza, e in caso positivo effettua il controllo di validazione sul campo Gate.

Vediamo ora come modifichiamo il file HTML per presentare il messaggio di errore:

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>DevMe - SWF Flight info test - </title>
  </head>
 
<body>
  <h1>Flight information </h1>
  <p>Inserisci le informazioni sul volo:</p>
    <form:form id="flightDetails" modelAttribute="flight">
      <table>
        <tr>
          <td>Numero del volo: </td>
         <td><form:input path="number"/></td>
        </tr>
 
        <tr>
          <td>Ora di partenza: </td>
          <td><form:input path="time"/></td>
        </tr>
 
        <tr>
         <td>Gate: </td>
         <td><form:input path="gate"/></td>
         <td><form:errors path="gate"/></td>
        </tr>
 
        <tr>
          <td>Volo in ritardo: </td>
          <td><form:radiobutton path="isDelayed" value="false" />
  	      <form:radiobutton path="isDelayed" value="true" /></td>
        </tr>
 
        <tr>
          <td><input type="submit" name="_eventId" value="next"></td>
        </tr>
    </table>
    </form:form>
  </body>
</html>

Per semplicità il nostro messaggio di errore comparirà sempre nello stesso posto, ovvero sotto il campo Gate. Così nel primo caso di errore, darà contezza del fatto che almeno uno dei campi di precedenti deve essere indicato, mentre nel secondo caso, sarà indicativo del campo stesso. Come vedete, l’aggiunta del tag <form:errors/> fa in modo di collegare eventuali codici di errori con il campo presentato in pagina.

Alla prossima. Stay tuned!

SWF: Model Data Binding

spring-webflowNell’ultimo articolo su Spring Web Flow ho condensato la maggior parte dei concetti chiave sull’argomento. Mi piacerebbe ora tornare indietro su alcune cose cercando di porre maggiore attenzione. In questo articolo vedremo un pò più da vicino come avviene il binding dei dati in SWF, da un form HTML verso un bean.
In SWF esiste un controller, dello stesso genere di quelli utilizzati in Spring MVC (es. AbstractFormController), che permette di effettuare il binding dei parametri corrispondenti ai campi di un form HTML, quindi presente nella request HTTP verso un command object rappresentato da una semplicissima classe Java Bean. Ad una certa view è associato un certo model object sul quale verranno memorizzati i valori dei parametri del form e affinché avvenga in binding è sufficiente dichiarare l’attributo model dell’elemento <view-state>. L’esempio che segue mostra come deve essere definito il tutto nel contesto SWF affinché avvenga correttamente il binding.

Si comincia col definire la classe del nostro Java Bean, suppioniamo di voler memorizzare le informazioni riguardanti i voli in partenza da un certo aeroporto.

package it.devme.flight;
 
import java.io.Serializable;
import java.sql.Time;
 
public class Flight implements Serializable {
 
        private static final long serialVersionUID = 1L;
 
        private String number;
        private Time time;
	private String gate;
	private boolean isDelayed;
 
	public String getNumber() {
		return number;
	}
	public void setNumber(String number) {
		this.number = number;
	}
	public Time getTime() {
		return time;
	}
	public void setTime(Time time) {
		this.time = time;
	}
	public String getGate() {
		return gate;
	}
	public void setGate(String gate) {
		this.gate = gate;
	}
	public boolean isDelayed() {
		return isDelayed;
	}
	public void setDelayed(boolean isDelayed) {
		this.isDelayed = isDelayed;
	}
 
}

Fin qui niente di più semplice. Procediamo ora con il nostro flow. Il flow consiste di 2 view. La prima pagina raccoglie i dati che verranno memorizzati all’interno dei 4 attributi della classe Flight. Avanzando con il bottone next, la seconda pagina semplicemente mostrerà i dati raccolti.

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow
        http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd">
 
    <var name="flight" class="it.devme.flight.Flight" />
 
    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" />
    </view-state>
 
    <view-state id="confirm" view="flight/showFlightInfo" />
 
</flow>

All’inizio del flow creiamo la variabile di flow flight la quale è un istanza della classe Flight. Fissando questa variabile come attributo model nella start view, diciamo a SWF di utilizzare questo oggetto per effettuare il binding dei dati. Implementando una semplicissima pagina HTML con un form chiudiamo il primo cerchio.

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
 
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>DevMe - SWF Flight info test - </title>
  </head>
 
<body>
  <h1>Flight information </h1>
  <p>Inserisci le informazioni sul volo:</p>
    <form:form id="flightDetails" modelAttribute="flight">
      <table>
        <tr>
          <td>Numero del volo: </td>
         <td><form:input path="number"/></td>
        </tr>
 
        <tr>
          <td>Ora di partenza: </td>
          <td><form:input path="time"/></td>
        </tr>
 
        <tr>
         <td>Gate: </td>
         <td><form:input path="gate"/></td>
        </tr>
 
        <tr>
          <td>Volo in ritardo: </td>
          <td><form:radiobutton path="isDelayed" value="false" />
  	      <form:radiobutton path="isDelayed" value="true" /></td>
        </tr>
 
        <tr>
          <td><input type="submit" name="_eventId" value="next"></td>
        </tr>
    </table>
    </form:form>
  </body>
</html>

Cliccando sul Next ci spostiamo verso la seconda view definita all’interno del flow attraverso la transition confirm. All’interno di questa transition i valori dei campi del form vengono inviati in POST e automaticamente ne viene fatto il bind verso l’oggetto flight presente nel flow scope. Successivamente, durante il caricamento della view confirm, vengono eseguite le espressioni EL rispetto al valore dei campi del bean, consentendoci quindi di visualizzarne il valore.

<%@ taglib prefix="form" uri="http://www.springframework.org/tags/form" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd">
 
<html>
  <head>
    <title>Flight Information Details</title>
  </head>
 
<body>
 
  <h1>Flight Information Details</h1>
  <p>Dettagli del volo:</p>
  <form:form modelAttribute="flight" >
 
    <table>
      <tr>
        <td>Numero volo: </td>
        <td>${flight.number}</td>
      </tr>
 
      <tr>
       <td>Orario: </td>
       <td>${flight.time}</td>
      </tr>
 
      <tr>
       <td>Gate: </td>
       <td>${flight.gate}</td>
      </tr>
 
      <tr>
       <td>Ritardo: </td>
       <td>${flight.isDelayed}</td>
      </tr>
 
   </table>
 </form:form>
</body>
</html>

Come vedete è molto semplice. Una piccola nota: se per qualunque ragione non si volesse proseguire durante una transition, al binding dei parametri della request è sufficiente aggiungere l’attributo bind all’interno del tag transition indicando come valore false.

    <view-state id="start" view="flight/insertFlightInfo" model="flight">
      <transition on="next" to="confirm" />
      <transition on="cancel" to="end" bind="false" />
    </view-state>

Nel prossimo articolo parleremo della validazione dei campi di un form. Alla prossima
Stay tuned!

Live Search con Spring e JQuery

live_searchTempo fa in questo articolo abbiamo visto come fare ad integrare il supporto Ajax all’interno del contesto di Spring utilizzando il framework DWR. In questi giorni invece ho deciso di non utilizzare DWR nell’applicazione a cui sto lavorando perché non volevo aggiungere dell’overhead. Per cui ho deciso di risolvere il problema con i soli strumenti messi a disposizione sia da Spring che da javascript.

Per prima cosa individuiamo la libreria javascript che fa per noi, provate ad indovinare cosa useremo ? JQuery esatto, il framework Javascript ormai famoso….rimando al sito per i dettagli di implementazione. Ciò detto passiamo a Spring, decidiamo subito che sarà un controller ad hoc che si occuperà della live search, eseguendo la query sulla nostra tabella e restituendo i risultati in una collection di oggetti noti.
Nel file devme-servlet.xml, file di definizione dei componenti spring della nostra applicazione, andiamo a definire il mapping con il nostro controller: 

<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
    <property name="mappings">
	<value>
	    /live.me=liveResolver
	</value>
    <property name="alwaysUseFullPath" value="true"/>
</bean>
 
<bean id="liveResolver" class="it.devme.live.LiveSearch">
	<property name="liveManager"><ref bean="liveManager"/></property>
</bean>

In questo modo ogni richiesta all’indirizzo live.me verrà gestita dal nostro controller liveResolver. Passiamo al controller:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class LiveSearch extends BaseCommandController {
 
    private LiveSearchManagerImpl liveManager;
    public void setLiveManager(LiveSearchManagerImpl liveManager) {
	this.liveManager = liveManager;
    }
 
    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {
	Object lsid = request.getParameter("lsid");
	Object q = request.getParameter("q");
	if (lsid==null || q==null) return new ModelAndView();
 
	int live = Integer.parseInt(lsid.toString());
	String key = q.toString();
	List result = null; 
	switch (live) {
	    // searchOnCity
	    case 1:
    	        result = liveManager.searchOnSchoolsData(key);
		if (result==null) return new ModelAndView();
		    break;
	   default:
		return new ModelAndView();
	}
 
	String content = "";
	for (String item : result) {
	     content += item;
	}
	return new ModelAndView(new LiveSearchView(content));
    }
}

Come si può vedere la classe in se è molto semplice.
Estende BaseCommandController per il quale è stato fatto override del metodo handleRequestInternal(HttpServletRequest request, HttpServletResponse response) così da gestire in modo personalizzato la richiesta. Osserviamo che all’interno della classe c’è l’inject della classe manager impl, ovvero il gestore del database che si preoccupa di eseguire il metodo di interrogazione e quindi di restituire i risultati impacchettando gli oggetti all’interno di una Collection.

/**
 * Effettua una ricerca sulla tabella target delle scuole.
 * 
 * @param key, chiave da ricercare
 * @return result, stringa dei risultati formattati secondo 
 */
@SuppressWarnings("unchecked")
public List<string> searchOnSchoolsData(String key) {
    try {
	String sql = 	"SELECT name, address, city " +
			"FROM \"Schools\" " +
			"WHERE name ILIKE ? OR address ILIKE ? OR city ILIKE ?" +
			"ORDER BY name, city";
 
	List<string> items = (List<string>) jdbcTemplate.query(sql,
			new Object[]{ Utility.wrapWithWildcards(key.trim()), 
                                      Utility.wrapWithWildcards(key.trim()),
                                      Utility.wrapWithWildcards(key.trim()) },
		        new RowMapper() {
			    public Object mapRow(ResultSet rs, int rowNum) throws SQLException {
		                String result = "";
				result += rs.getString("name") + "|" + 
					  rs.getString("address") + "|" +
					  rs.getString("city") + "\n";
				return result;
			    }
	});
	log.info("Search on schools with key "+key);
	return items;
    } catch (EmptyResultDataAccessException e) {
	return null;
    }  catch (DataAccessException dae) {
	dae.printStackTrace();
	log.info("Error while searching on schools.");
	return null;
    }
}

Per completezza riportiamo il metodo del managerImpl che estrae i dati dal DB. Si osservi che la collection restituita altro non è che una lista di stringhe in cui ciascun elemento è l’insieme dei dati delle scuole separati dal carattere separatore ‘|’ e terminati da uno ‘\n’.
Il metodo handleRequestInternal estrae dalla request 2 parametri che sono: lsid e q. Il primo serve ad indicare quale metodo di recupero dei dati eseguire; il secondo indica la chiave della ricerca. Nel nostro esempio c’è solo un metodo per il recupero dei dati, ma nulla vieta di aggiungerne quanti più se ne desidera.

I dati estratti vengono concatenati all’interno di una stringa passata al costruttore della view personalizzata (si veda questo post), come segue:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/**
 * @author mulp @ devme
 *
 */
public class LiveSearchView extends AbstractView {
 
    private String content;
 
    public LiveSearchView(String content) {
	this.content = content;
    }
 
    @Override
    protected void renderMergedOutputModel(Map model, HttpServletRequest request, HttpServletResponse response) throws Exception {
	byte [] bytes = content.getBytes();
        // Write content type and also length (determined via byte array).
        response.setContentType(getContentType());
        response.setContentLength(bytes.length);
 
        // Flush byte array to servlet output stream.
        ServletOutputStream out = response.getOutputStream();
        out.write(bytes);
        out.flush();		
    }
 
}

La view nel suo metodo renderMergedOutputModel realizza la scrittura di quanto estratto dal db all’interno della response, nella quale è stato precedentemente fissato il tipo e la lunghezza del contenuto. Questa azione comporta materialmente la comparsa nella pagina web del contenuto estratto, più precisamente viene intercetatto dal metodo javascript che formatta opportunamente il risultato. Di seguito vediamo i javascript che servono per realizzare la live search e lo scorcio di pagina che contiene il campo di testo sul quale avviene la live search.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js"></script>
<link href="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/themes/base/jquery-ui.css" rel="stylesheet" type="text/css"/>
<script src="http://ajax.googleapis.com/ajax/libs/jqueryui/1.8/jquery-ui.min.js"></script>
<script type="text/javascript" src="/script/jquery/jquery.autocomplete.js"></script>
 
<script type="text/javascript">
$(document).ready(function() {
	function formatItem(row) {
		return row[0] + "," + row[2] + "," + row[1];
	}
	function formatResult(row) {
		return row[0] + "," + row[1] + "," + row[1];
	}
 
	$("#ls_school").autocomplete('/live.me?lsid=1', {
		width: 400,
		matchContains: true,
		formatItem: formatItem,
		formatResult: formatResult,
		max: 100
	});
});
 
.....
.....
<input type="text" name="ls_school" id="ls_school" />
.....
....

Il codice Javascript di sopra è il binding con il componente JQuery dell’autocomplete (compreso il css) il quale trasforma la digitazione dei caratteri all’interno del campo di testo in una chiamata HTTP all’indirizzo http://www.devme.it/live.me?lsid=1&q=devme. Lato back-end risponde il nostro controller il quale effettua la ricerca e restituisce il risultato come descritto sopra. Infine il risultato verrà formattato a modi tendina da JQuery.
Come si vede è molto semplice gestire la live search o, in generali, componenti che richiedono interazione Ajax con questa tecnica. Spero di riuscire a mostrare altri esempi diversi, più avanti in altri articoli.
Stay tuned !

Spring Web Flow tutto d’un fiato ! [Part 2/2]

spring-webflowRieccoci qui per continuare il discorso iniziato nel post precedente su SFW, il framework per la creazione di applicazioni web. Dopo aver definito gli elementi facenti parte della definizione di un flusso (flow) vediamo come è possibile definirlo, attraverso la sua specifica XML. Come detto in precedenza, il flow ha inizio grazie al flow executor un componente interno di SWF. L’executor da inizio al flow a partire dallo stato configurato come attributo nel tag root della definizione del flow:

<flow xmlns="http://www.springframework.org/schema/webflow"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/webflow
      http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd"
      start-start="loginState">
	<-- Add your definition here -->
</flow>

loginState rappresenta lo stato iniziale da cui avrà inizio l’esecuzione del flow. Come già detto gli stati sono gli elementi di base della definizione di un flow, in cui è possibile transire da uno stato ad un’altro effettuando delle operazioni, dei controlli o visualizzare dell’output. Tra i possibili stati che possono essere utilizzati vi è il View State, il quale viene utilizzato per visualizzare o chiedere informazioni agli utenti. Una view può essere una qualunque pagina JSP, ma può anche essere una qualunque view supportata da Spring MVC. Di seguito viene riassunto l’elenco di possibili elementi figli del view state:

  • <attribute>, dichiara un attributo che descrive lo stato.
  • <binder>, usato per configurare un custom form binding.
  • <exception-handler>, riferisce un bean che implementa un FlowExecutionExceptionHandler che gestisce tutte le eccezioni sollevate nello stato corrente.
  • <on-entry>, indica quali azioni devono essere eseguiti quando si entra in questo stato.
  • <on-exit>,  indica quali azioni devono essere eseguiti quando si esce da questo stato.
  • <on-render>. indica quali azioni devono essere eseguiti quando si visualizza questo stato.
  • <secured>, viene utilizzato assieme a Spring Security per restringere l’accesso a questo stato.
  • <transition>, definisce un percorso da questo stato ad un’altro basato sul verificarsi di un evento o un’eccezione.
  • <var>, dichiara una variabile.

Ciò detto, il modo più semplice per dichiarare un View State è il seguente:

<view-state id="login"/>

Il tag di sopra definisce una view logica, ovvero non associata a nessuna pagina fisica, da cui non sarà possibile transire in nessun’altro stato. Per associare la view, il nome logico definito dall’attributo id ad una pagina jsp è necessario aggiungere l’attributo view,

<view-state id="login" view="loginForm"/>

in questo modo la view è associata alla pagina loginForm.jsp, la quale verrà visualizzata al caricamento della view. Nota: sarà possibile evitare di dover specificare l’estensione dei file associati alle view, configurando opportunamente Spring MVC View Resolver.

Ma vediamo un’esempio un pò più completo:

<view-state id="login" view="loginForm">
  <transition on="accountEntered" to="homeUser" />
  <transition to="endState" on="cancel" />
</view-state>

l’esempio di sopra definisce due elementi figli del tag view, elementi transition. Il primo dei due indica una transizione dallo stato corrente allo stato homeUser, al verificarsi incondizionato dell’evento accountEntered. Il secondo definisce una transizione dallo stato corrente allo stato endState al verificarsi dell’evento cancel. Come definiamo questo tipo di eventi ? Molto semplicemente….lo scatenarsi degli eventi avviene direttamente dalle view fisiche associate. Consideriamo la view loginForm.jsp associata alla view logica login come segue:

<form:form>
   <!-- HTML form definition here -->
   <input type="hidden" name="_flowExecutionKey" value="${flowExecutionKey}"/>
   <input type="submit" name="_eventId_accountEntered" value="Entra" />
   <input type="submit" name="_eventId_cancel" value="Annulla" />
</form:form>

la pagina web contiene tra gli altri elementi che ospiteranno i dati di accesso dell’utente, il pulsante di submit della pagina e un campo hidden. Quest’ultimo è richiesto per riconoscere l’id del flow in cui ci si trova ed è sempre necessario. I pulsanti di submit, oltre al loro classico funzionamento servono anche a scatenare gli eventi che abbiamo definito nel file di flow. Si noti il nome del pulsante submit Entra che invia i dati del form al server e serve per effettuare l’autenticazione dell’utente. In particolare il nome del pulsante ha un prefisso _eventId_ il quale indica a SWF che alla pressione del bottone dovrà scatenare un evento il cui nome è ciò che segue il prefisso, nel nostro caso accountEntered. In questo modo è possibile catturare l’evento nel file di definizione del flow. Stesso discorso vale per il bottone cancel.
E’ possibile anche scatenare un’evento attraverso un link, ad esempio:

<a href="${flowExecutionUrl}&_eventId=accountEntered">Entra</a>

Altro modo consiste nel creare un acampo hidden all’interno del form con name _eventId.

Dopo aver analizzato il ViewState che permette all’utente di essere coinvolto all’interno del flow, passiamo a vedere l’ActionState il quale definisce alcuni elementi che permettono di effettuare delle elaborazioni all’interno del flow. L’elenco dei nodi figli dell’action state è il seguente:

  • <attribute>, dichiara un attributo che descrive lo stato
  • <evaluate>, valuta un’espressione assegnando opzionalmente il risultato.
  • <exception-handler>, referenzia un bean che implementa FlowExecutionExceptionHandler il quale gestisce le eventuali eccezioni per lo stato corrente.
  • <on-entry>, definisce un’azione la quale viene eseguita all’ingresso dello stato.
  • <on-exit>, definisce un’azione la quale viene eseguita all’uscita dello stato.
  • <render>, richiede che la prossima view renderizzi un frammento di contenuto.
  • <secured>, restringe l’accesso allo stato corrente richiedendo l’inserimento degli attributi utente.
  • <set>, imposta una variabile all’interno dello scope del flow.
  • <transition>, definisce una transizione verso uno stato al verificarsi di un evento. Lo stato di destinazione può coincidere con lo stato corrente.

Quindi vediamo un’esempio d’uso dell’ActionState:

<action-state id="homePage">
	<evaluate expression="devME.authenticateUser(username, password)" />
	<transition to="home" on="userOK" />
	<transition to="loginForm" on="userKO" />
</action-state>

Il codice di sopra definisce il seguente comportamento. Dopo che l’utente ha inserito i propri dati di accesso all’interno del form e clicca sul pulsante Entra viene scatenato l’evento accountEntered, il quale prevede una transizione nello stato homeUser, un’ActionState. All’interno viene valutata un’espressione la quale esegue un metodo di autenticazione dell’utente sulla base dei dati forniti. Lo stesso metodo scatena 2 eventi diversi: userOK se l’utente è stato autenticato, dal quale si transisce verso la home dell’utente. L’evento userKO se l’utente non è stato autenticato e quindi si ritorna alla view di login. Come vedete è molto semplice e intuitivo.
Stay tuned.

Crittare l’url di un immagine in jsp con Spring

DataObfuscationIn questo articolo voglio far vedere come nascondere l’href di un immagine in una pagine JSP, pur visualizzando l’immagine come elemento HTML in modo standard.
Supponiamo di dover sviluppare un’applicazione web in cui ciascun utente mantiene una libreria multimediale, costituita per semplicità da soli elementi immagine. Ogni immagine viene memorizzata all’interno di un database assieme alla relative informazioni dell’utente a cui appartiene.
Affinché l’immagine non sia accessibile semplicemente attraverso l’indirizzo indicato nell’HREF, è necessario offuscare il suo contenuto attraverso una codifica il cui funzionamento è noto al sistema. Lo stesso sistema sarà in grado così di decodificare l’HREF in modo da poter restituire la risorsa e quindi visulalizzarla all’interno della pagina.
Vediamo il seguente esempio:

1
2
3
4
5
   <!-- Immagine in chiaro -->
   <img src="http://host/images/img.jpg" title="Immgine in chiaro" alt="" />
 
   <!-- Immagine offuscata -->
   <img src="http://host/image.htm?a=QVMyJCU0c2Rm%3D&b=QVMyJCU0c2RmMzI0M3NkdzI%3D" title="Immgine in chiaro" alt="" />

Nell’esempio di sopra viene mostrata un’immagine in cui l’href è crittata secondo un algoritmo che ora vedremo. E’ chiaro che nel secondo caso, affinché l’immagine possa essere visualizzata è necessaria la presenza di un elemento capace di interpretarne il contenuto, ottenere e restituire la risorsa.
Nell’ambito di Spring tutto questo può essere tradotto nel modo seguente: è necessario un Controller che venga richiamato ogni volta in cui nella pagina è presente un’immagine.
Il Controller dovrà prelevare il contenuto dell’HREF decodificarlo e restituire l’immagine, se corretto. Procediamo quindi per step.
Primo Step configuriamo il Controller (Servlet) all’interno di Spring…quindi editiamo il file di configurazione di spring ed aggiungiamo le seguenti righe di codice:

1
2
3
4
5
6
7
8
    <bean class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping" id="urlMapping"> 
        <property name="mappings">
	<value>/image.htm=mediaResolver</value>
        <property value="true" name="alwaysUseFullPath"></property>
    </bean> 
    <bean class="it.devme.obfuscator.media.MediaResolver" id="mediaResolver">
        <property name="dbManager"><ref bean="dbManager"></ref></property>     
    </bean>

L’invocazione della risorsa virtuale index.htm provoca l’invocazione del Controller MediaResolver. Vediamo la sua struttura di seguito:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class MediaResolver extends BaseCommandController {
 
    private DBManager dbManager;
    public void setDbManager (DBManager dbManager) {
	this.dbManager = dbManager;
    }
 
    @Override
    protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
	Object mediaid = req.getParameter("a");
	Object uid = req.getParameter("b");
 
	if (mediaid==null || uid==null) 
	    return new ModelAndView(new MediaView("image/jpeg", "no-image.jpg", rs.getString("basePath"), MediaView.USE_DEFAULT_IMAGE));
 
	Encrypter dec = Encrypter.getInstance();
	int idaccount = Integer.parseInt(URLDecoder.decode(dec.decrypt(uid.toString()), "UTF-8"));
	int idelement = Integer.parseInt(URLDecoder.decode(dec.decrypt(mediaid.toString()), "UTF-8"));
 
	MediaBean media = null;
	File f = null;
	String mediaPath = null;
 
	/* Check if media item exists */
	media = dbManager.getImage(idelement, idaccount);
	if (media==null) return new ModelAndView();
	mediaPath = media.getPath();
	f = new File(UPLOAD_PATH + File.separator + mediaPath);
 
	MimetypesFileTypeMap mime = new MimetypesFileTypeMap();
 
	resp.setHeader("Cache-Control", "private,no-cache,no-store");
	resp.setContentType(mime.getContentType(f));
	return new ModelAndView(new MediaView(mime.getContentType(f), mediaPath, rs.getString("basePath"), !MediaView.USE_DEFAULT_IMAGE));
    }
 
}

La classe di sopra estende BaseCommandController e quando invocata viene richiamato l’unico metodo di cui è stato fatto l’override che si occupa di decodificare e restituire la risorsa. Vediamo come.
Sostanzialmente recupera i parametri dalla GET (nel nostro caso sono a e b). Li decodifica utilizzando un algoritmo di crittografia a noi noto (si può usare qualunque algoritmo a nostro piacimento basato su una chiave provata) e quindi ottiene per il parametro a, l’id dell’utente a cui appartiene la risorsa e per il parametro b, l’id della risorsa a cui si vuole accedere. Questi dati vengono passati in input ad un metodo che effettua una query su db (getImage(idelement, idaccount)) e verifica se effettivamente la risorsa richiesta appartiene all’utente corrente.
In caso contrario viene restituita una View vuota, altrimenti si determina il mime-type della risorsa e si restituisce una view creata a partire dalla classe MediaView.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
public class MediaView extends AbstractView {
 
    private String media;
    private String basePath;
    private boolean noImage;
 
    public MediaView(String mime, String media, String basePath, boolean noImage) {
	this.media = media; 
	setContentType(mime);
	this.basePath = basePath;
    }
 
    @Override
    protected void renderMergedOutputModel(Map model, HttpServletRequest request, HttpServletResponse response) throws Exception {
	String rpath = 	null;
 
	rpath = this.basePath + request.getContextPath().substring(1) +
		MediaResolver.UPLOAD_PATH + File.separator + this.media;
 
 
	File f = new File(rpath);
	byte[] bytes = FileUtils.readFileToByteArray(f);
 
 
        // Write content type and also length (determined via byte array).
        response.setContentType(getContentType());
        response.setContentLength(bytes.length);
 
        // Flush byte array to servlet output stream.
        ServletOutputStream out = response.getOutputStream();
        out.write(bytes);
        out.flush();
    }
 
}

La classe MediaView non fa altro che leggere fisicamente i byte dell’immagine e restituirla nella response utilizzando un OutputStream. Il risultato è che l’immagine scritta nella response verrà visualizzata in pagina come un elemento HTML standard, mantenendo perà l’HREF dell’immagine crittato.
Alla prossima.

 

You need to log in to vote

The blog owner requires users to be logged in to be able to vote for this post.

Alternatively, if you do not have an account yet you can create one here.

Powered by Vote It Up

WordPress Themes