LA VALIDAZIONE DEI FORM
Prima di affrontare la validazione vediamo come sia possibile esternalizzare le etichette dei nostri form per favorirne l’internazionalizzazione.
ESTERNALIZZARE LE LABEL
I più attenti si saranno resi conto che nei form abbiamo utilizzato delle label cablate direttamente nel codice. Come prima cosa per esternalizzare le etichette dobbiamo apportare delle modifiche a livello di configurazione. Apriamo il file WebApplicationContextConfig.java e modifichiamolo come segue. Come vedi dalla figura in basso il Bean non fa altro che configurare la sorgente dei messaggi. La proprietà setBasename imposta un file di testo che ne sarà l’origine.
Ora dobbiamo creare un file properties avente esattamente lo stesso nome cioè messages in src/main/resources. Ti riporto un piccolo estratto. Come vedi si segue la seguente convenzione: nome del form seguito dalla parola form poi il nome del controllo e infine label.
Nel form di inserimento dobbiamo aggiungere il seguente tag spring:message. Anche i bottoni possono essere etichettati con questa tecnica.
TECNICHE DI INTERNAZIONALIZZAZIONE
Ora faremo un passo avanti e dalla semplice esternalizzazione vedremo come sia possibile creare applicazioni multilingue. In questo esempio ci limiteremo alla sola lingua inglese. Nella cartella src/main/resources creiamo un nuovo file messages_en.properties che conterrà tutte le etichette tradotte nella lingua inglese.
È molto importante che tutti gli elementi stiano su entrambi i file properties. Una volta inserite le etichette dobbiamo modificare il file di configurazione WebApplicationContextConfig.java. Come prima cosa inseriamo l’interceptor, che sono degli elementi che permettono di eseguire specifiche operazioni prima o dopo una chiamata. In particolare, aprirà una pagina dopo aver tradotto le rispettive etichette, selezionata con il click su un bottone o link. L’elemento più importante è la specifica di una stringa “language”. Vedremo che tale stringa dovrà essere uguale nella pagina JSP in particolare nei link che determinano il cambio della lingua. Dopo aver aggiunto l’interceptor dobbiamo comunicare a Spring MVC quale è la nostra lingua di default. In particolare, con quale lingua si aprirà la nostra pagina. Questo Bean si chiama LocaleResolver.
Andiamo a vedere i link nella nostra pagina JSP di inserimento. I parametri inseriti nell’interceptor devono essere coerenti con i link impostati a livello di pagina jsp. Come vedi abbiamo usato language come nell’interceptor.
Siccome img non è presente sotto la cartella static dobbiamo aggiungere un Handler nel file di configurazione come si vede nella classe WebApplicationContextConfig.java sopra riportata. Tale metodo mappa il path /img/ seguito da qualsiasi altra cosa con la cartella /static/images presente sotto la directory static. In pratica a fronte del path /static/images corrisponde il path /img/.
LA VALIDAZIONE CON LA BEAN VALIDATION
La bean validation è un sistema di validazione che si basa su specifiche notazioni che vengono prese da Hibernate. Hibernate è un ORM e lo approfondiremo successivamente. In via teorica non avendo predisposto alcun controllo, un utente potrebbe inserire qualsiasi cosa nel form. Il primo passo per aggiornare il progetto è quello di andare a modificare il nostro file POM.XML per poter lavorare con le notazioni di Hibernate.
Modifichiamo poi il file di configurazione WebApplicationContextConfig.java introducendo un nuovo Bean che attiva la Bean Validation. Come si vede abbiamo fatto il settings dell’origine dei messaggi visualizzati, e di nuovo questi messaggi e le varianti in lingua andranno inseriti nel file messages.properties e messages_en.properties. La messageSource creata in un Bean precedente altro non è che l’origine dei nostri messaggi. L’ultima modifica restituisce il validator appena creato.
Le notazioni di validazione di Hibernate andranno inserite nei campi privati della nostra classe di dominio Articoli.
Questa è la classe di dominio Articoli.
I messaggi seguono questa convenzione: Nome della notazione, la classe in cui viene applicata, il nome del campo privato e infine validation. Tali messaggi dovranno essere presenti nei due file properties con i relativi messaggi di errore. Fatto questo si modificano le pagine di inserimento e aggiornamento articoli, ti mostro un estratto della pagina. In pratica stiamo impostando la variabile error con il contenuto di uno speciale tag form:errors che prende tutti i campi. Se la variabile non è vuota viene mostrato il messaggio o i messaggi di errore.
Vediamo infine le modifiche da apportare al controller, analizziamo l’inserimento, discorso analogo vale per l’update. Con il metodo GET valorizziamo le combo della categoria e dell’iva e restituiamo un form vuoto pronto per essere compilato. Nel POST, nota che il mapping è sempre lo stesso, inseriamo la fondamentale notazione @Valid che è l’artefice vera e propria della validazione, nel caso in cui il BindingResult presenta un errore result.hasError() restituisce true (presenza di errori di validazione) allora viene di nuovo presentato il form per la correzione degli errori. Altrimenti si procede con l’inserimento.
DOWNLOAD CODICE DELL’ARTICOLO
Il progetto AlphaShopV4.zip è per il DBMS SQL Server mentre AlphaShopV5.zip è per MySQL.
Scrivi un commento