In step 2, we provided a workspace path for STS. When you open STS for the very first time after installing STS, it will ask you to provide a workspace location. This is because when you create a project on STS, all your project files will be created under this location only.

Once we enter STS, we should inform STS where the Tomcat has been installed. Only then can STS use your Tomcat web server to deploy the project. This is also a one-time configuration; you need not perform this configuration every time you open STS. We did this by creating a new server runtime environment in step 5. Although STS might come with an internal VMware vFabric tc Server, we chose to use the Tomcat web server as our server runtime environment.

We just created the basic project structure. Any Java project follows a certain directory structure to organize its source code and static resources. Instead of manually creating the whole directory hierarchy by ourselves, we just handed over that job to STS. By collecting some basic information about our project, such as Group Id, Artifact Id, and the Packaging style from us, it is clear that STS is smart enough to create the whole project directory structure with the help of the Maven plugin. Actually, what is happening behind the screen is that STS is internally using Maven to create the project structure.

We want our project to be deployable in any servlet container-based web server, such as Tomcat, and that's why we selected the Packaging style as war. After executing step 4, you will see the project structure in Package Explorer, as shown in the following screenshot:

The project structure of the application

As we are going to use Spring MVC APIs heavily in our project, we need the Spring jars in our project during the development. As I already mentioned, Maven will take care of managing dependencies and packaging the project.

In the Maven world, pom.xml (Project Object Model) is the configuration file that defines the required dependencies. While building our project, Maven will read that file and try to download the specified jars from the Maven central binary repository. You need Internet access in order to download jars from Maven's central repository. Maven uses an addressing system to locate a jar in the central repository, which consists of Group Id, Artifact Id, and Version.

Every time we add a dependency, an entry will be made within the <dependencies> </ dependencies> tags in the pom.xml file. For example, if you go to the pom.xml tab after finishing step 3, you will see an entry for spring-mvc as follows within the <dependencies> </ dependencies> tag:

<dependency>
   <groupId>org.springframework</groupId>
   <artifactId>spring-webmvc</artifactId>
   <version>4.0.3.RELEASE</version>
</dependency>

We added the dependency for spring-mvc in step 3, and in step 4, we added the dependency for JSTL. JSTL is a collection of useful JSP tags that can be used to write JSP pages easily. Finally, we need a servlet-api jar in order to use servlet-related code; this is what we added in step 5.

However, there is a little difference in the scope of the servlet-api dependency compared to the other two dependencies. We only need servlet-api while compiling our project. While packaging our project as war, we don't want to the ship servlet-api jar as part of our project. This is because the Tomcat web server would provide the servlet-api jar while deploying our project. This is why we selected the scope as provided for the servlet-api.

After finishing step 6, you will see all the dependent jars configured in your project, as shown in the following screenshot, under the Maven Dependencies library:

We added only three jars as our dependencies, but if you notice in our Maven dependency library list, you will see more than three jar entries. Can you guess why? What if our dependent jars have a dependency on other jars and so on?

For example, our spring-mvc jar is dependent on the spring-core, spring-context, and spring-aop jars, but we have not specified those jars in our pom.xml file; this is called transitive dependencies in the Maven world. In other words, we can say that our project is transitively dependent on these jars. Maven will automatically download all these transitive dependent jars; this is the beauty of Maven. It will take care of all the dependency management automatically; we need to inform Maven only about the first level dependencies.

We created our project and added all the required jars, so we are ready to code. We are going to incrementally build an online web store throughout this book, chapter by chapter. As a first step, let's create a home page in our project to welcome our customers.

Our aim is simple; when we enter the http://localhost:8080/webstore/ URL on the browser, we would like to show a welcome page that is similar to the following screenshot:

Don't worry if you are not able to understand some of the code; we are going to take a look at each concept in detail in the upcoming chapters. As of now, our aim is to have quick hands-on experience of developing a simple web page using Spring MVC.

In step 1, we just created a JSP view; the important thing we need to notice here is the <h1> tag and the <p> tag. Both the tags have some expression that is surrounded by curly braces and prefixed by the $ symbol:

<h1> ${greeting} </h1>
<p> ${tagline} </p>

So, what is the meaning of ${greeting}? It means that greeting is a kind of variable; during the rendering of this JSP page, the value stored in the greeting variable will be shown in the header 1 style, and similarly, the value stored in the tagline variable will be shown as a paragraph.

So now, the next question of where we will assign values to those variables arises. This is where the controller will be of help; within the welcome method of the HomeController class, take a look at the following lines of code:

model.addAttribute("greeting", "Welcome to Web Store!");
model.addAttribute("tagline", "The one and only amazing web store");

You can observe that the two variable names, greeting and tagline, are passed as a first parameter of the addAttribute method and the corresponding second parameter is the value for each variable. So what we are doing here is simply putting two strings, "Welcome to Web Store!" and "The one and only amazing web store", into the model with their corresponding keys as greeting and tagline. As of now, simply consider the fact that model is a kind of map. Folks with knowledge of servlet programming can consider the fact that model.addAttribute works exactly like request.setAttribute.

So, whatever value we put into the model can be retrieved from the view (jsp) using the corresponding key with the help of the ${} placeholder expression notation.

We created a controller that can put values into the model, and we created the view that can read those values from the model. So, the model acts as an intermediate between the view and the controller; with this, we have finished all the coding part required to present the welcome page. So will we be able to run our project now? No; at this stage, if we run our project and enter the http://localhost:8080/webstore/ URL on the browser, we will get an HTTP Status 404 error. This is because we have not performed any servlet mapping yet. In a Spring MVC project, we must configure a front servlet mapping. The front servlet (sometimes called the front controller) mapping is a design pattern where all requests for a particular web application are directed to the same servlet. One such front servlet given by Spring MVC framework is the dispatcher servlet (org.springframework.web.servlet.DispatcherServlet). We have not configured a dispatcher servlet for our project yet; this is why we get the HTTP Status 404 error.

If you know about servlet programming, you might be quite familiar with the servlet configuration and web.xml. In web.xml, we configured a servlet named DefaultServlet, which is more or less similar to any other normal servlet configuration. The only difference is that we have not created any servlet class for that configuration. Instead, the servlet class (org.springframework.web.servlet.DispatcherServlet) is provided by the Spring MVC framework, and we make use of it in web.xml. After this step, our configured DispatcherServlet (DefaultServlet) will be ready to handle any requests that come to our application on runtime and will dispatch the request to the correct controller's method.

However, DispatcherServlet should know where our controllers and view files are located in our project, and only then can it properly dispatch the request to the correct controllers. So we have to give some hint to DispatcherServlet to locate the controllers and view files. This is what we configured in step 2 through the DispatcherServlet-servlet.xml file.

Don't worry if you are not able to understand each and every configuration in web.xml and DispatcherServlet-servlet.xml; we will take a look at these configuration files in next chapter. As of now, just remember that this is a one-time configuration that is needed to run our project successfully.

We successfully created the project in the last section, so you might be curious to know what would happen if we run our project now. As our project is a web project, we need a web server to run it.