Spring MVC - The Basics

Spring MVC - The Basics Ilio Catallo - info@iliocatallo.it

Outline • MVC and MVC 2 • Request processing pipeline • Se8ng up Spring MVC • Wri:ng Controllers • References

Model-View-Controller The Model-View-Controller (MVC) pa5en was invented at Xerox Parc by Trygve Reenskaug in 1979

MVC pa'ern Applica'ons should have three major parts • The part that manages the data • The part that creates screens and reports • The part that handles interac3ons between the user and the other subsystems

MVC pa'ern Applica'ons should have three major parts • Model • View • Controller

MVC pa'ern Applica'ons should have three major parts • Domain model • View • Controller

What is the reason not to use the same MVC pa2ern also for Web applica7ons?

HTTP limita*ons The reason is that the HTTP protocol limits the applicability of the MVC pa7ern

Stateless protocol The MVC pa*ern requires a stateful protocol to keep track of the applica.on state

Applica'on state "If we think of an applica1on as being computerized behavior that achieves a goal, we can describe an applica1on protocol as the set of legal interac1ons necessary to realize that behavior. Applica3on state is a snapshot of an execu1on of such an applica1on protocol." (J. Webber et al.)

Stateless protocol However, HTTP is stateless

Pull protocol The MVC pa*ern requires a push protocol for the views to be no7ﬁed by the model

Pull protocol However, HTTP is a pull protocol: no request implies no response

How can we overcome such limita2ons?

Stateless protocol HTTP is stateless: we can implement the MVC design pa3ern on top of the Java Servlet Pla;orm

Stateless protocol The Java Servlet Pla-orm provides a session context to help track users in the applica8on

Pull protocol HTTP is a pull protocol: we can increase the Controller responsibility

Pull protocol Namely, the Controller will be responsible for: • State changes • State queries • Change no2ﬁca2ons

MVC 2 pa(ern The resul)ng pa.ern is some)mes called MVC 2 or Web MVC +-------------+ +---------------+ +----------------+ | +----------> +---------> | | View | | Controller | | Domain model | | <----------+ <---------+ | +-------------+ +---------------+ +----------------+

MVC 2 pa(ern Any state query or change no0ﬁca0on must pass through the Controller +-------------+ +---------------+ +----------------+ | +----------> +---------> | | View | | Controller | | Domain model | | <----------+ <---------+ | +-------------+ +---------------+ +----------------+

MVC 2 pa(ern The View renders data passed by the Controller rather than data returned directly from the Model +-------------+ +---------------+ +----------------+ | +----------> +---------> | | View | | Controller | | Domain model | | <----------+ <---------+ | +-------------+ +---------------+ +----------------+

Compe&ng architectures Note that MVC 2 proposes a compe&ng architecture to the one we presented during the last lecture ┌──────┐┌────────────────────────────────┐ │ D ││ │ │ o ││ Presentation layer │ │ m ││ │ │ a │└────────────────────────────────┘ │ i │┌────────────────────────────────┐ │ n ││ │ │ ││ Service layer │ │ m ││ │ │ o │└────────────────────────────────┘ │ d │┌────────────────────────────────┐ │ e ││ │ │ l ││ Persistence layer │ │ ││ │ └──────┘└────────────────────────────────┘

Compe&ng architectures We reconcile the two architectures by limi3ng the scope of the MVC 2 pa;ern to the sole presenta(on layer ┌──────┐┌────────────────────────────────┐ │ D ││ │ │ o ││ Presentation layer │ │ m ││ │ │ a │└────────────────────────────────┘ │ i │┌────────────────────────────────┐ │ n ││ │ │ ││ Service layer │ │ m ││ │ │ o │└────────────────────────────────┘ │ d │┌────────────────────────────────┐ │ e ││ │ │ l ││ Persistence layer │ │ ││ │ └──────┘└────────────────────────────────┘

What is Spring MVC? Spring MVC is an open source MVC 2 framework for developing Web applica3ons

Spring MVC Spring MVC eases Web applica2on development • It provides a ready-to-use MVC 2 Controller • It promotes Spring’s loosely coupled techniques in the presenta>on layer of an applica>on

DispatcherServlet Spring MVC is designed around a central servlet named DispatcherServlet Presentation layer +---------------------------------+ | | | | | | | +-----------------------+ | | | | | | | DispatcherServlet | | | | | | | +-----------------------+ | | | | | | | | | +---------------------------------+

DispatcherServlet DispatcherServlet acts as a centralized entry point to the Web applica.on Presentation layer +---------------------------------+ | | | | | | +---------------+ | +-----------------------+ | | | Request | | | | | Browser +--------------> DispatcherServlet | | | | | | | | +---------------+ | +-----------------------+ | | | | | | | | | +---------------------------------+

DispatcherServlet That is, every request is handled by DispatcherServlet Presentation layer +---------------------------------+ | | | | | | +---------------+ | +-----------------------+ | | | Request | | | | | Browser +--------------> DispatcherServlet | | | | | | | | +---------------+ | +-----------------------+ | | | | | | | | | +---------------------------------+

DispatcherServlet DispatcherServlet is an expression of the front controller pa.ern Presentation layer +---------------------------------+ | | | | | | +---------------+ | +-----------------------+ | | | Request | | | | | Browser +--------------> Front Controller | | | | | | | | +---------------+ | +-----------------------+ | | | | | | | | | +---------------------------------+

The Front Controller The Front controller’s job is to determine a suitable handler capable of performing the actual processing Presentation layer +---------------------------------+ | | | | | | +---------------+ | +-----------------------+ | | | Request | | | | | Browser +--------------> Front Controller | | | | | | | | +---------------+ | +-----------+-----------+ | | | | | | | | | | | +--------v---------+ | | | | | | | Handler | | | | | | | +------------------+ | | | | | +---------------------------------+

Controllers Handlers are nearly always Spring MVC controllers Presentation layer +---------------------------------+ | | | | | | +---------------+ | +-----------------------+ | | | Request | | | | | Browser +--------------> Front Controller | | | | | | | | +---------------+ | +-----------+-----------+ | | | | | | | | | | | +--------v---------+ | | | | | | | Controller | | | | | | | +------------------+ | | | | | +---------------------------------+

Model The selected Controller interacts with the service layer; the relevant data are collected in a view model Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------------------+-------+ | | | | | | | | | | | | +--------v----------+ | | | | | Persistence layer | | | | | +--------+----------+ | | | | | | +---v----------+ | | v | | | | | +--+---+ | | Controller <-----+ | | | | | | | DB | | +--------------+ | | | +--------------------------------------+ +------+

Model The selected Controller interacts with the service layer; the relevant data are collected in a view model Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------------------+-----^-+ | | | | | | | | | | | +---+---+ | | +--------v----------+ | | | Model | | | | Persistence layer | | | +---+---+ | | +--------+----------+ | | | | | | | +---v-----+----+ | | v | | | | | +--+---+ | | Controller <-----+ | | | | | | | DB | | +--------------+ | | | +--------------------------------------+ +------+

Model Spring MVC refers to the view model simply as the model. This may lead to confusion with the classic MVC terminology Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------------------+-----^-+ | | | | | | | | | | | +---+---+ | | +--------v----------+ | | | Model | | | | Persistence layer | | | +---+---+ | | +--------+----------+ | | | | | | | +---v-----+----+ | | v | | | | | +--+---+ | | Controller <-----+ | | | | | | | DB | | +--------------+ | | | +--------------------------------------+ +------+

Model Regardless the name, remember that the model consists of data the Controller prepares just for the view Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------------------+-----^-+ | | | | | | | | | | | +---+---+ | | +--------v----------+ | | | Model | | | | Persistence layer | | | +---+---+ | | +--------+----------+ | | | | | | | +---v-----+----+ | | v | | | | | +--+---+ | | Controller <-----+ | | | | | | | DB | | +--------------+ | | | +--------------------------------------+ +------+

Controllers When the controller has ﬁnished processing, the front controller determines which view to render Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------------------+-----^-+ | | | | | | | | | | | +---+---+ | | +--------v----------+ | | | Model | | | | Persistence layer | | | +---+---+ | | +--------+----------+ | | | | | | | +-------------+ +---v-----+----+ | | v | | | | | | | +--+---+ | | View | | Controller <-----+ | | | | | | | | | DB | | +-------------+ +--------------+ | | | +--------------------------------------+ +------+

Views When the controller has ﬁnished processing, the front controller determines which view to render Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-------+-----------+-----^-+ | | | | | | | | | | | +---+---+ | +---+---+ | | +--------v----------+ | | Model | | | Model | | | | Persistence layer | | +---+---+ | +---+---+ | | +--------+----------+ | | | | | | | | +--------v----+ +---v-----+----+ | | v | | | | | | | +--+---+ | | View | | Controller <-----+ | | | | | | | | | DB | | +-------------+ +--------------+ | | | +--------------------------------------+ +------+

Views When the controller has ﬁnished processing, the front controller determines which view to render Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | | | | | | | +--------+----------+ +-------------+ | +-^-----+-----------+-----^-+ | | | | | | | | | | | | | +---+---+ | +---+---+ | | +--------v----------+ | | | Model | | | Model | | | | Persistence layer | | | +---+---+ | +---+---+ | | +--------+----------+ | | | | | | | | | +--+-----v----+ +---v-----+----+ | | v | | | | | | | +--+---+ | | View | | Controller <-----+ | | | | | | | | | DB | | +-------------+ +--------------+ | | | +--------------------------------------+ +------+

Views When the controller has ﬁnished processing, the front controller determines which view to render Presentation layer +--------------------------------------+ | | +-------------+ Request | +---------------------------+ | | +--------------> | | +-------------------+ | Browser | | | Front controller | | +-> Service layer | | +<-------------+ | | | +--------+----------+ +-------------+ Response| +-^-----+-----------+-----^-+ | | | | | | | | | | | | | +---+---+ | +---+---+ | | +--------v----------+ | | | Model | | | Model | | | | Persistence layer | | | +---+---+ | +---+---+ | | +--------+----------+ | | | | | | | | | +--+-----v----+ +---v-----+----+ | | v | | | | | | | +--+---+ | | View | | Controller <-----+ | | | | | | | | | DB | | +-------------+ +--------------+ | | | +--------------------------------------+ +------+

Se#ng up Spring MVC Se#ng up Spring MVC is a two-step process 1. Loading DispatcherServlet in the Web container 2. Instan5a5ng a DI container and the related beans

1. Loading DispatcherServlet in the Web container

Loading the front controller We need to tell the Web container to load DispatcherServlet

Loading the front controller To this end, we provide the Web container with a web.xml deployment descriptor ﬁle + Web components | (e.g., servlets) | +-------v--------+ | | | Web | web.xml +--------> container | | | +-------+--------+ | | v Web app

Loading the front controller Recall that the web.xml ﬁle describes how to deploy the Web components of an applica6on + Web components | (e.g., servlets) | +-------v--------+ | | | Web | web.xml +--------> container | | | +-------+--------+ | | v Web app

Loading the front controller  <servlet> <servlet-name>frontcontroller</servlet-name> <servlet-class> org.springframework.web.servlet.DispatcherServlet </servlet-class> <load-on-startup>1</load-on-startup> </servlet>  <servlet-mapping> <servlet-name>frontcontroller</servlet-name> <url-pattern>/</url-pattern> </servlet-mapping>

2. Instan)a)ng a DI container and the related beans

Instan&a&ng beans DispatcherServlet instan'ates a Spring DI container +---------------------------------------------------+ | | | | | | | +------------+ +------------+ | | | +------------+ | +------------+ | | | | +-------------+ | | +-------------+ | | | | | | | | | | | | +-+ | Controllers | +-+ | Special | | | +-+ | +-+ beans | | | +-------------+ +-------------+ | | | | | | | +---------------------------------------------------+ Spring DI Container

Instan&a&ng beans Such a container hosts beans belonging to the presenta(on layer • Controllers • Special beans

Controllers Controllers are wri'en by the developer and provide access to the service layer of the applica5on @Controller public class AccountController { ... }

Special beans Special beans are beans that are already part of Spring MVC

Special beans More precisely, special beans are DispatcherServlet's collaborators

Special beans DispatcherServlet relies on them to process requests and render the appropriate views

Special beans Each special bean plays its own small part in the overall processing of the request

Special beans For instance: • HandlerMapping maps HTTP requests to handlers • ViewResolver maps logical name to views • HandlerExceptionResolver maps excep:ons to handlers

Special bean interfaces Each special bean is expressed as an interface public interface ViewResolver { View resolveViewName(String viewName, Locale locale); }

Special bean advantages Thanks to this, the request processing pipeline is highly ﬂexible and conﬁgurable

Special bean advantages Indeed, we can tailor each stage of the pipeline just by changing its concrete implementa9on public class VelocityViewResolver implements ViewResolver { ... } public class XmlViewResolver implements ViewResolver { ... } public class InternalResourceViewResolver implements ViewResolver { ... }

Default special beans For each special bean, the DispatcherServlet maintains a list of implementa)ons to be used by default

Default special beans For instance, InternalResourceViewResolver is instan-ated by default public class InternalResourceViewResolver implements ViewResolver { ... }

Default special beans If not stated otherwise, DispatcherServlet will use default implementa4ons throughout the en4re processing pipeline

Web beans Controllers and special beans are the Web beans of our applica3on +---------------------------------------------------+ | | | | | | | +------------+ +------------+ | | | +------------+ | +------------+ | | | | +-------------+ | | +-------------+ | | | | | | | | | | | | +-+ | Controllers | +-+ | Special | | | +-+ | +-+ beans | | | +-------------+ +-------------+ | | | | | | | +---------------------------------------------------+ Spring DI Container

WebApplicationContext The container we obtain is of type WebApplicationContext +---------------------------------------------------+ | | | | | | | +------------+ +------------+ | | | +------------+ | +------------+ | | | | +-------------+ | | +-------------+ | | | | | | | | | | | | +-+ | Controllers | +-+ | Special | | | +-+ | +-+ beans | | | +-------------+ +-------------+ | | | | | | | +---------------------------------------------------+ Spring DI Container

WebApplicationContext WebApplicationContext extends the ApplicationContext interface with some extra features necessary for Web applica7ons public interface WebApplicationContext extends ApplicationContext { ... }

frontcontroller-servlet.xml In par'cular, the container looks in WEB-INF/ for an XML ﬁle named frontcontroller-servlet.xml1 1 More generally, the servletName in servletName-servlet.xml must be the same as the <servlet-name> speciﬁed in web.xml

frontcontroller-servlet.xml <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xmlns:mvc="http://www.springframework.org/schema/mvc" xsi:schemaLocation=”...">  </beans>

Overriding defaults By altering frontcontroller-servlet.xml, we can customize or replace default beans within the container

Overriding defaults Example: customizing InternalResourceViewResolver <bean class="org.springframework.web. servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>

Controllers Controllers are responsible for responding to the ac#ons the user takes on the user interface • Submi'ng a form • Clicking on a link • Accessing a page

Types of controllers There exist two op-ons for wri-ng controllers • Using the @Controller annota-on • Implemen-ng the Controller interface2 2 Do not use this approach. The only reason why the Controller interface is s5ll available is to preserve compa5bility with legacy code

Annotated controllers To write annotated controllers we need to use the @Controller annota/on @Controller public class GreetingController { ... }

Annotated controllers The @Controller annota)on indicates that a par)cular class serves the role of a controller @Controller public class GreetingController { ... }

Auto-detec)ng controllers A simple addi+on to frontcontroller-servlet.xml allows the container to auto-detect annotated controllers <context:component-scan base-package="it.polimi.awt.springmvc.web"/>

Auto-detec)ng controllers The <context:component-scan> element recursively scans a package, looking for classes to be automa8cally registered as beans <context:component-scan base-package="it.polimi.awt.springmvc.web"/>

@RequestMapping The @RequestMapping annota)on is used to map URLs to handler methods @Controller public class GreetingController { @RequestMapping("/greeting") public String getGreeting() { ... } }

@RequestMapping The /greeting URL is mapped to getGreeting() @RequestMapping("/greeting") public String getGreeting() { ... }

Unique endpoints Think of handler methods as unique endpoints, with mappings derived from the related @RequestMapping annota6ons @RequestMapping("/greeting") public String getGreeting() {...}

Annotated controllers upsides When you open a controller, you can see which URLs the controller is mapped to @RequestMapping("/greeting") public String getGreeting() {...}

Annotated controllers downsides The mapping is sca$ered throughout the codebase, making it harder to see which URL is mapped to which handler method @RequestMapping("/greeting") public String getGreeting() {...}

Mapping URLs to handlers In order to interpret the mappings deﬁned in the controller class, Spring MVC needs a HandlerMapping implementa8on @RequestMapping("/greeting") public String getGreeting() {...}

Determining which handler to call The HandlerMapping interface provides the abstrac2on for mapping requests to handlers3 public interface HandlerMapping { public HandlerExecutionChain getHandler(HttpServletRequest request); } 3 The getHandler method returns a HandlerExecutionChain only because of the need of accoun4ng for possible interceptors. Conceptually, we can s4ll assume the method to return a handler

Overriding HandlerMapping DefaultAnnotationHandlerMapping is the default implementa-on of HandlerMapping public class DefaultAnnotationHandlerMapping implements HandlerMapping { ... }

Overriding HandlerMapping As of Spring 3, the suggested implementa.on became RequestMappingHandlerMapping public class DefaultAnnotationHandlerMapping implements HandlerMapping { ... } public class RequestMappingHandlerMapping implements HandlerMapping { ... }

Overriding HandlerMapping RequestMappingHandlerMapping is a HandlerMapping implementa+on that allows performing more advanced opera+ons • Data valida*on • Wri*ng and reading JSON • Date and numbers support

Overriding HandlerMapping To start using RequestMappingHandlerMapping, it is suﬃcient to alter frontcontroller-servlet.xml so as to add <mvc:annotation-driven/>

Responsibili*es We already know that the Web layer has two responsibili-es 1. Glueing together the service layer and the Web 2. Taking care of the naviga;on logic

Responsibili*es Let us now see how to implement such responsibili2es in prac(ce 1. Glueing together the service layer and the Web 2. Taking care of the naviga;on logic

1. Interac+ng with the service layer

Interac(ng with the service layer A"er being invoked, the controller processes the HTTP request and interacts with the service layer +---------------+ +----------------+ | +---------> | | Controller | | Service layer | | <---------+ | +---------------+ +----------------+

GreetingService For instance, we may assume that in our ﬁc3onal applica3on, the user can request a random gree3ng public interface GreetingService { public String getRandomGreeting(); }

GreetingService implementa*on public class NaiveGreetingService implements GreetingService { private List<String> greetings; public NaiveGreetingService() { this.greetings = Arrays.asList( "Hello sweetie", "Valar morghulis", "Tiger tiger" ); } @Override public String getRandomGreeting() { int index = ThreadLocalRandom.current().nextInt(greetings.size()); return greetings.get(index); } }

Execu&ng the use case Within the handler method, we ﬁrst execute the related use case @Controller public class GreetingController { private GreetingService service; @RequestMapping("/greeting") public String getGreeting() { // execute the related use case String greeting = service.getRandomGreeting(); ... } }

Execu&ng the use case Such an invoca+on may result in an arbitrarily complex object @Controller public class GreetingController { private GreetingService service; @RequestMapping("/greeting") public String getGreeting() { // execute the related use case String greeting = service.getRandomGreeting(); ... } }

Execu&ng the use case However, in this case we end up with a simple String @Controller public class GreetingController { private GreetingService service; @RequestMapping("/greeting") public String getGreeting() { // execute the related use case String greeting = service.getRandomGreeting(); ... } }

Model Once we collected the use case outcome, the next step is to build a model object +--------------+ +--------------------+ +----------------+ | | +----------+ | | +----------+ | | | View <--+ Model +--+ Front Controller <--+ Model +--+ Controller | | | +----------+ | | +----------+ | | +--------------+ +--------------------+ +----------------+

Model This model object will contain the frac%on of the outcome that holds some signiﬁcance for the next view to render +--------------+ +--------------------+ +----------------+ | | +----------+ | | +----------+ | | | View <--+ Model +--+ Front Controller <--+ Model +--+ Controller | | | +----------+ | | +----------+ | | +--------------+ +--------------------+ +----------------+

Model The view will use the model to build up the dynamic parts of the user interface +--------------+ +--------------------+ +----------------+ | | +----------+ | | +----------+ | | | View <--+ Model +--+ Front Controller <--+ Model +--+ Controller | | | +----------+ | | +----------+ | | +--------------+ +--------------------+ +----------------+

Model The model is the collec+on of named objects needed by the view in order to render itself +---------------+--------------+ | key1 | value1 | +------------------------------+ | key2 | value2 | +------------------------------+ | key3 | value3 | +---------------+--------------+

Model a(ributes These named objects are usually called model a.ributes +---------------+--------------+ | key1 | value1 | +------------------------------+ | key2 | value2 | +------------------------------+ | key3 | value3 | +---------------+--------------+

Model implementa-ons Several data structures can be used for represen2ng a model • Any implementa-on of java.util.Map • Any implementa-on of the Model interface provided by Spring • A ModelMap object provided by Spring

Model as an input argument Regardless the speciﬁc implementa2on, it is common prac2ce to let the framework provide the model directly as an input argument public String getGreeting(Map<String, Object> model) {...} public String getGreeting(Model model) {...} public String getGreeting(ModelMap model) {...}

Model as a Map The only requirement when using java.util.Map to store model a4ributes is that the key has to be of type String @RequestMapping("/greeting") public String getGreeting(Map<String, Object> model) { String greeting = service.getRandomGreeting(); model.put("greeting", greeting); ... }

Model as a Map The value part of the map can be freely decided. Because of its generality, Object is a popular choice @RequestMapping("/greeting") public String getGreeting(Map<String, Object> model) { String greeting = service.getRandomGreeting(); model.put("greeting", greeting); ... }

Model as a Model The downside of using a Map is that we have to decide the name of each model a)ribute we want to store // deciding names... boring (and difficult!) model.put("greeting", greeting);

Model as a Model The Model interface provides convenient methods for popula4ng the Model, such as addAttribute() @RequestMapping("/special-deals") public String getSpecialDeals(Model model) { List<SpecialDeal> specialDeals = service.getSpecialDeals(); model.addAttribute(specialDeals); ... }

Model as a Model addAttribute() is the same as Map’s put(), except that it automa&cally generates the name for the model a5ribute @RequestMapping("/special-deals") public String getSpecialDeals(Model model) { List<SpecialDeal> specialDeals = service.getSpecialDeals(); model.addAttribute(specialDeals); ... }

Naming strategy • Scalar objects take the uncapitalized, unqualified class name • Collec.on objects take the uncapitalized, unqualified class name of the first object in the collec:on, with List appended to the name

Naming strategy Examples: • com.myapp.Product becomes product • List<com.myapp.Product> becomes productList

You can s)ll decide the names If needed, it is s+ll possible to decide the name of each model a4ribute @RequestMapping("/fullname") public String getFullname(Model model) { // as both "Jon" and "Snow" are of type // String, it is better to explicitly name them model.addAttribute("name", "Jon"); model.addAttribute("surname", "Snow"); ... }

Model as ModelMap The ModelMap class is a Map, but it provides some addi4onal conveniences w.r.t. the plain Map interface @RequestMapping("/fullname") public String getFullname(Model model) { // chained calls are handy! model.addAttribute("name", "Jon") .addAttribute("surname", "Snow"); ... }

Model as ModelMap Namely: • It adheres to the same naming conven2on as Model • The addAttribute() method checks if the values are null • It supports chained calls of the addAttribute() method

2. Taking care of the naviga2on logic

Choosing the next view When processing is complete, the controller is responsible for choosing what view the user sees next +--------------+ +--------------------+ +----------------+ | | +----------+ | | +----------+ | | | View <--+ Model +--+ Front Controller <--+ Model +--+ Controller | | | +----------+ | | +----------+ | | +--------------+ +--------------------+ +----------------+

The View renders the model Views are responsible for rendering the objects in the Model +--------------+ +--------------------+ +----------------+ | | +----------+ | | +----------+ | | | View <--+ Model +--+ Front Controller <--+ Model +--+ Controller | | | +----------+ | | +----------+ | | +--------------+ +--------------------+ +----------------+

The View interface Spring MVC does not make any assump)on on the speciﬁc view technology • JavaServer Pages • JavaServer Faces • Velocity

The View interface To this end, views are modeled according to the View interface public interface View { void render(Map<String,?> model, HttpServletRequest request, HttpServletResponse response) String getContentType(); }

The View interface As with many Spring’s interfaces, the View interface is really simple public interface View { void render(Map<String,?> model, HttpServletRequest request, HttpServletResponse response) String getContentType(); }

The render() method The View will render the output star2ng from • The Model • The Servlet’s request and response objects

The render() method The render() method returns void to denote that it is the arriving point of the en0re request processing pipeline7 void render(Map<String,?> model, HttpServletRequest request, HttpServletResponse response) 7 Here, we are not considering possible calls to HandlerInterceptor.afterCompletion()

The render() method Hence, it is the responsibility of the View not only to render the content, but also to actually return it to the client void render(Map<String,?> model, HttpServletRequest request, HttpServletResponse response)

Wri$ng a View implementa$on Given the interface, we can easily write a View implementa4on public class GreetingView implements View { @Override public void render(Map<String, ?> model, HttpServletRequest request, HttpServletResponse response) throws Exception { PrintWriter out = response.getWriter(); out.print(model.get("greeting")); out.flush(); out.close(); } @Override String getContentType() { ... } }

View implementa*ons However, most probably we would prefer to use a speciﬁc view technology, rather than implemen9ng our own Views

View technology independence Spring MVC makes a special eﬀort to keep the controller unaware of the adopted view technology @RequestMapping("/greeting") public String getGreeting(Model model) { ... return "greeting"; }

View technology independence Such a decoupling is achieved by referring to views by their logical name @RequestMapping("/greeting") public String getGreeting(Model model) { ... return "greeting"; }

View technology independence In order to enforce decoupling, we let the controller knows nothing of the view but its logical name @RequestMapping("/greeting") public String getGreeting(Model model) { ... return "greeting"; }

ViewResolver The special bean ViewResolver will later resolve the view’s logical name to an actual view instance public interface ViewResolver { View resolveViewName(String viewName, Locale locale); }

ViewResolver Implementa)ons of ViewResolver are able to provide the mapping between logical names and View objects +-----------------+ | | | ViewResolver | | | +---+-----------^-+ | | +---v----+ | | View | | +---+----+ | | | +-----v-----------+---+ +----------------+ | | | | | DispatcherServlet <-------+ Controller | | | | | +---------------------+ +----------------+

getGreeting() @RequestMapping("/greeting") public String getGreeting(Model model) { String greeting = service.getRandomGreeting(); model.addAttribute("greeting", greeting); return "greeting"; }

Controller testability Note that this allows controllers to be easily unit-tested6 public class GreetingControllerTest { @Test public void getGreetingTest() { GreetingController controller = new GreetingController(...); Map<String, Object> model = new HashMap<>(); String viewName = controller.getGreeting(model); assertTrue(viewName.equals("greeting")); assertTrue(model.get("expression") != null); } } 6 Snippet adapted from h0p://stackoverﬂow.com/a/9363053/1849221

InternalResourceViewResolver The most commonly used ViewResolver when developing with JSP is the InternalResourceViewResolver

InternalResourceViewResolver InternalResourceViewResolver obtains the psychical view loca1on by surrounding the logical name with a preﬁx and a suﬃx

InternalResourceViewResolver We need to conﬁgure InternalResourceViewResolver in frontcontroller-servlet.xml <bean class="org.springframework.web. servlet.view.InternalResourceViewResolver"> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean>

Hiding JSP pages It is good prac-ce to place all view pages under the /WEB-INF directory

Hiding JSP pages This protects the pages from being retrieved independently of the Controllers that conﬁgure them

References • Stackoverﬂow, Design pa5erns for Web applica:ons • SpringSource, Spring Framework Reference • SpringSource, Java-doc APIs • Stackoverﬂow, ModelMap usage in Spring

References • S. Ladd, K. Donald, Expert Spring MVC and Web ﬂows, Apress PublicaBons • M. Deinum, K. Serneels, Pro Spring MVC: with Web ﬂows, Apress PublicaBons • Craig Walls, Spring in AcBon (3rd EdiBon), Manning PublicaBons • T. N. Husted et al., Struts 1 In AcBon, Manning PublicaBons

References • Clarence Ho, Rob Harrop, Pro Spring 3, Apress Publica8ons • Rod Johnson et al., Professional Java Development with the Spring Framework, Wiley Publishing

Spring MVC - The Basics

More Related Content

What's hot

Viewers also liked

Similar to Spring MVC - The Basics

More from Ilio Catallo

Recently uploaded

Spring MVC - The Basics