First thing, let's slightly change the controller, so that a empty spitter object is passed to the register view when we GET it.
@RequestMapping(value = "/register", method = GET) public String showRegistrationForm(Model model) { model.addAttribute(new Spitter()); return "registerForm"; }Spring sees we want to push on the model a new Spitter. By default it names it as the class, first letter lowercase, "spitter".
The registerForm JSP now changes to use it. Our job is made simpler by using a Spring tag library, form, that provides a nice support for manage HTML forms. I associated the "sf" prefix to it, and I am going to use only a few of the many functionality it makes available.
I have rewritten the form in this way:
<sf:form method="POST" commandName="spitter"> <!-- 1 --> First Name: <sf:input path="firstName" /> <!-- 2 --> <sf:errors path="firstName" /> <!-- 3 --> <br /> Last Name: <sf:input path="lastName" /> <sf:errors path="lastName" /> <br /> Email: <sf:input path="email" /> <sf:errors path="email" /> <br /> Username: <sf:input path="username" /> <sf:errors path="username" /> <br /> Password: <sf:password path="password" /> <!-- 4 --> <sf:errors path="password" /> <br /> <input type="submit" value="Register" /> </sf:form>1. Instead of using the standard HTML form, I used the Spring Form version. The attribute (in XML sense) commandName shows the name of the attribute that has to be used to populate the fields in the form. If we arrive here from GETting "/register", spitter would be empty. If we arrive here POSTing "/register", after detecting validation errors, spitter would contain the fields as entered by the user.
2. The Spring Form input tag uses its attribute path to select the field from the commandName object that is associated to it. In this case, firstName.
3. The Spring Form errors tag is just like a plain text label, but linked to the Spring Validation Errors object generated by the validation process - when available. Again, its path attribute refers to the specific field in it.
4. The Spring Form password tag is a sort of Spring aware HTML input-password tag.
And with this, we could claim that the job is done. However, we would like to have a better control on the messages showed to the user in case of errors. That is very easily done, as it is providing localized version of those messages.
To do that I have created a file named ValidationMessages.properties in the src/main/resources folder, and its ValidationMessages_it.properties counterpart for its Italian version. Each line represents an error message. For instance:
firstName.size=First name must be between {min} and {max} characters long.Notice the words included in curly braces. These are variables that Spring will resolve when creating the actual message.
I am going to use the custom messages in the Spitter class:
@Size(min = 2, max = 30, message="{firstName.size}") private String firstName;Now, if I push the Register button without entering anything, I get:
(Notice that there is no error message for the empty email address - no email is considered a valid alternative)
In a browser localized for Italy, I have this alternative result:
Reference: Rendering web views, from Spring in Action, Fourth Edition by Craig Walls. Chapter six.
I have pushed the project changes to GitHub.
No comments:
Post a Comment