JUG – Ancona Italy
Spring MVC Andrea Del Bene Jug Marche
Cos'è Spring MVC? Spring MVC è il sotto-framework di Spring che permetti di servirsi del Framework Spring per realizzare applicazioni web.
Possiamo quindi avvantaggiarci delle peculiarità di Spring (IoC, DI, ecc...) anche nello sviluppo di web application.
Ovviamente usa il pattern MVC :-) ...
Una panoramica del pattern MVC in Spring MVC Model: qui spring non fa nulla e segue la sua filosofia di base. Il modello è rappresentato dai POJO, classi Java "nude e crude" (JavaBean).
Controler: il grosso di Spring MVC consiste nel fornire classi di supporto per la parte controller, ossia per ricevere e processare request http provenienti da un client. Il controller deve anche reindirizzare il client sulla vista giusta.
View: la parte controller crea viste da mostrare al client, ma la generazione della vista vera e propria è demandata al framework di visualizzazione che si è scelto di usare. Spring supporta diversi framework di "vista" per il web: Jsp, Velocity, JSF, ecc...
Tecnologie di visualizzazione Spring quindi NON fornisce una tecnologia di vista propria ma invita a scegliere quella che si preferisce. Anche qui Spring segue la sua filosofia di base di non invasività.
il framework usato (Jsp, Velocity, JSF, ecc...) non è consapevole in alcun modo di essere usato da Spring (nessuno dipendenza).
Il file web.xml
Il punto di partenza: il file web.xml Come per ogni applicazione web Java il file web.xml (nella cartella WEB-INF) contiene tutte le informazioni che il web container (Tomcat nel nostro caso) andrà ad utilizzare per caricare e rendere operativa la nostra applicazione.
Jug4Tenda org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:springConfigFiles/jug4tendaContext.xml 1 .... index.jsp
Il file web.xml di Jug4Tenda
Nel nostro caso la porzione più significativa del file è la seguente:
Jug4Tenda org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:springConfigFiles/jug4tendaContext.xml 1 Jug4Tenda *.html Jug4Tenda *.do
index.jsp
Il file web.xml di Jug4Tenda 2
Jug4Tenda org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:springConfigFiles/jug4tendaContext.xml 1
Nel tag specifichiamo il nome della nostra servlet (Jug4Tenda) che viene lanciata e associata alla nostra applicazione al momento dell'avvio del web container. La servlet è del tipo org.springframework.web.servlet.DispatcherServlet. Si può notare tra il tag il nome e la posizione del file di configurazione di Spring che la nostra servlet si aspetta di caricare al suo avvio. La servlet è un vero e proprio ponte tra la nostra applicazione Spring e il mondo web.
Il file web.xml di Jug4Tenda 3 ... ...
Jug4Tenda *.html Jug4Tenda *.do
Continuando l'analisi del file web.xml troviamo il tag dove indichiamo quali URL verranno indirizzati alla nostra servlet Jug4Tenda: tutti gli URL terminanti con html verranno gestiti dalla servlet Jug4Tenda. Analogamente anche gli url terminanti con .do verranno getiti da Jug4Tenda NOTA: per evitare confusione è ben dire che un url terminante con
html NON deve per forza riferirsi ad un corrispondente file html esistente!
I controller
Spring MVC: il “cammino” delle request Abbiamo visto come ora tutte le request indirizzate alla nostra applicazione transitano per la servlet Jug4Tenda che le reindirizerà alle varie componenti della nostra web application. Vedremo ovviamente cosa sono queste componenti che gestiscono le request e vengono configurate nel file di contesto di Spring.
E' il momento di mostrare il cammino classico di una request all'interno dell'architettura di un'applicazione Spring MVC.
Primi passi standard della request 2.
Come abbiamo dettogli URL terminanti con .html passano alla nostra servlet (Jug4Tenda).
Dopo di che Spring MVC “passa la palla” ad un componente che implementa l'interfaccia Controller (package org.springframework.web.servlet.mvc ) e che si occuperà di gestire fisicamente la request.
Il giusto controller da usare è specificato nel file di contesto xml e dipende anche dall'URL ricevuto.
Controller e file di contesto. ...
...
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> ospiteController ...
Nel file di contesto vediamo che la gestione degli url che terminano con Ospite.html è delegata mediante un SimpleUrlHandlerMapping al controller ospiteController.
MultiActionController La classe OspiteControlelr oltre ad implementare l'interfaccia Controller di Spring MVC discende da una classe “preconfezionata” del framework, la MultiActionController.
La sua particolarità risiede nel fatto che può richiamare diversi metodi per processare la request analizzando il contenuto dell'URL.
Tradotto in parole povere il controller analizza l'URL alla ricerca di un parametro param e tenta di invocare un suo metodo pubblico che come nome ha proprioil valore di param (listOspite nel nostro esempio).
MultiActionController 2
Quale parametro della request corrisponda al nome del metodo da invocare è specificato nel file di contesto.
...
ospiteController
class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResol ver"> param
MultiActionController 3
Il controller deve sempre restituire un oggetto di tipo ModelAndView (che fa parte del framework) che contiene i dati restituiti dall'elaborazione della request e una vista logica che deve essere mostrata all'utente.
Il metodo listOspite obbedisce alla regola appena espressa.
public ModelAndView listOspite(HttpSer vletReq uest req uest, HttpServletResponse response) { List elencoOspiti = ospiteManager.getOspiti(0, 100); return new ModelAndView("listOspite", "elencoOspiti", elencoOspiti); }
MultiActionController 4 public ModelAndView listOspite(HttpSer vletReq uest req uest, HttpServletResponse response) { List elencoOspiti = ospiteManager.getOspiti(0, 100); return new ModelAndView("listOspite", "elencoOspiti", elencoOspiti); }
E se per caso in un metodo di gestione request dovessi avere un'eccezione !!!????
La classe MultiActionController permette di definire dei metodi pubblici secondo I lseguente schema (dalla documentazione):
public ModelAndView anyMeaningfulName (HttpServletRequest request, HttpServletResponse response, ExceptionClass exception);
MultiActionController 5 Se viene lanciata un'eccezione viene gestita dal metodo che come 3° parametro ha un'istanza di classe compatibile con quella dell'eccezione lanciata.
Es (dal sorgente di OspiteController): public ModelAndView handleIllegalArgumentException( ..., ..., IllegalArgumentException exception) throws Exception { request.setAttribute("errore", "dateError"); return redirectToFormView(request, response); Il}metodo gestisce l'eccezione
IllegalArgumentException (un'errore di validazione). Il metodo redirectToFormView rimanda alla form di provenienza.
ModelAndView e ViewResolver public ModelAndView listOspite(HttpSer vletReq uest req uest, HttpServletResponse response) { List elencoOspiti = ospiteManager.getOspiti(0, 100); return new ModelAndView("listOspite", "elencoOspiti", elencoOspiti); }
Non rimane che vedere come l'oggetto ModelAndView viene tradotto in una vista concreta, nel nostro caso una pagina JSP.
Ancora una volta nel file di contesto indicheremo quale sarà il componente che trasforma gli oggetti ModelAndView in pagine jsp. Tale componente si chiama appunto viewResolver.
ModelAndView e ViewResolver 2
class="org.springframework.web.servlet.view.InternalResourceViewRes olver"> org.springframework.web.servlet.view.JstlView /WEBINF/jsp/ .jsp
Il viewResolver indica che la dispatch servlet nel restituire all'utente la pagina indicata la andrà a cercare per default alla posizione /WEB-INF/jsp/.
Il file fisico della vista è ottenuto prendendo il nome della vista dell'oggetto ModelAndView (listOspite) e mettendo come prefisso .jsp (/WEB-INF/jsp/listOspite.jsp).
View resolving avanzato Quello che abbiamo visto è il meccanismo standard di Spring MVC per la risoluzione delle viste.
Purtroppo tutto ciò va bene per certi usi ma in alcuni casi reali è un pò limitato... Es: se non volessimo mettere tutte le pagine JSP sotto un unica cartella? Sarebbe meglio raggrupparle per sottocartele
HandlerInterceptorAdapter Per rendere la risoluzione delle viste più fessibile ci viene in soccorso la classe HandlerInterceptorAdapter.
E'una classe di Spring che consente di applicare i concetti dell'AOP alla getione delle request.
Possiamo intercettare la getione delle request e decidere di fare qualcosa prima o dopo che la request sia processata.
Nota: abbiamo appena visto che un Controller quando finisce di processare una request restituisce un ogetto ModelAndView che contiene dati del modello e una vista che li userà. Noi ad esempio vorremmo che le viste generate da ospiteController vadano a cercare le pagine JSP nella sottocartella ospite di jsp.
HandlerInterceptorAdapter: esempio “Scatta” dopo che la request è stata processata.
L'oggetto ModelAndView è pronto per essere restituito.
package org.jugancona.jug4tenda.web.controllers.interceptors; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.springframework.web.servlet.ModelAndView; import org.springframework.web.servlet.handler.HandlerInterceptorAdapter; public class PrefixViewInterceptor extends HandlerInterceptor Adapter { public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { //do something... } }
La classe PrefixViewInterceptor E' un'implementazione di HandlerInterceptorAdapter.
public class PrefixViewInterceptor extends HandlerInterceptorAdapter { private Map subDirMap; public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { String prefix; String className = handler.getClass().getSimpleName(); if (modelAndView.getViewName() != null) { prefix = checkForPattern(className); if (!prefix.isEmpty()) { modelAndView.setViewName(prefix + "/" + modelAndView.getViewName()); } } } }
Metodo postHandle public void postHandle(...) throws Exception { String prefix; String className = handler.getClass().getSimpleName(); ...
In postHandle per prima cosa recuperiamo il nome della classe Cotroller (handler) che ha gestito la request. Abbiamo anche una variabile prefix che come vedremo è la sottocartella in cui cercare la pagina jsp per la vista.
if (modelAndView.getViewName() != null) { prefix = checkForPattern(className); if (!prefix.isEmpty()) { modelAndView.setViewName(prefix + "/" + modelAndView.getViewName()); } }
Successivamente in base al nome della classe si cerca la sotto cartella relativa al controller. Se viene trovato un prefisso esso viene concatenato al nome della vista (che comporra il percorso della jsp).
Metodo postHandle 2 if (modelAndView.getViewName() != null) { prefix = checkForPattern(className); if (!prefix.isEmpty()) { modelAndView.setViewName(prefix + "/" + modelAndView.getViewName()); } }
Il prefisso relativo alla classe Controller viene cercato dal metodo checkForPattern che qui non tratteremo (ma è abbastanza semplice... :-) ).
Esempio: la classe OspiteController avrà ospite come prefisso. Opsite è la sottocartella dove cercare le jsp per le sue viste.
Se OspiteController restituisce la vista “editOspite” il file jsp finale sarà: ...jsp/ospite/editOspite.jsp
Configurazione di HandlerInterceptorAdapter (1) ... ...
Il nostro oggetto SimpleUrlHandlerMapping, ha una proprietà interceptors dove possiamo dichiarare i nostri Advice (in terminologia AOP).
Oltre al nostro prefixViewInterceptor è presente in molti progetti anche openSessionInViewInterceptor che si occupa di gestire le sessioni Hibernate.
Configurazione di HandlerInterceptorAdapter (2) La classe PrefixViewInterceptor è un'estensione di HandlerInterceptorAdapter. La sua particolarati è la proprietà subDirMap. In essa specifichiamo quale sottocartella di JSP corrisponde a un determinato Controller. La corrispondenza si basa sul nome della classe del controller!
Stanchi??
Se volete facciamo un paio di slide su Visual Basic eh??!!!
I FormController: SimpleFormController
Gestisce una singola form di una pagina web
La sua funzione si divide in due parti
Form request (visualizzazione della form)
Carica eventuali dati con cui precaricare la form (se si vogliono variare dati già esistenti ) Mostra la form all'utente
Form submission (invio della form)
Carica i parametri immessi nella form dall'utente. Crea i corrispondenti oggetti di dominio. Valida in nuovi dati. Esegue la logica di invio. Mostra la vista di successo. Se la validazione non va a buon fine rimanda alla form.
I FormController: SimpleFormController 1
Gestisce una singola form di una pagina web
La sua funzione si divide in due parti
Form request (visualizzazione della form)
Carica eventuali dati con cui precaricare la form (se si vogliono variare dati già esistenti ) Mostra la form all'utente
Form submission (invio della form)
Carica i parametri immessi nella form dall'utente. Crea i corrispondenti oggetti di dominio. Valida in nuovi dati. Esegue la logica di invio. Mostra la vista di successo. Se la validazione non va a buon fine rimanda alla form.
I FormController: SimpleFormController 2
I FormController per funzionare usano svariate tecniche presenti nel mondo JEE (taglib, property editor, ecc...) Non penso si possano dare tutte per scontate e ci vorrebbe un meeting a parte per conoscerle. Il modo migliore di approcciarsi ai FormController rimane il tutorial che si trova nella distribuzione di Spring alla posizione docs/MVCstepbystep. Tuttavia vale la pena introdurre un paio di concetti propedeutici...
PropertyEditorSupport 1
Il concetto di PropertyEditor nasce considerando che spesso molti tipi primitivi (interi, double, date, ecc...) hanno bisogno in fase di visualizzazione di essere formattati. Es: la data italiana è dd/mm/YYYY, quella inglese è mm/dd/YYYY ma per Java è un numero in millisecondi!
Il “casino” aumenta se consideriamo che l'utente inserisce i dati nel formato a lui familiari ed essi devono essere tradotti in tipi primitivi Java!!!
DatePropertyEditor: code snippet 1 ... private static SimpleDateFormat formatter;
public void setAsText(String text) throws IllegalArgumentException { try { setValue(formatter.parse(text)); } catch (ParseException e) { //throw new IllegalArgumentException("Invalid date format"); setValue(null); } } ...
Il metodo setAsText(String text) ereditato dalla classe base PropertyEditorSupport, usa la classe standard di java SimpleDateFormat, per convertire testo in Date e viceversa
PropertyEditorSupport 2
La classe PropertyEditorSupport è la classe da base per creare un componente comune e riutilizzabile che si occupa delle conversioni testo <> dato. Nel package org.jugancona.jug4tenda.utility del nostro progetto c'è il nostro PropertyEditor DatePropertyEditor che si occupa delle date. I FormController dispongono del metodo initBinder() che consente di associare uno o più PropertyEditor a campi della form per effettuare le conversioni testo <> dato.
DatePropertyEditor: code snippet 2 ... public void setPattern(String pattern) { formatter = new SimpleDateFormat(pattern); } ...
L'attributo formatter è costruito in base ad un pattern di data (es: dd/mm/YYYY). Se riprendiamo il file di contesto vediamo che è lì che abbiamo configurato il pattern!
${dateFormat}
Libreria DisplayTag: cenni
E' una libreria di tag jsp (taglib) molto utile per visualizzare oggetti Java nelle pagine jsp. Es (listOspite.jsp): visualizzazione di una lista
Libreria Libreria JSTL: cenni
E' una libreria di tag jsp sviluppata da Apache. Semplifica la visualizzazione degli oggetti Java visibili da una pagina jsp. Es:
Scrive su jsp il valore della proprietà nome dell' oggetto ospite.
Libreria Libreria JSTL: cenni 2
E' utile anche usare I tag di formattazione, per visualizzare valori che hanno bisogno di una formattazione comprensibile dall'utente. Es: le date
La pagina “vede” la lista elencoOspiti. La tabella ha lo stesso nome.
Domande...?
JUG – Ancona Italy
Grazie !
Andrea Del Bene
JUG Marche www.jugancona.it
