JUG – Ancona Italy Spring MVC Andrea Del Bene Jug Marche

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 :-)... Cos'è Spring 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

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. Il punto di partenza: il file web.xml Jug4Tenda org.springframework.web.servlet.DispatcherServlet contextConfigLocation classpath:springConfigFiles/jug4tendaContext.xml 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.... < bean id="ospiteController" class="org.jugancona.jug4tenda.web.controllers.OspiteController">... <bean id="urlMapping" 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. < bean id="ospiteController" class="org.jugancona.jug4tenda.web.controllers.OspiteController">... <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> ospiteController <bean id="methodNameResolver" class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameRe solver"> 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. public ModelAndView listOspite(HttpServletRequest request, HttpServletResponse response) { List elencoOspiti = ospiteManager.getOspiti(0, 100); return new ModelAndView("listOspite", "elencoOspiti", elencoOspiti); } Il metodo listOspite obbedisce alla regola appena espressa.

MultiActionController 4 public ModelAndView listOspite(HttpServletRequest request, 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(HttpServletRequest request, 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 <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResol ver"> org.springframework.web.servlet.view.JstlView /WEB-INF/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. Noi ad esempio vorremmo che le viste generate da ospiteController vadano a cercare le pagine JSP nella sottocartella ospite di jsp. 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à.

HandlerInterceptorAdapter: esempio 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... } “Scatta” dopo che la request è stata processata. L'oggetto ModelAndView è pronto per essere restituito.

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 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. public void postHandle(...) throws Exception { String prefix; String className = handler.getClass().getSimpleName();... 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) <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> 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.

<bean id="prefixViewInterceptor" class="org.jugancona.jug4tenda.web.controllers.interceptors. PrefixViewInterceptor"> 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/MVC-step-by-step. 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! <bean class="org.jugancona.jug4tenda.utility.DatePropertyEditor" id="dateFormatter"> ${dateFormat}

E' una libreria di tag jsp (taglib) molto utile per visualizzare oggetti Java nelle pagine jsp. Es (listOspite.jsp): visualizzazione di una lista <display:table name="elencoOspiti" class="dataTable" uid="elencoOspiti" cellspacing="0" cellpadding="1"> <display:column property="id" href="detailOspite.html?param=viewOspiteDetail" paramId="id" class="cellTable" headerClass="cellTable"/> <display:column property="dataNascita" decorator="org.jugancona.jug4tenda.utility.DatePropertyEditor" titleKey="ospite.dataNascita" class="cellTable" headerClass="cellTable"/> Libreria DisplayTag: cenni

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.

E' utile anche usare I tag di formattazione, per visualizzare valori che hanno bisogno di una formattazione comprensibile dall'utente. Es: le date <fmt:formatDate value="${ospite.dataNascita}" type="date"... Libreria Libreria JSTL: cenni 2

La pagina “vede” la lista elencoOspiti. La tabella ha lo stesso nome. <display:table name="elencoOspiti" class="dataTable" uid="elencoOspiti" cellspacing="0" cellpadding="1"> <display:column property="id" href="detailOspite.html?param=viewOspiteDetail" paramId="id" class="cellTable" headerClass="cellTable"/> <display:column property="dataNascita" decorator="org.jugancona.jug4tenda.utility.DatePropertyEditor" titleKey="ospite.dataNascita" class="cellTable" headerClass="cellTable"/>

Domande...?

JUG – Ancona Italy Grazie ! Andrea Del Bene JUG Marche -