Spring MVC - Web Forms

Spring MVC - Web forms
Ilio Catallo - info@iliocatallo.it

Outline
• First principles
• Data binding
• Data valida3on
• The PRG pa:ern
• References

Handling user input
Web apps o)en have to perform some logic against one or more
pieces of informa(on coming from the user
User User's
interaction +-------------+ information +-------------+
| | | |
+--------------> Browser +-------------------> Web app |
| | | |
+-------------+ +-------------+

Request parameters
Request parameters can be transferred as part of
• The query string
• The HTTP en1ty body

Request parameters
• The HTTP en)ty body

Query string
Request parameters are speciﬁed as a sequence of URL
parameters appended to the request URL
http://my.server/resource?par1=val1&par2=val2
<----------------->
URL parameters

Query string
In other words, request parameters are appended to the
query string
http://my.server/resource?par1=val1&par2=val2
<----------------->
query string

Gree$ng by name
Assume that we want our applica2on to be able to accept the
name and the surname of the user to greet

Gree$ng by name
In order to do so, we ﬁrst provide an addi1onal overload of
getRandomGreeting()
public interface GreetingService {
public String getRandomGreeting();
public String getRandomGreeting(String name, String surname);
}

Parsing request parameters
Second, we need a mechanism for parsing the HTTP request so as
to extract the related request parameters
HTTP request
+--------------------------------------+
| &surname=Snow |
+--------------------------------------+
| |
| User-Agent: ... |
| |
+--------------------------------------+

@RequestParam
One such mechanism is the @RequestParam annota.on
HTTP request
+--------------------------------------+
| &surname=Snow |
+--------------------------------------+
| |
| User-Agent: ... |
| |
+--------------------------------------+

@RequestParam
The @RequestParam annota)on binds request parameters to
method parameters
@RequestMapping("/custom-greeting")
public String getGreeting(@RequestParam("name") String name,
@RequestParam("surname") String surname,
Model model) { ... }

Request vs. method parameters
The name request parameter binds to the name method parameter

Request vs. method parameters
The surname request parameter binds to the surname method
parameter

@RequestParam
We can now add an addi+onal overload of getGreeting() and
associate it with the /custom-greeting endpoint
public class GreetingController {
@RequestMapping("/greeting")
public String getGreeting(Model model) { ... }
}

getGreeting()
Model model) {
String greeting = service.getRandomGreeting(name, surname);
model.addAttribute("greeting", greeting);
return "greeting";
}

Required by default
Request parameters speciﬁed using @RequestParam are required
by default

URL templates
To trigger the execu-on of getGreeting(), we should construct
a URL according to the following URL template
http://myserver.com/webapp/custom-greeting?name={name}
&surname={surname}

HTML forms
A possible way to construct URLs from a URL template is to use an
HTML form
<form action="..." method="...">
</form>

HTML forms
HTML forms are hypermedia controls that allow users to supply
data towards an applica7on endpoint
</form>

HTML forms
We provide one text ﬁeld per URL parameter, as well as a submit
bu3on
<input type="text" name="name">
<input type="text" name="surname">
<button type="submit">Get your greeting!</button>
</form>

HTML forms
Since we want values to be sent as part of the query string, we
specify GET as the HTTP method
<form action="..." method="GET">
</form>

HTML forms
Finally, we provide the endpoint where to send the parameters;
intui6vely we would like to do the following
<form action="/custom-greeting" method="GET">
</form>

HTML forms
Since a single Web container may host several Web applica4ons,
the correct endpoint is /webapp/custom-greeting1
<form action="/webapp/custom-greeting" method="GET">
</form>
1
Where webapp is the name of our Web applica4on

HTML forms
However, we would much prefer not to hard-code the name of the
Web applica7on

The <spring:url> tag
When using JSP as view technology, we can take advantage of the
<spring:url> tag
<spring:url value="/custom-greeting" var="customGreeting"/>

Given an URL, <spring:url> generates the corresponding
context-aware URL, which is then saved into a page variable

That is, links of the form /endpoint are automa2cally
transformed into links of the form /webapp/endpoint
/endpoint → /webapp/endpoint

HTML forms
The ﬁnal HTML form thus reads
<form action="${customGreeting}" method="GET">
</form>

The Spring tag library
The <spring:url> tag is part of the Spring tag library, which is
in turn part of Spring MVC

The Spring tag library
The Spring tag library can be imported into a JSP page by means of
the taglib direc8ve2
<%@ taglib prefix="spring"
uri="http://www.springframework.org/tags" %>
2
Remember that the taglib direc.ve does not actually load anything, we s.ll need to deploy the Spring tag library
together with the applica.on

Request parameters
• The HTTP en(ty body

En#ty body
The en&ty body is an op#onal part of HTTP messages
HTTP message
+----------------------------+
| Start line |
+----------------------------+
| |
| Headers |
| |
+----------------------------+
| |
| Entity body |
| |
+----------------------------+

En#ty body
Unlike the start line and the headers, the body can contain text or
binary data
HTTP message
+----------------------------+
| Start line |
+----------------------------+
| |
| Headers |
| |
+----------------------------+
| |
| Entity body |
| |
+----------------------------+

En#ty body
While any HTTP request is allowed to contain a body, some
servers will refuse to, e.g., process a GET request with a body3
3
One prominent example is Google (see references)

POST
The POST verb is among the HTTP verbs that explicitly admit the
presence of an en5ty body
HTTP message
+--------------------------------+
| POST /custom-greeting HTTP/1.1 |
+--------------------------------+
| |
| Content-Type: ... |
| |
+--------------------------------+
| |
| Entity body |
| |
+--------------------------------+

POST
As a ma&er of fact, the POST method is speciﬁcally designed to
send input data to the server

POSTing our gree-ng
+--------------------------------------------------+
| POST /webapp/custom-greeting HTTP/1.1 |
+--------------------------------------------------+
| User-Agent: ... |
| Content-Type: application/x-www-form-urlencoded |
+--------------------------------------------------+
| name=Jon&surname=Snow |
| |
+--------------------------------------------------+

HTML form
As before, we can use an HTML form to issue a POST request
<form action="${customGreeting}" method="POST">
<input type="text" name="name"/>
<input type="text" name="surname"/>
</form>

HTML form
Since we want our parameters to be transferred as part of the
en4ty body, we specify POST as the HTTP method
<form action="${customGreeting}" method="POST">
<input type="text" name="name"/>
<input type="text" name="surname"/>
</form>

How can we decide between GET and POST requests?

"...the GET and HEAD methods SHOULD NOT have the signiﬁcance of
taking an ac?on other than retrieval. These methods ought to be
considered "safe"."
(RFC 2616)

"This allows user agents to represent other methods, such as POST,
PUT and DELETE, in a special way, so that the user is made aware of
the fact that a possibly unsafe ac/on is being requested."
(RFC 2616)

"The important dis0nc0on here is that the user did not request the
side-eﬀects, so therefore cannot be held accountable for them."
(RFC 2616)

Unsafe ac)ons
The user is accountable for the POST requests she executes, as
they represent unsafe ac-ons on the Web applica:on

Unsafe ac)ons
Unsafe ac)ons may alter the state of the Web applica)on. For
instance, causing external informa)on sent as form data to be
stored

Accountability
That’s why the browser informs us when we try to send again a
HTTP POST request

HTML form vs. Web apps
HTML forms give users a place where to enter data

Text parameters
The browser sends the data up to the server as a list of name-value
pairs
+--------------------------------------------------+
+--------------------------------------------------+
| User-Agent: ... |
+--------------------------------------------------+
| |
+--------------------------------------------------+

Text parameters
Everything is going to be transferred to the Web app as text
+--------------------------------------------------+
+--------------------------------------------------+
| User-Agent: ... |
+--------------------------------------------------+
| |
+--------------------------------------------------+

But, what if...
• A field has to be interpreted as something different than a
String (e.g., as a Date)?
• The user forgets to provide a mandatory field? does she have to
re-type everything from scratch?
• We want to check that a field respects a given paDern?

But, what if...
• We need to perform data conversion?
• We need to perform data buﬀering?
• We need to perform data valida2on?

HTTP/HTML does not provide a component that can buﬀer,
validate4
and convert inputs coming from a form
4
Here, we are not considering HTML5 Constraint Valida8on API

When trying to solve these issues, HTML and HTTP are of no use
to us

This is how HTTP and HTML work, Web apps cannot control this

The "Sign-up" example
Let us assume that our Web applica2on requires the user to sign up
for a new account

The "Sign-up" example
To this end, we introduce:
• An annotated controller named AccountController
• A registra1on page

AccountController
@Controller
public class AccountController {
@RequestMapping("/account")
public String addAccount(...) { ... }
}

Registra)on form
<spring:url value="/account" var="account"/>
<form action="${account}" method="POST">
Name: <input type="text" name="name"/> <br/>
Surname: <input type="text" name="surname"/> <br/>
Email: <input type="text" name="email"/> <br/>
Birthday: <input type="text" name="birthday"/> <br/>
<button type="submit">Sign-up</button>
</form>

The Account bean
Once we get the data, we may want to store them in a JavaBean
public class Account {
private String name;
private String surname;
private String email;
private Date birthday;
// getters and setters
}

The Account bean
Which is the best way of moving from the request parameters to
the corresponding Account object?
+------------------------------------------------+
| POST /webapp/account HTTP/1.1 | public class Account {
+------------------------------------------------+
| Host: myserver.com | private String name;
| User-Agent: ... | private String surname;
| Content-Type: application/x-www-form-urlencoded| private String email;
+------------------------------------------------+ +-----> private Date birthday;
| name=Jon& |
| surname=Snow& | // getters and setters
| birthday=10-1-1956 | }
+------------------------------------------------+

The naïve solu-on
We could try to get each single request parameter individually
public String addAccount(@RequestParam("name") String name,
@RequestParam("email") String email,
@RequestParam("birthday") Date birthday,
Model model) {
// we manually populate the Account object with
// the data coming from the user
Account a = new Account();
a.setName(name);
...
}

Method parameters in OOP
“The ideal number of arguments for a func5on is zero. Next comes one,
followed closely by two. Three arguments should be avoided where
possible. More than three requires very special jus5ﬁca5on - and then
shouldn’t be used anyway.”
(B. Mar(n)

The naïve solu-on
By doing so, we eﬀec/vely clu$ered the handler method signature
public String addAccount(@RequestParam("name") String name,
@RequestParam("email") String email,
@RequestParam("birthday") Date birthday,
Model model) {
Account a = new Account();
a.setName(name);
...
}

Data binding
Wouldn’t it be great if data coming from the form could be
automa&cally bound to an Account object?
+------------------------------------------------+
| POST /webapp/account HTTP/1.1 | public class Account {
+------------------------------------------------+
| Host: myserver.com | private String name;
| User-Agent: ... | private String surname;
| Content-Type: application/x-www-form-urlencoded| private String email;
+------------------------------------------------+ +-----> private Date birthday;
| name=Jon& |
| surname=Snow& | // getters and setters
| birthday=10-1-1956 | }
+------------------------------------------------+

Data binding
Data binding is the process of binding the request parameters to a
so called form bean
}

Data binding
The form bean is also called the form-backing bean, the form
object or the command object
public class Account { ... }

Data binding
It turns out that all we need to do is to declare an Account object
as a method parameter
public String addAccount(Account account) {
// account will be automatically populated
// with the request parameters
}

Data binding
The following sequence of opera3ons occurs:
• A new form bean is instan(ated
• The form bean is added to the model
• The form bean is populated from the request parameters

The form bean is a model a0ribute
The account form bean will be automa&cally added to the model
Model
+----------------+
| |
| account |
HTTP +-------------------+ +----------------+ +--------------------+
request | | | |
+--------> DispatcherServlet +----------------------> AccountController |
| | | |
+-------------------+ +--------------------+

Hence, views can access and render the form bean content
Model Model
+--------------+ +--------------+
| | | |
| account | | account |
+----------+ +--------------+ +-------------------+ +--------------+ +--------------------+
| | | | | |
| View <--------------------+ DispatcherServlet <--------------------+ AccountController |
| | | | | |
+----------+ +-------------------+ +--------------------+

<html>
<head>
<title>Thanks</title>
</head>
<body>
Hi, ${account.name} ${account.surname}.
You have successfully registered. <br/>
</body>
</html>

Default values
Assume that we want to ask the user for the permission of sending
marke&ng e-mails

Default values
To this end, we add a marketingOk property in the Account
form bean
private boolean marketingOk;
}

Default values
By default, we would like the marketingOk property to be true
private boolean marketingOk = true;
}

Prepopula)ng Account
As a ma&er of fact, we are prepopula(ng the Account bean
}

Showing prepopulated data
We want the registra-on page to use proper-es coming from a
prepopulated Account bean
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | | +--------------+
| +----------------------+ | | |
| <----------+ Account bean |
| +----------------------+ | | |
| Date: | | | +--------------+
| +----------------------+ |
| |
| +-+ |
| |✓| Please send me product updates |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Recall that we can send data to the view through the model object
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | | +--------------+
| +----------------------+ | | |
| <----------+ Account bean |
| +----------------------+ | | |
| Date: | | | +--------------+
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

What if we let the AccountController return a prepopulated
form bean as part of the model?
Model Model
+--------------+ +--------------+
| | | |
+----------+ +--------------+ +-------------------+ +--------------+ +--------------------+
| | | | | |
| | | | | |
+----------+ +-------------------+ +--------------------+

AccountController
@Controller
@RequestMapping(value="/account/new", method=RequestMethod.GET)
public String getEmptyAccount(Model model) {
model.addAttribute(new Account());
return "account/new";
}
@RequestMapping(value="/account/new", method=RequestMethod.POST)
public String addAccount(Account account) { ... }
}

Data binding-aware forms
Once the prepopulated Account object is available in the view, we
need to bind its content to the Web form
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | | +--------------+
| +----------------------+ | | |
| <----------+ Account bean |
| +----------------------+ | | |
| Date: | | | +--------------+
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Spring form tag library
To deal with prepopulated form beans, Spring provides a set of
data binding-aware tags

The revised registra-on form
<form:form modelAttribute="account">
Name: <form:input path="name"/> <br/>
Surname: <form:input path="surname"/> <br/>
Email: <form:input path="email"/> <br/>
Birthday: <form:input path="birthday"/> <br/>
<form:checkbox path="marketingOk"/>
Please send me product updates via e-mail <br/>
<button type="submit">Sign-up<button/>
</form:form>

Form tags vs. HTML tags
┌───────────────────────────────────┬───────────────────────────┐
│ Spring form tag library │ HTML │
├───────────────────────────────────┼───────────────────────────┤
│ <form:form> │ <form> │
├───────────────────────────────────┼───────────────────────────┤
│ <input:text> │ <input type="text"> │
├───────────────────────────────────┼───────────────────────────┤
│ <input:password> │ <input type="password"> │
├───────────────────────────────────┼───────────────────────────┤
│ <input:checkbox> │ <input type="checkbox"> │
└───────────────────────────────────┴───────────────────────────┘

Spring form tags
The <form:input>, <form:password> and
<form:checkbox> tags are data-binding versions of the
corresponding HTML elements

Spring form tags
The tag library does not provide anything for submit bu(ons, as
there is nothing to bind to
<button type="submit">Sign-up<button/>

Spring form tag library
To use the tags from the form library, the following direc7ve needs
to be added at the top of the JSP page:
<%@ taglib prefix=”form"
uri="http://www.springframework.org/tags/form" %>

Users make mistakes
No ma&er how intui/ve the registra/on form, users will
accidentally ﬁll it out with invalid informa,on
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Users make mistakes
When this happens, we want to explain the error in nontechnical
language and help the users to overcome it
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| | | Please send me product updates |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Data valida)on
To detect user’s errors, we need to validate the form data that are
encapsulated in the form bean
}

Data valida)on
Example: the email property should respect the pa/ern
username@provider.tld
}

Bean Valida*on API
The Bean Valida*on API (JSR-303) is a speciﬁca3on that deﬁnes a
metadata model and API for JavaBean valida3on

Bean Valida*on API
Using this API, it is possible to annotate bean proper4es with
declara*ve valida*on constraints
• @NotNull, @Pattern, @Size

Constraining Account
@Pattern(regexp="^[A-Z]{1}[a-z]+$")
@Size(min=2, max=50)
@NotNull
@Email
@NotNull
}

We impose name and surname to start with a capital le2er and
have at least one addi4onal lowercase le2er
}

We impose email to respect the username@provider.tld
pa.ern
@NotNull @Email
}

Hibernate Validator
As with any other Java Enterprise Edi3on API, the standard deﬁnes
only the API speciﬁca,on

Hibernate Validator
We are going to use Hibernate Validator, which is the reference
implementa5on of the JSR-303 speciﬁca5on
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.1.3.Final</version>
</dependency>

Custom annota*ons
Along with the standard constraints, Hibernate Validator provides
some custom annota*ons (e.g., @Email)
@Email
}

Custom annota*ons
Remember: those annota)ons are Hibernate-speciﬁc and they will
not work with any other JSR-303 implementa)on
@Email
}

Valida&ng account
Valida&on is achieved through the @Valid annota&on
@RequestMapping(...)
public String addAccount(@Valid Account account) { ... }

Valida&ng account
The @Valid annota)on causes the account object to be ﬁrst
validated and then added to the model
public String addAccount(@Valid Account account) { ... }

Valida&ng account
The handler method may ask for a BindingResult object, which
represent th result of the valida9on process
public String addAccount(@Valid Account account,
BindingResult bindingResult) { ... }

Valida&ng account
We can then inspect the bindingResult object for possible
valida&on errors
BindingResult bindingResult) {
if (bindingResult.hasErrors()) return "account/new";
...
}

Data buﬀering
Since the account bean is part of the model, it will be sent back
to the view even in case of errors
Model Model
+--------------+ +--------------+
| | | |
+----------+ +--------------+ +-------------------+ +--------------+ +--------------------+
| | | | | |
| | | | | |
+----------+ +-------------------+ +--------------------+

Data buﬀering
Hence, the user is not forced to re-enter the data from scratch
when asked to correct her mistakes
+--------------------------------------+
| |
| +----------------------+ |
| Name: | Jon | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | 1234 | |
| +----------------------+ |
| |
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Data buﬀering
Hence, the user can correct her mistakes, while keeping the correct
data untouched
+--------------------------------------+
| |
| +----------------------+ |
| Name: | Jon | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | 1234 | |
| +----------------------+ |
| |
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Error messages
Even if we returned the ini.al form, we s.ll have to inform the user
on the reason why the data have been rejected
+--------------------------------------+
| |
| +----------------------+ |
| Name: | Jon | |
| +----------------------+ |
| |
| +----------------------+ | "Hey user, the
| Surname: | snow <----------+ surname should
| +----------------------+ | start with a
| | capital letter"
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

Error messages
To this end, the BindingResult object is automa&cally inserted
into the model and sent back to the view
Model Model
+--------------+ +--------------+
+--------------+ +--------------+
|bindingResult | |bindingResult |
+----------+ +--------------+ +-------------------+ +--------------+ +--------------------+
| | | | | |
| | | | | |
+----------+ +-------------------+ +--------------------+

<form:errors>
Spring MVC provides the <form:errors> tag as part of the
Spring’s form tag library
<form:errors path="name"/>

<form:errors>
The <form:errors> tag renders in HTML error messages taken
from the BindingResult object

<form:errors>
<form:form modelAttribute="account">
Name: <form:input path="name"/> <form:errors path="name"/> <br/>
Surname: <form:input path="surname"/> <form:errors path="surname"/> <br/>
Email: <form:input path="email"/> <form:errors path="email"/> <br/>
...
</form:form>

User-centric error messages
Unfortunately, most of the default Hibernate validator error
messages are not par8cularly user-centric

User-centric error messages
For instance, @Pattern's default message shows a reference to
the regular expression to be respected

Message interpola.on
Message interpola.on is the process of crea-ng error messages
for violated Bean Valida-on constraints
+--------------------------------------+
| |
| +----------------------+ |
| Name: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Surname: | | |
| +----------------------+ |
| |
| +----------------------+ |
| Date: | | |
| +----------------------+ |
| |
| +-+ |
| +-+ |
| +-------------+ |
| | Sign-up! | |
| +-------------+ |
+--------------------------------------+

We can deﬁne the message descriptor of each property through
the message a4ribute
@NotNull(message = "the email address cannot be empty")
@Email(message = "please provide a valid e-mail address")
}

The problem with message a1ributes is that we are hard-coding
the error messages
@NotNull(message = "the email address cannot be empty")
@Email(message = "please provide a valid e-mail address")
}

What if we want the messages to change according to, e.g., the user’s
locale?

Resource bundle
A be%er alterna+ve is to store the error messages in a separate ﬁle,
called the resource bundle

Resource bundle
By doing so, error messages can be updated independently of the
source code (and vice versa)

Resource bundle
We may devise the following resource bundle:
NotBlank.account.email=the email address cannot be empty
Email.account.email=please provide a valid e-mail address
NotNull.account.birthday=The date cannot be empty

Resource bundle
Spring’s conven.on dictates the following syntax for messages:
[ConstraintName].[ClassName].[FieldName]=[Message]

MessageSource
If we decide to externalize messages from the code, we need a
source from which to get the messages, i.e., a MessageSource

MessageSource
Speciﬁcally, in order to load messages from a resource bundle, we
need a ReloadableResourceBundleMessageSource bean

Adding a MessageSource
We therefore change frontcontroller-servlet.xml in order
to have the Spring DI Container load the MessageSource5
<bean id="messageSource"
class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basename" value="classpath:validationMessages" />
</bean>
5
Remember: the MessageSource bean must have the id equal to messageSource

Using message codes
We can now specify the message code in lieu of the message itself
@NotBlank(message = "{NotBlank.account.email}")
@Email(message = "{Email.account.email}")
}

What if the user presses refresh on the browser?
+--------------+ +--------------+
| +------- POST --------> |
| <------ 200 OK -------+ |
+--------------+ +--------------+

Since refreshing means resending the latest HTTP request, it will
cause the HTTP POST to be resubmi+ed
+--------------+ +--------------+
+-------> +------- POST --------> |
Refresh | | Browser | | Web app |
+-------+ <------ 200 OK -------+ |
+--------------+ +--------------+

Given the unsafe nature of POST, resending the latest POST
request may lead to unwanted results
+--------------+ +--------------+
+-------> +------- POST --------> |
+-------+ <------ 200 OK -------+ |
+--------------+ +--------------+

The PRG pa*ern
The Post/Redirect/Get (PRG) pa/ern solves the duplicate
submission problem

The PRG pa*ern
According to the PRG pa2ern, the Web app should not immediately
return the outcome of the POST opera?ons
+--------------+ +--------------+
| +------- POST --------> |
| <------ 200 OK -------+ |
+--------------+ +--------------+

The PRG pa*ern
Instead, the Web applica1on should answer with a redirect
response
+--------------+ +--------------+
| +------- POST --------> |
| <--- 3xx REDIRECT ----+ |
+--------------+ +--------------+

The PRG pa*ern
This causes the client to automa/cally issue a new GET request, to
which the Web app ﬁnally answers with the actual content
+--------------+ +--------------+
| +------- GET -------> |
| <------ 200 OK -------+ |
+--------------+ +--------------+

The PRG pa*ern
Thus, if the user refreshes the page, the GET request will be send,
instead of the original HTTP POST
+--------------+ +--------------+
+-------> +------- GET -------> |
+-------+ <------ 200 OK -------+ |
+--------------+ +--------------+

Redirec'ng
In order to force a redirect, it is suﬃcient to return the redirect
URL preﬁxed with the label redirect:
if (bindingResult.hasErrors()) return "account/edit";
service.saveAccount(account);
return "redirect:/account/thanks";
}

Redirec'ng
The redirect: preﬁx is used as a special indica+on that a
redirect is needed
}

Redirec'ng
Note that what follows redirect: is used as the redirect URL
}

Redirec'ng
That is, /account/thanks has to be intended as
http://myserver.com/webapp/account/thanks
}

View controllers
We need to associate a handler method with /account/thanks
@Controller
@RequestMapping("/thanks")
public String getThanks() { return "thanks"; }
}

View controllers
The sole responsibility of such a handler method would be to
return the /account/thanks view name
@RequestMapping("/thanks")
public String getThanks() { return "thanks"; }

View controllers
Star%ng from Spring 3, it is possible to declara've set up
controllers whose unique responsibility is to return a view name

View controllers
The following declares in frontcontroller-servlet.xml a
controller capable of answering to /account/thanks
<mvc:view-controller path="/account/thanks”
view-name="account/thanks"/>

Model life)me
As the model contains the data to be rendered by the view, its
life6me is limited by the request/response lifecycle

Model life)me
In other words, a new model object is created for each request
that hits DispatcherServlet
+-------+
HTTP | Model |
request +---------------------+ +-------+ +--------------+
| | | |
+-------> DispatcherServlet +-------------> Controller |
| | | |
+---------------------+ +--------------+

PRG pa'ern vs. model a'ributes
A redirect creates a new request, hence causing the model
a3ributes to be discarded
+--------------+ +--------------+
| +------- POST --------> |
| <--- 3xx REDIRECT ----+ |
+--------------+ +--------------+

What if we want to retain some model a1ributes?

The ﬂash scope
A possible solu+on is store a0ributes of interest in the ﬂash scope

The ﬂash scope
The ﬂash scope works similarly to the session scope
+-----+ Request +-----+
| +----------------> | +--+-------+-+
| | | | | |
| | Response | | | F |
| <----------------+ | | l |
| B | | W | | a |
| r | Request | e | S | s |
| o +----------------> b | e | h |
| w | | | s | |
| s | Response | a | s | |
| e <----------------+ p +------ i | ------v--
| r | | p | o |
| | Request | | n |
| +----------------> | |
| | | | |
| | Response | | |
| <----------------+ +---------v---
+-----+ +-----+

The flash scope
The difference is that flash a&ributes are kept solely for the
subsequent request
+-----+ Request +-----+
| +----------------> | +--+-------+-+
| | | | | |
| <----------------+ | | l |
| B | | W | | a |
| o +----------------> b | e | h |
| w | | | s | |
| e <----------------+ p +------ i | ------v--
| r | | p | o |
| | Request | | n |
| +----------------> | |
| | | | |
| | Response | | |
| <----------------+ +---------v---
+-----+ +-----+

The ﬂash scope
Flash a'ributes are stored before the redirect and made available
as model a'ributes a2er the redirect
+-----+ Request +-----+
| +----------------> | +--+-------+-+
| | | | | |
| <----------------+ | | l |
| B | | W | | a |
| o +----------------> b | e | h |
| w | | | s | |
| e <----------------+ p +------ i | ------v--
| r | | p | o |
| | Request | | n |
| +----------------> | |
| | | | |
| | Response | | |
| <----------------+ +---------v---
+-----+ +-----+

RedirectAttributes
A handler method can declare an argument of type
RedirectAttributes...
BindingResult bindingResult,
RedirectAttributes redirectAttributes) {...}

RedirectAttributes
...and use its addFlashAttribute() method to add a.ributes in
the ﬂash scope
BindingResult bindingResult,
RedirectAttributes redirectAttributes) {
if (bindingResult.hasErrors()) return "account/new";
redirectAttributes.addFlashAttribute("account", account);
return ”redirect:/account/thanks”;
}

The "Thank you" page
account is accessible in the view, since it has been automa2cally
inserted into the next request model
<html>
<head>
<title>Thanks</title>
</head>
<body>
Hi, ${account.name} ${account.surname}.
You have been successfully registered. <br/>
</body>
</html>

Form beans
Form beans are versa&le objects, as they play diﬀerent roles at the
same 1me
• Data binder
• Data buﬀer
• Data validator

Data binder
Developers can work with a trusty POJO and leave all the HTML/
HTTP issues to the framework
• Binding
• Coercion

Data buﬀer
The form bean is not the des0na0on of the input, but a buﬀer that
preserves the input un0l it can be validated and commi7ed to the
service layer

Data validator
Many ﬁelds must be the correct type before they can be processed
by the business logic

References
• Stackoverﬂow, GET vs. POST does it really ma;er?
• Stackoverﬂow, HTTP GET with request body
• R. Fielding, Introductory REST ArHcle
• IETF, Hypertext Transfer Protocol – HTTP/1.1 (RFC 2616)
• SpringSource, Spring Framework Reference

References
• SpringSource, Java-doc APIs
• Wikipedia, Post/Redirect/Get
• Wikipedia, Bean Valida@on
• Hibernate, Hibernate Validator reference guide

References
• Craig Walls, Spring in Ac1on (3rd ed.), Manning Publica1ons
• Willie Wheeler, Spring in Prac1ce, Manning Publica1ons
• T. N. Husted et al., Struts 1 In Ac1on, Manning Publica1ons

Spring MVC - Web Forms

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to Spring MVC - Web Forms (20)

More from Ilio Catallo (19)

Recently uploaded (20)

Spring MVC - Web Forms