To start creating the project, press CTRL + N to browse the menu wizard of the IDE. This menu wizard contains all the types of project modules you'll need to start a project. The menu wizard should look similar to the following screenshot:

Once on the menu, browse the Web option and choose Dynamic Web Project. Afterwards, just follow the series of instructions to create the chosen project module until you reached the last menu wizard, which looks like the following figure:

This last instruction (Web Module panel) will auto-generate the deployment descriptor (web.xml) of the project. Always click on the Generate web-xml deployment descriptor checkbox option. The deployment descriptor is an XML file that must reside inside the /WEB-INF/ folder of all JEE projects. This file describes how a component, module or application can be deployed. A JEE project must always be in the web.xml file otherwise the project will be defective.

The next major step is to convert the newly created dynamic web project to a Maven one. To complete the conversion, right-click on the project and navigate to the Configure | Convert Maven Project command set, as shown in the following image:

It is always best for the developer to study the directory structure of the project folder created before the actual implementation starts. The following is the directory structure of the Maven project after the conversion:

The project directories are just like the usual Eclipse dynamic web project without the pom.xml file.

Another method of creating a Spring MVC web project is by creating a Maven project from the start. Be sure to install the Maven 3.2 plugin in STS Eclipse. Browse the menu wizard again, and locate the Maven option. Click on the Maven Project to generate a new Maven project.

After clicking this option, a wizard will pop up, asking if an archetype is needed or not to create the Maven project. An archetype is a Maven plugin whose main objective is to create a project structure as per its template. To start quickly, choose an archetype plugin to create a simple Java application here. It is recommended to create the project using the archetype maven-archetype-webapp. However, skipping the archetype selection can still be a valid option.

After you've done this, proceed with the Select an Archetype window shown in the following screenshot. Locate maven-archetype-webapp then proceed with the last process.

The selection of the Archetype maven-archetype-webapp will require the input of Maven parameters before ending the whole process with a new Maven project:

The required parameters for the Maven group or project are as follows:

For more information on Maven plugin and configuration details, visit the documentation and samples on the site http://maven.apache.org/.

After providing the Maven parameters, the project source folder structure will be similar to the following screenshot:

All projects are deployed in the Tomcat 7 server using the Maven plugin installed in STS. Follow the steps below to properly deploy the Spring MVC projects.

We start creating the Spring MVC project by configuring the DispatcherServlet API class. The Spring MVC framework has the DispatcherServlet at the center of all request and response transactions as illustrated in the preceding figure.

From the point of view of the PWP, the DispatcherServlet starts receiving requests when the user starts running pages on the web browser. The processes are enumerated as follows:

The PWP has the following configuration for the DispatcherServlet:

<?xml version="1.0" encoding="UTF-8"?> 
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns="http://java.sun.com/xml/ns/javaee"  
  xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
  http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"    id="WebApp_ID"  
  version="3.0"> 
  <display-name>ChapterOne</display-name> 
 
  <!-- Declare Spring DispatcherServlet --> 
  <servlet> 
    <servlet-name>pwp</servlet-name> 
    <servlet-class> 
      org.springframework.web.servlet.DispatcherServlet 
    </servlet-class> 
  </servlet> 
  <servlet-mapping> 
    <servlet-name>pwp</servlet-name> 
    <url-pattern>*.html</url-pattern> 
  </servlet-mapping> 
 
  <!-- Spring accepted extension declared here below --> 
  <mime-mapping> 
    <extension>png</extension> 
    <mime-type>image/png</mime-type> 
  </mime-mapping> 
 
</web-app> 

Just like any typical JEE servlet, the tags <servlet> and <servlet-mapping> are used to declare the dispatcher servlet DispatcherServlet:

<servlet> 
  <servlet-name>pwp</servlet-name> 
  <servlet-class> 
    org.springframework.web.servlet.DispatcherServlet 
  </servlet-class> 
</servlet> 
<servlet-mapping> 
  <servlet-name>pwp</servlet-name> 
  <url-pattern>*.html</url-pattern> 
</servlet-mapping> 

The <servlet-name> tag does not only stand for the name of the servlet, but is also related to the name of a Spring container which will be tackled later. The  <url-pattern> indicates which type of valid URLs will be recognized by the DispatcherServlet during request-response transactions. In our preceding configuration, it shows that all URL must have an extension .html in order for the requests to be processed by the servlet.

When it comes to file types, the DispatcherServlet only considers content types declared with the <mime-mapping> tag. In this project, we only have PNG files needed by the portal.

  <mime-mapping> 
    <extension>png</extension> 
    <mime-type>image/png</mime-type> 
  </mime-mapping> 

Using our STS IDE, the ApplicationContext (applicationContext.xml) can be created using the Spring Eclipse plugin. Following is the menu wizard showing the plugin for the Spring Framework module:

On the wizard, click on the Spring Bean Configuration File option which will guide you to the next instruction panel. This is the selection of the XSD namespaces needed by the applicationContext.xml for the Spring components.

After choosing the necessary XSD namespaces needed for bean injections and configurations, the PWP's XML-based container will look like the following configuration:

<?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:aop="http://www.springframework.org/schema/aop" 
  xmlns:context="http://www.springframework.org/schema/context" 
  xmlns:oxm="http://www.springframework.org/schema/oxm"
  xmlns:tx="http://www.springframework.org/schema/tx" 
  xmlns:mvc="http://www.springframework.org/schema/mvc" 
  xsi:schemaLocation="http://www.springframework.org/schema/aop    http://www.springframework.org/schema/aop/spring-aop-4.1.xsd 
http://www.springframework.org/schema/oxm      http://www.springframework.org/schema/oxm/spring-oxm-4.1.xsd 
http://www.springframework.org/schema/beans      http://www.springframework.org/schema/beans/spring-beans-4.1.xsd 
http://www.springframework.org/schema/tx      http://www.springframework.org/schema/tx/spring-tx-4.1.xsd 
http://www.springframework.org/schema/context      http://www.springframework.org/schema/context/spring-context-4.1.xsd 
http://www.springframework.org/schema/mvc      http://www.springframework.org/schema/mvc/spring-mvc-4.1.xsd"> 
 
    // all beans injected here 
</beans> 

The applicationContext.xml is loaded, accessed, and read by the DispatcherServlet. The convention used so the DispatcherServlet recognizes the container is to name our applicationContext.xml file using the format dispatcherServletName-servlet.xml, wherein the dispatcherServletName is the name indicated by the <servlet-name> tag:

<servlet> 
  <servlet-name>pwp</servlet-name> 
  <servlet-class> 
    org.springframework.web.servlet.DispatcherServlet 
  </servlet-class> 
</servlet> 

Thus, the PWP's applicationContext.xml file is named pwp-servlet.xml. The default filename of an XML-based Spring container must always follow the convention [dispatcher-servlet-name]-servlet.xml.

The other type of implementation of the Spring MVC container is through the JavaConfig classes. In the JavaConfig method, every component tag has its respective annotation equivalent. Following is the equivalent configuration of the preceding XML-based setup.

package org.packt.personal.web.portal.config; 
import org.springframework.context.annotation.Configuration; 
 
@Configuration 
public class PersonalWebPortalConfig {   } 

The @Configuration annotation indicates that this class contains one or more bean methods (usually getters) annotated with @Bean that returns manageable beans of the container. Some references call this class a configurator class.

The two implementations are incomparable, but some projects mix them. XML-based Spring MVC containers become cumbersome when the files get larger, while annotation-based ones can be managed since they are just POJO-based. JavaConfig is a better approach when it comes to using a rapid application development (RAD) strategy. The reason for this is that when the number of components in the project increases, JavaConfig can only just manage the dependencies among beans through autowiring, which the XML cannot impose since the codes are decoupled from the dependency injection process. Debugging is also easy, since bug detection will be done during compilation, unlike in the XML-style where errors will be detected right after the deployment or execution of the application.

On the issue of mixing them, the project must choose which configuration is going to be bootstrapped by the container. If it is the JavaConfig, it must use the @ImportResource to load all the injected beans from the XML:

@Configuration 
@ImportResource("classpath:pws-servlet.xml") 
public class PersonalWebPortalConfig {   } 

If the XML-based configuration is used instead, the XML must use <context:component-scan="org.packt.personal.web.portal"/> to locate the @Configuration class and load all @Bean autowired in it.

In general, the XML-based method is preferred, whenever an Enterprise application is being developed, because XML is still widely used in systems integration techniques. Some legacy systems also preferred the XML-based container.

The PWP project has an XML-based and JavaConfig-based container.

The PWP project will consist of four content pages each having its own use request transaction. Users can update three of the four contents using session handling. In order to implement services to each page, controller class must be created with the stereotype @Controller instead of extending controller base classes or Spring-specific APIs. The home page of PWP has the following controller declaration:

@Controller 
public class IndexController {  } 

Each controller class has more than service or handler methods. Each service method is being mapped to the user's request by the DispatcherServlet. A valid service or handler method must have a @RequestMapping stereotype written on top of the method or function signature. A sample controller with a service method is shown as follows:

@Controller 
public class IndexController { 
 
  @RequestMapping(value="/index", method=RequestMethod.GET) 
  public String getIndex(Model model) { 
    model.addAttribute("greetings",  "Welcome Page"); 
    return "index"; 
  } 
} 

A service method is mapped to at least one URL or path, and has an HTTP method declared. The preceding sample getIndex() is mapped to the /index.html and processes a GET request transaction.

There are actually four general classifications of a controller and these are the following:

        @Controller 
          public class IndexController { 
 
            @RequestMapping(value="/index", 
            method=RequestMethod.GET) 
            public String getIndex() { 
              return "index"; 
            } 
          } 

        @Controller 
          public class IndexController { 
 
            @RequestMapping(value="/index", 
            method=RequestMethod.GET) 
            public ModelAndView getIndex() { 
              Map<String, Object> model = new HashMap<>(); 
              model.put("greetings",  "Welcome Page"); 
              return new ModelAndView("index", "model", model); 
            } 
 
          } 

        @Controller 
          public class IndexController { 
 
            @RequestMapping(value="/index", 
            method=RequestMethod.GET) 
            public String getIndex(Model model) { 
              model.addAttribute("greetings",  "Welcome Page"); 
              return "index"; 
            } 
          } 

        @Controller 
        public class IndexController { 
 
          @RequestMapping(value="/index", 
          method=RequestMethod.GET) 
          public String getIndex(Model model){ 
            model.addAttribute("greetings",  "Welcome Page"); 
            return "index"; 
          } 
 
          @RequestMapping(value="/index_post", 
            method=RequestMethod.POST) 
            public String postIndex(Model model) { 
              model.addAttribute("greetings",  "Welcome Page"); 
              return "index"; 
            } 
        } 

         @Controller 
         @SessionAttributes(value={"statusSess", "homeSess"}) 
         @RequestMapping("/pwp/index_update") 
         public class IndexUpdateController { 
 
         @Autowired 
         private Validator indexValidator; 
 
         @InitBinder("homeForm") 
         public void initBinder(WebDataBinder binder) { 
         binder.setValidator(indexValidator); 
         } 
 
         @RequestMapping(method=RequestMethod.GET) 
 
         public String initForm(Model model) { 
         Home homeForm = new Home(); 
         model.addAttribute("homeForm", homeForm); 
         return "index_update"; 
         } 
 
         @RequestMapping(method=RequestMethod.POST) 
         public String submitForm(Model model, 
         @ModelAttribute("homeForm") 
         @Validated Home homeForm, BindingResult binding) { 
         model.addAttribute("homeForm", homeForm); 
         String returnVal = "index"; 
         if(binding.hasErrors()) { 
         returnVal = "index_update"; 
         } else { 
         model.addAttribute("homeSess", homeForm); 
         model.addAttribute("statusSess", "undefault"); 
         } 
         return returnVal; 
         } 
         }

The PWP controllers

This project utilizes all the preceding controller classification except for multi-action controllers. Following is the finished product of the PWP that highlights the home page. All content pages have an equivalent update transaction for updating their content. The home page, in particular, is invoked through the URL http://localhost:8080/ch01/pwp/index.html where ch01 is the context root. With this URL, DispatcherServlet will look for the controller that has the service method bearing the path /pwp/index. Once the match is found, the service method calls the appropriate view with the data model, if there is one. The final step will be loading the content desired by the user.

A complete home page controller class with the default values of the cone is shown as follows:

package org.packt.personal.web.portal.controller; 
 
import java.util.ArrayList; 
import java.util.Date; 
import java.util.HashMap; 
import java.util.List; 
import java.util.Map; 
 
import org.packt.personal.web.portal.model.form.Home; 
import org.packt.personal.web.portal.model.form.PostMessage; 
// Rest of the code in the sources 
 
@Controller 
@SessionAttributes("posts") 
@RequestMapping("pwp") 
public class IndexController { 
 
  @ModelAttribute("posts") 
  public List<PostMessage> newPosts() { 
    return initPost(); 
  } 
 
  @RequestMapping(value="/index", method=RequestMethod.GET) 
  public String getIndex(Model model,  @ModelAttribute("posts") 
    List<PostMessage> posts, 
    @ModelAttribute("postForm") PostMessage postForm) { 
 
      Home home = new Home(); 
      home.setMessage(initMessage()); 
      home.setQuote(initQuote()); 
      model.addAttribute("home",  home); 
        if(posts == null) posts = newPosts(); 
        if(validatePost(postForm)) { 
          postForm.setDatePosted(new Date()); 
          posts.add(postForm); 
        } 
        model.addAttribute("posts",  posts); 
      return "index"; 
  } 
 
  @RequestMapping(value="/index_redirect", 
    method=RequestMethod.GET) 
  public RedirectView updateIndex() { 
    return new RedirectView("/ch01/pwp/index_update.html"); 
  } 
 
  public String initQuote() { 
    String message = "Twenty years from now you will be more 
      disappointed by the things .......... -Mark Twain"; 
    return message; 
  } 
 
  public String initMessage() { 
    String message = "Having a positive outlook on life is a      crucial part of finding inspiration. In the paragraph above,      ......"; 
    return message; 
  } 
 
  public List<PostMessage> initPost() { 
    List<PostMessage> posts = new ArrayList<>(); 
    PostMessage post = new PostMessage(); 
    post.setSubject("Welcome!"); 
    post.setDatePosted(new Date()); 
    post.setPostedMsg("Hello visitors!Feelfree to post on my 
    portal!"); 
 
    posts.add(post); 
    return posts; 
  } 
 
  public boolean validatePost(PostMessage post) { 
    try { 
      if(post.getSubject().trim().length() == 0 || 
      post.getPostedMsg().trim().length() == 0) { 
        return false; 
      } 
    } 
    catch(Exception e) { 
      return false; 
    } 
    return true; 
  } 
} 

The method getIndex() is responsible for loading the home page initially. The default content for message and content are given by two methods, namely initMessage() and initPost(). The initPost() method initially populates the right navigation panel of the home page where all the posts will be listed. This posting feature will be elaborated on further in the next topics.

Generally, all these default methods are essential to generate the home page when no session data are available to replace this default content.

The update page on the home page will be invoked by clicking the Update button. Each portal has an Update button except for the Reach Out page. After clicking the Update button on the home page, DispatcherServlet will look for the service that has the URL path /pwp/index_redirect. There are two general ways to implement redirection and these are the following:

• Using the RedirectView API: This process of redirection is done through implementation of the handler method that returns org.springframework.web.servlet.view.RedirectView. Following are some snippets that show how to implement redirection.

        @RequestMapping(value="/index_redirect",
                        method=RequestMethod.GET) 
          public RedirectView updateIndex() { 
            return new RedirectView("/ch01/pwp/index_update.html"); 
          } 
 
          @RequestMapping(value="/index_redirect",
                          method=RequestMethod.GET) 
            public String updateIndex() { 
              return (redirect:"/ch01/pwp/index_update.html"); 
            } 

• Using the <c:url> JSTL tag: This process is a direct process of redirection and being configured on the view page.

          <c:url var=indexUpdate" value="/pwp/index_update.html"/> 
          <a href="<c:out value="${indexUpdate }"/>">Update Home</a>  
  

  

After redirection to the update page, the home page has two important pieces of content information that need to be updated, and these are the message and quote portions of the page:

All update pages have validators to check the attributes of the form data. On the home page, users cannot input quotes or messages that are less than 50 and more than 500 alphanumeric characters. Validation and object type checking occurs only if our controllers have form views. A controller that has form and success views is implemented in a different way. Following is a template of a form controller that is used by the PWP project:

package org.packt.personal.web.portal.controller; 
 
import java.util.ArrayList; 
import java.util.Date; 
import java.util.List; 
 
import org.packt.personal.web.portal.converter.AgeConverter; 
import org.packt.personal.web.portal.converter.BirthDateConverter; 
// Rest of the codes in the sources 
@Controller 
@SessionAttributes(value = {"pStatusSess", "personSess"}) 
@RequestMapping("/pwp/personal_update") 
public class PersonalUpdateController { 
 
  @Autowired 
  Validator personalValidator; 
 
  @InitBinder("personForm") 
  public void initBinder(WebDataBinder binder) { 
    binder.setValidator(personalValidator); 
    binder.registerCustomEditor(Integer.class, "biography.age", 
    new AgeConverter()); 
    binder.registerCustomEditor(Integer.class, "education.year", 
    new YearConverter()); 
    binder.registerCustomEditor(Date.class, "biography.birthDate", 
    new BirthDateConverter()); 
  } 
 
  @RequestMapping(method=RequestMethod.GET) 
  public String initForm(Model model) { 
    Biography bio = new Biography(); 
    Education educ = new Education(); 
    Personal personForm = new Personal(); 
    personForm.setBiography(bio); 
    personForm.setEducation(educ); 
    references(model); 
    model.addAttribute("personForm", personForm); 
    return "personal_update"; 
  } 
 
  @RequestMapping(method=RequestMethod.POST) 
  public String submitForm(Model model, 
  @ModelAttribute("personForm") @Validated Personal personForm, 
  BindingResult binding) { 
    model.addAttribute("personForm", personForm); 
    String returnVal = "personal"; 
    if(binding.hasErrors()) { 
      references(model); 
      returnVal = "personal_update"; 
    } else { 
      model.addAttribute("personSess", personForm); 
      model.addAttribute("pStatusSess", "undefault"); 
    } 
    return returnVal; 
 
  } 
 
  public void references(Model model) { 
    List<String> hobbiesList = new ArrayList<String>(); 
    hobbiesList.add("Not Applicable"); 
    hobbiesList.add("Singing"); 
    hobbiesList.add("Painting"); 
    hobbiesList.add("Traveling"); 
    hobbiesList.add("Writing"); 
    hobbiesList.add("Swimming"); 
    model.addAttribute("hobbiesList", hobbiesList); 
    // Rest of the code in sources 
  } 
} 

Although there is no restriction as to what, and how many, handler methods are needed in a typical controller class, a form controller has to maintain having only one @RequestMapping stereotype declared at the class level. The path indicated must be the controller's form view.

The preceding controller has two service operations namely the initForm() and submitForm() methods. The initForm() service is always a GET method, which always initializes the form view. It also binds the form domain object that contains the request data from the user. The submitForm() is a POST service that is executed after form submission. This automatically extracts the validated domain object from the form and transports any model to the result views.

The references() method is used to populate the form components found in the form view. Java Collection Framework (JCF) is used to contain all the data which can be hardcoded or which is from a data store.

The usual exception during form-handling happens when the form-backing object, or the model, is not set to bind with the form view. Whenever the browser calls the initForm(), the following exception will be encountered.

java.lang.IllegalStateException: 
  Neither BindingResult nor plain target object 
    for bean name 'home' available as request attribute 
      at o.s.w.s.s.BindStatus.<init>(BindStatus.java:141) 

In order for submitForm() to access the form-backing object, the @ModelAttribute annotation is needed to be declared in its parameters. An @ModelAttribute local parameter indicates that the argument will be retrieved from the form view. If not present in the form view, the argument must be instantiated first in the initForm(), and bound to the form view. Moreover, Spring MVC throws an exception when errors occur during request binding, by default. That is why in submitForm(), one of the arguments is for BindIngResult where we can extract all errors during the request transaction. The BindingResult argument needs to be positioned right after our form-backing object, which is a rare case when it comes to the @RequestMapping order of arguments.

If this rule is violated, the following exception will be thrown:

java.lang.IllegalStateException:
Errors/BindingResult argument declared without preceding model    attribute 

The Personal Web Portal (PWP) application does not have database connectivity since the main highlight in this chapter are the raw Spring MVC 4 components. Also, it has no Spring security attached to it from the core, so there are no login/logout transaction for the user. All controllers in the PWP use a lot of @ModelAttribute and @SessionAttributes data.

The @ModelAttribute data are actually the same with request attributes. These are objects created from one single request dispatching. Moreover, these data are also called request-scoped data, which means that these data values are only valid within one request-response transaction.

One use of @ModelAttribute is to bind the form domain object to the form view page. On an incoming request transaction, any models with @ModelAttributes are called before any controller handler method. The following initForm() method is one example of this scenario.

@RequestMapping(method=RequestMethod.GET) 
  public String initForm(Model model, 
  @ModelAttribute("profesionalForm") 
  Professional professionalForm) { 
    return "professional_update"; 
  } 
 
@RequestMapping(method=RequestMethod.GET) 
  public String initForm(Model model) { 
    Professional professionalForm = new Professional(); 
 
    model.addAttribute("professionalForm", professionalForm); 
    references(model); 
    return "professional_update"; 
  } 
  public void references(Model model) { 
    List<String> hobbiesList = new ArrayList<String>(); 
    hobbiesList.add("Not Applicable"); 
    hobbiesList.add("Singing"); 
    hobbiesList.add("Painting"); 
    hobbiesList.add("Traveling"); 
    hobbiesList.add("Writing"); 
    hobbiesList.add("Swimming"); 
    model.addAttribute("hobbiesList", hobbiesList); 
 
    List<String> readingsList = new ArrayList<String>(); 
    readingsList.add("Not Applicable"); 
    readingsList.add("Novel"); 
    readingsList.add("Magazine"); 
    readingsList.add("Newspaper"); 
    readingsList.add("Diaries"); 
    model.addAttribute("readingsList", readingsList); 
 
    List<String> educLevelList = new ArrayList<String>(); 
    educLevelList.add("Not Applicable"); 
    educLevelList.add("Doctoral"); 
    educLevelList.add("Masters"); 
    educLevelList.add("College"); 
    educLevelList.add("Vocational"); 
    educLevelList.add("High School"); 
    model.addAttribute("educLevelList", educLevelList); 
  } 

To initialize the @ModelAttribute, it must be injected with an object value just like we have in the PWP project:

@ModelAttribute("greetings") 
  public List<String> getGreetings() { 
    return Greetings.allGreets(); 
  } 

The @SessionAttributes, on the other hand, are used by the controller to declare session objects during session handling. Equally, these attributes are the session attributes in a typical JEE web component. As long as the session is not terminated, session data are always accessible for update and retrieval. Sessions were used in the PWP project to store values for all the dynamic content transactions. Here is a code snippet that shows how to declare, initialize and update values that are @SessionAttributes.

@Controller 
@SessionAttributes("posts") 
@RequestMapping("pwp") 
public class IndexController { 
 
  @ModelAttribute("posts") 
  public List<PostMessage> newPosts() { 
    return initPost(); 
  } 
 
  @RequestMapping(value="/index", method=RequestMethod.GET) 
  public String getIndex(Model model,  @ModelAttribute("posts") 
    List<PostMessage> posts, 
    @ModelAttribute("postForm") PostMessage postForm) { 
 
      Home home = new Home(); 
      home.setMessage(initMessage()); 
      home.setQuote(initQuote()); 
      model.addAttribute("home",  home); 
 
      if(posts == null) posts = newPosts(); 
      if(validatePost(postForm)) { 
        postForm.setDatePosted(new Date()); 
        posts.add(postForm); 
      } 
 
      model.addAttribute("posts",  posts); 
      return "index"; 
    } 
    // Other codes refer to sources 
} 

The @SessionAttributes are declared on the controller level and are initialized as with any @ModelAttribute. Always initialize the session data to avoid the following error:

Servlet.service() for servlet [pwp] in context with path [/ch01] threw exception [Expected session attribute 'posts'] with root cause
org.springframework.web.HttpSessionRequiredException: Expected session attribute 'posts'

In order for the service operations to access the session attribute argument, be sure to have a @ModelAttribute parameter on the local parameter of the service depicting the attribute data:

public String getIndex(Model model,  @ModelAttribute("posts") 
  List<PostMessage> posts, 
  @ModelAttribute("postForm") PostMessage postForm) { 
  } 

These two attributes trigger the information workflow of the PWP project, even without the help of any web services or data store.

Binding to the form view using @ModelAttribute, forms domain objects that are plain POJOs, and are used to save request parameter values from the user. Sometimes these objects are also called form data models. See the following domain:

package org.packt.personal.web.portal.model.form; 
 
public class Home { 
 
  private String message; 
  private String quote; 
 
  public String getMessage() { 
    return message; 
  } 
 
  public void setMessage(String message) { 
    this.message = message; 
  } 
 
  public String getQuote() { 
    return quote; 
  } 
 
  public void setQuote(String quote) { 
    this.quote = quote; 
  } 
} 

Instantiation of this model will be found in the initForm() method and the binding to the form view page will be implemented using the Spring Form Taglib directive:

<%@ taglib prefix="form"  uri="http://www.springframework.org/tags/form"%> 

The Spring MVC <form> tag has its own form components that can be readily mapped to the setters of the form domain objects. These topics will be highlighted in Chapter 3, Student Management Portal (SMP), of this book. The following JSP code snippet shows how the binding is done through the <form> tag:

<form:form commandName="homeForm" method="post"> 
  <div class="form_settings"> 
    <!-- insert the page content here --> 
    <h2>Update Inspirational Message</h2> 
    <p><form:textarea path="message" rows="8" cols="50"/></p> 
    <span><form:errors path="message" cssStyle="color:      #ff0000; "/></span> 
    <br/> <br/> <br/> 
 
    <h2>Update Best Quote (Required)</h2> 
    <p><form:textarea path="quote" rows="8" cols="50"/></p> 
    <span><form:errors path="quote"  cssStyle="color:      #ff0000; "/></span>  
    <br/> <br/> <br/> 
 
    <p style="padding-top: 15px; padding-left: 20px"><input      class="submit"  
    type="submit" value="Update Home Page"></p> 
  </div> 
  </form:form> 

There are instances when a form view page contains several request parameters which need to be subdivided into groups.

Given this situation, the best strategy is to decompose the huge flat domain POJO into several specific form domain models, each containing related data. Then, create a main POJO component class, which will hold all smaller domain models. This class will be represented as the form-backing object for the form view. A sample implementation of the preceding content page is shown as follows:

package org.packt.personal.web.portal.model.form; 
 
public class Personal { 
 
  private Biography biography; 
  private Education education; 
 
  public Biography getBiography() { 
    return biography; 
  } 
  public void setBiography(Biography biography) { 
    this.biography = biography; 
  } 
  public Education getEducation() { 
    return education; 
  } 
  public void setEducation(Education education) { 
    this.education = education; 
  } 
} 
 
package org.packt.personal.web.portal.model.form; 
import java.util.Date; 
import java.util.List; 
 
public class Biography { 
  private String firstName; 
  private String lastName; 
  private Integer age; 
  private Date birthDate; 
  private String location; 
  private String country; 
  private List<String> hobbies; 
  private List<String> readings; 
  // The getters and the setters 
} 
 
package org.packt.personal.web.portal.model.form; 
public class Education { 
 
  private String educLevel; 
  private String institution; 
  private String degree; 
  private String specialization; 
  private Integer year; 
 
  // The getters and the setters 
} 

The binding of the component will be quite different compared to the usual domain model. To bind all biography attributes to the form components, it is important to access first the getter method of the biography object, then through this we can now access all the setters of its attributes. The following example is a clear picture of the complicated binding:

<form:form commandName="personForm" method="post"> 
  <div class="form_settings"> 
  <!-- insert the page content here --> 
 
    <h2>Update Personal Information</h2> 
    <table style="width:100%; border-spacing:0;"> 
    <tr><td>First Name (*)</td> 
      <td><form:input path="biography.firstName"/></td> 
      <td><form:errors path="biography.firstName" cssStyle="color:        #ff0000"/></td> 
    </tr> 
    <tr><td>Last Name (*)</td> 
      <td><form:input path="biography.lastName"/></td> 
      <td><form:errors path="biography.lastName" cssStyle="color:        #ff0000"/> 
    </tr> 
    <!-- Rest of the script in the sources --> 
  </table> 
 
  <!-- Rest of the code in sources --> 
</form:form> 

The interface ViewResolver is responsible for the mapping of the view names to the actual view pages. It also provides the view interface, which addresses the request of a view to the view technology. In this PWP project, all of our pages are written in JSP-JSTL so the view interface used is org.springframework.web.servlet.view.JstlView. The project's view resolver is implemented inside the Spring container in this way:

<bean id="viewResolver" 
  class="org.springframework.web.servlet.view.   ResourceBundleViewResolver"> 
  <property name="basename"> 
    <value>config.views</value> 
  </property> 
</bean> 

The views are also declared in the custom property file ./src/config/views.properties:

hello.(class)=org.springframework.web.servlet.view.JstlView 
hello.url=/jsp/hello_world.jsp 
 
index.(class)=org.springframework.web.servlet.view.JstlView 
index.url=/jsp/index.jsp 
 
index_update.(class)=org.springframework.web.servlet.view.JstlView 
index_update.url=/jsp/index_update.jsp 
 
// See the sources 

There are three popular generic ViewResolver implementations that developers always use and these are:

        <bean id="helloWorld" 
          class="org.springframework.web.servlet.view.JstlView"> 
          <property name="url" 
            value="/WEB-INF/helloWorld.jsp" /> 
        </bean> 

A Spring MVC project can have more than resolvers, given that the order property in all definitions is defined to set order levels of 0 having the highest priority. The following code shows the ordering technique:

<bean 
  class="org.springframework.web.servlet.view.   InternalResourceViewResolver"> 
    <property name="prefix"> 
      <value>/WEB-INF/</value> 
    </property> 
    <property name="suffix"> 
      <value>.jsp</value> 
    </property> 
    <property name="order" value="2" /> 
</bean> 
 
<bean class= "org.springframework.web.servlet.view.XmlViewResolver"> 
  <property name="location"> 
    <value>/WEB-INF/views.xml</value> 
  </property> 
  <property name="order" value="1" /> 
</bean> 
 
<bean class= "org.springframework.web.servlet.view.ResourceBundleViewResolver"> 
  <property name="basename" value="views" /> 
  <property name="order" value="0" /> 
</bean> 

By convention, the InternalResourceViewResolver is always given the least priority because it takes a little time to map the view name directly to the actual pages before all the remaining resolvers. This might give conflict to other mappings if other resolvers are not fast enough in mapping views.

All form domain objects must be validated using the org.springframework.validation.Validator interface and annotations supported by JSR 303. The validation interface is implemented to create a set of validation rules as per the form view. A sample implementation used in PWP's home content page is shown as follows:

package org.packt.personal.web.portal.validator; 
 
import org.packt.personal.web.portal.model.form.Home; 
import org.springframework.stereotype.Component; 
import org.springframework.validation.Errors; 
import org.springframework.validation.ValidationUtils; 
import org.springframework.validation.Validator; 
 
public class IndexValidator implements Validator { 
  @Override 
  public boolean supports(Class<?> clazz) { 
    return Home.class.equals(clazz); 
  } 
 
  @Override 
  public void validate(Object obj, Errors errors) { 
    Home homeForm = (Home) obj; 
    ValidationUtils.rejectIfEmptyOrWhitespace(errors, 
      "message", "message.empty"); 
    ValidationUtils.rejectIfEmptyOrWhitespace(errors,  
      "quote", "quote.empty"); 
 
    if(homeForm.getMessage().length() > 500) { 
      errors.rejectValue("message", 
        "message.maxlength"); 
    } 
    if(homeForm.getMessage().length() < 50) { 
      errors.rejectValue("message", 
        "message.minlength"); 
    } 
 
    if(homeForm.getQuote().length() > 500) { 
      errors.rejectValue("quote", "quote.maxlength"); 
    } 
    if(homeForm.getQuote().length() < 50) { 
      errors.rejectValue("quote", "quote.minlength"); 
    } 
  } 
 
} 

It validates checks if the user entered a content message and quotes greater than 50, but not greater than 500 alphanumeric. The validator interface has two abstract methods to implement, namely:

Validators are components of the Spring MVC project. Spring MVC 4 uses the @Autowired stereotype to call the instance of the validator in the controller class. To enable the validator, the setValidator() method of org.springframework.web.bind .WebDataBinder has to be invoked inside the initBinder() method. To avoid complications, it is recommended to set one validator per initBinder() since we can create more than one initBinder() inside a form controller.

For situations like in PWP where both the @SessionAttributes and @ModelAttribute are utilized by the operations, initBinder() is recommended to be explicitly mapped to the specific attribute for the validator. Otherwise, the following exception shown will be encountered:

SEVERE: Servlet.service() for servlet [pwp] in context with path [/ch01] threw exception [Request processing failed; nested exception is java.lang.IllegalStateException: Invalid target for Validator [org.packt.personal.web.portal.validator.IndexValidator@5b4ca52d]: undefault] with root cause
java.lang.IllegalStateException: Invalid target for Validator [org.packt.personal.web.portal.validator.IndexValidator@5b4ca52d]: undefault

To retrieve the result of the validation on a @ModelAttribute as per initBinder(), be sure to use the @Validated stereotype with the model argument declared in the submitForm() method. Following is a code that shows how to declare and enable validation in a form controller:

@Autowired 
  private Validator indexValidator; 
 
  @InitBinder("homeForm") 
  public void initBinder(WebDataBinder binder) { 
    binder.setValidator(indexValidator); 
  } 
 
  @RequestMapping(method=RequestMethod.POST) 
  public String submitForm(Model model,    @ModelAttribute("homeForm") @Validated Home homeForm,    BindingResult binding) { 
    model.addAttribute("homeForm", homeForm); 
    String returnVal = "index"; 
    if(binding.hasErrors()) { 
      returnVal = "index_update"; 
    } else { 
      model.addAttribute("homeSess", homeForm); 
      model.addAttribute("statusSess", "undefault"); 
    } 
    return returnVal; 
  } 

@Controller 
@RequestMapping("/pwp/contact") 
public class EmailController { 
 
  @NotNull 
  @Autowired 
  private SimpleMailMessage emailTemplate; 
 
  @NotNull 
  @Autowired 
  private JavaMailSender emailSender; 
  // See the sources 
} 

The main purpose of the initBinder() is not purely to validate, but to bind request parameter data to the form domain model. It checks if the request parameter data matches the type of variables in the form-backing object. It provides conversion processes to data in order to avoid type mismatch and other related exceptions. The method has built-in property editors that you can use to check types. Some are custom editors of the type  java.beans.PropertyEditorSupport that check complicated matches with added custom transactions.

In the Personal portal page, there are data that needs to be converted into proper object types like age and birth date.

Remember that request parameter data are all, by default, String objects. The custom property editor can be helpful in converting String data to other types, just to fit in the form-backing object's setter methods. Following is a custom editor for this page:

package org.packt.personal.web.portal.converter; 
import java.beans.PropertyEditorSupport; 
 
public class AgeConverter extends PropertyEditorSupport { 
 
  @Override 
  public void setAsText(String text) throws 
  IllegalArgumentException { 
    Integer age = 0; 
    try { 
      age = Integer.parseInt(text.trim()); 
    } catch(Exception e) { 
      age = 18; 
    } 
    setValue(age); 
  } 
} 
 
package org.packt.personal.web.portal.converter; 
 
import java.beans.PropertyEditorSupport; 
import java.text.ParseException; 
import java.text.SimpleDateFormat; 
import java.util.Date; 
 
public class BirthDateConverter extends PropertyEditorSupport { 
 
  @Override 
  public void setAsText(String text) throws 
  IllegalArgumentException { 
    SimpleDateFormat format = new 
    SimpleDateFormat("mm/yy/dd"); 
    Date birthDate; 
    try { 
      birthDate = format.parse(text.trim()); 
    } catch (ParseException e) { 
      // TODO Auto-generated catch block 
      birthDate = new Date(); 
    } 
    setValue(birthDate); 
  } 
} 

The Reach Out page opens an electronic communication between the portal owner and the portal reader or user. The Spring Framework supports e-mail operations with the org.springframework.mail package as the root level package with the following API classes:

This project sends three forms of e-mail template, namely the basic text-based e-mail, HTML-based e-mail and template-based e-mail. Following is PWP's way of sending an HTML-based e-mail.

public void sendMailHTML(Email emailForm) { 
  String  fromEmail = emailForm.getSendTo(); 
  String toEmail = emailForm.getSendTo(); 
  String emailSubject = emailForm.getSubject(); 
  String emailBody = emailForm.getMessage(); 
 
  MimeMessage mimeMessage = 
  emailSender.createMimeMessage(); 
  try { 
    MimeMessageHelper helper = new 
    MimeMessageHelper(mimeMessage, true, "utf-8"); 
    mimeMessage.setContent("<i><b>"+emailBody  
    +"</b></i>", "text/html"); 
    helper.setFrom(fromEmail); 
    helper.setTo(toEmail); 
    helper.setSubject(emailSubject); 
 
  } catch (MessagingException e) {} 
  /* 
  uncomment the following lines for attachment 
  FileSystemResource 
  file = new FileSystemResource("sample.jpg"); 
  helper.addAttachment(file.getFilename(), file); 
  */ 
 
  emailSender.send(mimeMessage); 
  System.out.println("Mail sent successfully."); 
 
}