2. The Basics of Web Programming

The primary purpose of this chapter is to introduce the key principles of web programming, which are independent of the specific technology used to implement them. It presents numerous examples that you are encouraged to test in order to gradually “absorb” the philosophy of web development. Readers who already possess this knowledge may proceed directly to Chapter 3.

The components of a web application are as follows:

Number	Role	Common Examples
1	OS Server	Unix, Linux, Windows
2	Web server	Apache (Unix, Linux, Windows) IIS (Windows + .NET platform) Node.js (Unix, Linux, Windows)
3	Server-side code. This code can be executed by server modules or by programs external to the server (CGI).	JAVASCRIPT (Node.js) PHP (Apache, IIS) JAVA (Tomcat, WebSphere, JBoss, WebLogic, ...) C#, VB.NET (IIS)
4	Database - This can be on the same machine as the program that uses it or on another machine via the Internet.	Oracle (Linux, Windows) MySQL (Linux, Windows) Postgres (Linux, Windows) SQL Server (Windows)
5	OS Client	Unix, Linux, Windows
6	Web browser	Chrome, Internet Explorer, Firefox, Opera, Safari, ...
7	Client-side scripts executed within the browser. These scripts have no access to the client machine's disks.	Javascript (any browser)

2.1. Data exchange in a web application with a form

Number	Role
1	The browser requests a URL for the first time (http://machine/url). No parameters are passed.
2	The web server sends it the web page for this URL. It can be static or dynamically generated by a server-side script (SA) that may have used database content (SB, SC). Here, the script will detect that URL was requested without any parameters and will generate the initial web page. The browser receives the page and displays it (CA). Browser-side scripts (CB) may have modified the initial page sent by the server. Then, through interactions between the user (CD) and the scripts (CB), the web page will be modified. In particular, the forms will be filled out.
3	The user submits the form data, which must then be sent to the web server. The browser requests the initial URL or another one, as appropriate, and simultaneously transmits the form values to the server. It can use two methods for this purpose, called GET and POST. Upon receiving the client’s request, the server triggers the script (SA) associated with the requested URL, which detects the parameters and processes them.
4	The server delivers the programmatically generated web page (SA, SB, SC). This step is identical to the previous Step 2. Communication now proceeds according to Steps 2 and 3.

2.2. Static Web Pages, Dynamic Web Pages

A static page is represented by a HTML file. A dynamic page is a HTML page generated "on the fly" by the web server.

2.2.1. Static page HTML (HyperText Markup Language)

Let’s build our first Spring project MVC [1-2]:

In [1-2], we create a new project based on Spring Boot [http://projects.spring.io/spring-boot/];

the information in [3-7] is for the project’s Maven configuration;
in [3], the name of the Maven project;
In [4], the Maven group where the project's build output will be placed;
in [5], the name given to the compilation output;
in [6], a description of the project;
in [7], the package in which the project’s executable class will be placed;
in [8], the nature of the project. It is a web project with Thymeleaf views. Here, we see all the ready-to-use Maven dependencies provided by the Spring Boot project;
in [9], we specify that the output of the Maven build will be packaged in a jar archive rather than a WAR file. The project will then use an embedded Tomcat server, which will be included in its dependencies;
In [10], we proceed to the next step of the wizard;

In [11], specify the project folder;
In [12], complete the wizard;
In [13], the generated project.

Let’s examine the generated file [pom.xml]:


<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
 
    <groupId>istia.st.springmvc</groupId>
    <artifactId>intro</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>
 
    <name>springmvc-intro</name>
    <description>Les bases de la programmation web</description>
 
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.1.9.RELEASE</version>
        <relativePath /> <!-- lookup parent from repository -->
    </parent>
 
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>
 
    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <start-class>istia.st.springmvc.Application</start-class>
        <java.version>1.7</java.version>
    </properties>
 
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>
 
</project>

It includes all the information provided in the wizard. In lines 26–30, we find a dependency we weren’t aware of. It enables the integration of the JUnit unit tests with Spring.

Let’s start by creating a static HTML page in this project. By default, it should be placed in the [src / main / resources / static] folder:

In [1-4], create a file named HTML in the [static] folder;

In [6], name the page;
In [7], the page has been added.

The content of the created page is as follows:


<!DOCTYPE html>
<html>
<head>
<meta charset="ISO-8859-1">
<title>Insert title here</title>
</head>
<body>
 
</body>
</html>

lines 2-10: the code is delimited by the root tag <html>;
lines 3-6: the <head> tag delimits what is called the page header;
lines 7-9: the <body> tag delimits what is called the body of the page.

Let’s modify this code as follows:


<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>essai 1 : une page statique</title>
</head>
<body>
  <h1>Une page statique...</h1>
</body>
</html>

line 5: defines the page title – will be displayed as the title of the browser window displaying the page;
line 8: text in large font (<h1>).

Let's run the [1-3] application:

then, using a browser, let’s request URL [http://localhost:8080/exemple-01.html]:

in [1], the URL of the displayed page;
in [2], the window title – provided by the <title> tag on the page;
in [3], the body of the page – was provided by the h1 tag.

Let’s look at [4-5], the code received by the browser:

in [5], the browser received the page HTML that we had built. It interpreted it and rendered it as a graphical display.

2.2.2. A dynamic Thymeleaf page

Now let’s create a Thymeleaf page. It is a classic HTML page with tags enriched with [Thymeleaf] and [http://www.thymeleaf.org/] attributes. We follow a process similar to that used to create the HTML page, but this time the new HTML page must be placed in the [templates] folder:

The page [exemple-02.html] will be as follows:


<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<title>spring mvc intro</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
    <p th:text="'Il est ' + ${heure}">Voici l'heure</p>
</body>
</html>

line 8: the <p> tag is a HTML tag that introduces a paragraph into the displayed page. [th:text] is a [Thymeleaf] attribute that has two different purposes depending on whether [Thymeleaf] is active or not:
- if [Thymeleaf] does not interpret the page HTML, the attribute [th:text] will be ignored because it is unknown in HTML. The displayed text will then be [Voici l'heure],
- if [Thymeleaf] interprets the page HTML, the attribute [th:text] will be evaluated and its value will replace the text [Voici l'heure]. Its value will be something like [Il est 17:11:06];

Let’s see this in action. We duplicate the page [templates / exemple-02.html] into the folder [static]. The pages HTML placed in this folder are not interpreted by [Thymeleaf]:

We run the application as we have done several times before, then request URL and [http://localhost:8080/exemple-02.html] using a browser:

We see in [1] that the [th:text] attribute was not interpreted and did not cause an error either. The source code of the page received in [2] shows that the browser did indeed receive the complete page.

Let’s return to the [exemple-02.html] page in the [templates] folder:

The pages HTML located in the folder [templates] are interpreted by [Thymeleaf]. Let’s return to the page’s code:


<!DOCTYPE HTML>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<title>spring mvc intro</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<body>
    <p th:text="'Il est ' + ${heure}">Voici l'heure</p>
</body>
</html>

Line 7: [Thymeleaf] will interpret the attribute [th:text] and replace [Voici l'heure] with the value of the expression:

"'Il est ' + ${heure}"

This expression uses the variable [${heure}], where [heure] belongs to the [exemple-02.html] view template. We therefore need to create this template. To do so, we will follow the example discussed in section 1.6. We update the project as follows:

In [1], we add the following controller:


package istia.st.springmvc;
 
import java.text.SimpleDateFormat;
import java.util.Date;
 
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.RequestMapping;
 
@Controller
public class MyController {
 
    @RequestMapping("/")
    public String heure(Model model) {
        // time format
        SimpleDateFormat formater = new SimpleDateFormat("HH:MM:ss");
        // the hour of the moment
        String heure = formater.format(new Date());
        // set the time in the view model
        model.addAttribute("heure", heure);
        // display the [exemple-02.html] view
        return "exemple-02";
    }
}

lines 13-14: the [heure] method processes URL and [/];
line 14: [Model model] is an empty template. The [heure] action must populate it with the attributes it wants to see in the template. We know that the view [exemple-02.html] expects an attribute named [heure];
lines 19–22: implement what has just been explained. The view [exemple-02.html] will be displayed (line 22) with an attribute named [heure] in its template (line 20);
line 16: a date formatter is created. The format [HH:MM:ss] used is a [heures:minutes:secondes] format where the hours are in the range [0-24];
line 18: using this formatter, the current date is formatted;
line 20: the resulting time is assigned to an attribute named [heure];

We launch the application and request the URL [/]:

in [1] the resulting page and in [2] its content HTML. We can see that the original text [Voici l'heure] has completely disappeared;

If we now refresh the page [1] (F5), we get a different display (new time), while URL remains unchanged. This is the dynamic aspect of the page: its content can change over time.

From the above, we can see the fundamentally different nature of dynamic and static pages.

2.2.3. Configuring the Spring Boot Application

Let’s return to the Eclipse project architecture:

The [application.properties] file is used to configure the Spring Boot application. For now, this file is empty. It can be used to configure the application in various ways described in URL and [http://docs.spring.io/spring-boot/docs/current/reference/html/common-application-properties.html]. We will use the following [application.properties] file:

line 1: sets the web application’s service port;
line 2: sets the web application context;

With this configuration, the static page [exemple-01.html] will be generated using URL and [http://localhost:9000/intro/exemple-01.html]:

2.3. Browser-side scripts

A HTML page can contain scripts that will be executed by the browser. The primary browser-side scripting language is currently (Jan 2015) Javascript. Hundreds of libraries have been built using this language to make developers' lives easier.

Let’s create a new [exemple-03.html] page in the [static] folder of the existing project:

Edit the [exemple-03.html] file with the following content:


<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>exemple Javascript</title>
  <script type="text/javascript">
    function réagir() {
      alert("Vous avez cliqué sur le bouton !");
    }
  </script>
</head>
<body>
  <input type="button" value="Cliquez-moi" onclick="réagir()" />
</body>
</html>

line 13: defines a button (type attribute) with the text "Click me" (value attribute). When clicked, the function Javascript [réagir] is executed (onclick attribute);
lines 6–10: a script Javascript;
lines 7–9: the [réagir] function;
line 8: displays a dialog box with the message [Vous avez cliqué sur le bouton].

Let’s view the page in a browser:

in [1], the displayed page;
in [2], the dialog box when the button is clicked.

When the button is clicked, there is no communication with the server. The code Javascript is executed by the browser.

With the many Javascript libraries available, it is now possible to embed full-fledged applications within the browser. This leads to the following architectures:

1-2: the HTML server is a server for static pages HTML5 / CSS / Javascript;
3-4: The delivered pages HTML5 / CSS / Javascript interact directly with the data server. The data server delivers only data without formatting (HTML). It is Javascript that inserts them into HTML pages already present in the browser.

In this architecture, the Javascript code can become cumbersome. We therefore aim to structure it into layers, as we do for server-side code:

the [UI] layer is the one that interacts with the user;
the [DAO] layer interacts with the data server;
the [métier] layer contains the business procedures that interact with neither the user nor the data server. This layer may not exist.

2.4. Client-server communication

Let’s return to our initial diagram illustrating the components of a web application:

Here, we are focusing on the exchanges between the client machine and the server machine. These occur over a network, and it is worth reviewing the general structure of exchanges between two remote machines.

2.4.1. The OSI model

The open network model known as OSI (Open Systems Interconnection Reference Model), defined by the ISO (International Standards Organization), describes an ideal network where communication between machines can be represented by a seven-layer model:

Each layer receives services from the lower layer and provides its own to the upper layer. Suppose two applications located on different machines A and B want to communicate: they do so at the Application layer. They do not need to know all the details of how the network operates: each application passes the information it wishes to transmit to the layer below it: the Presentation layer. The application therefore only needs to know the rules for interfacing with the Presentation layer. Once the information is in the Presentation layer, it is passed according to other rules to the Session layer, and so on, until the information reaches the physical medium and is physically transmitted to the destination machine. There, it will undergo the reverse process of what it underwent on the sending machine.

At each layer, the sender process responsible for sending the information sends it to a receiver process on the other machine belonging to the same layer as itself. It does so according to certain rules known as the layer protocol. We therefore have the following final communication diagram:

The roles of the different layers are as follows:

Physical	Ensures the transmission of bits over a physical medium. This layer includes data processing terminal equipment (E.T.T.D.) such as terminals or computers, as well as data circuit termination equipment (E.T.C.D.) such as modulators/demodulators, multiplexers, and concentrators. Key points at this level are: the choice of information encoding (analog or digital) the choice of transmission mode (synchronous or asynchronous).
Data Link	Hides the physical characteristics of the Physical Layer. Detects and corrects transmission errors.
Network	Manages the path that information sent over the network must follow. This is called routing: determining the route that information must take to reach its destination.
Transport	Enables communication between two applications, whereas the previous layers only allowed communication between machines. A service provided by this layer can be multiplexing: the transport layer can use a single network connection (from machine to machine) to transmit data belonging to multiple applications.
Session	This layer provides services that allow an application to open and maintain a working session on a remote machine.
Presentation	It aims to standardize the representation of data across different machines. Thus, data originating from machine A will be "formatted" by machine A’s Presentation layer according to a standard format before being sent over the network. Upon reaching the Presentation layer of the destination machine B, which will recognize them thanks to their standard format, they will be formatted differently so that the application on machine B can recognize them.
Application	At this level, we find applications that are generally close to the user, such as email or file transfer.

2.4.2. The TCP/IP model

The OSI model is an ideal model. The TCP/IP protocol suite approximates it in the following form:

the network interface (the computer's network card) performs the functions of layers 1 and 2 of the OSI model
the IP layer (Internet Protocol) performs the functions of Layer 3 (network)
the TCP layer (Transfer Control Protocol) or UDP (User Datagram Protocol) performs the functions of Layer 4 (transport). The TCP protocol ensures that the data packets exchanged by the machines reach their destination. If this is not the case, it resends the lost packets. The UDP protocol does not perform this task, so it is up to the application developer to do so. This is why, on the Internet—which is not a 100% reliable network—the TCP protocol is the most widely used. This is referred to as a TCP-IP network.
The Application layer covers the functions of layers 5 through 7 of the OSI model.

Web applications reside in the Application layer and therefore rely on the TCP-IP protocols. The Application layers of the client and server machines exchange messages, which are then handed off to layers 1 through 4 of the model for forwarding to their destination. To communicate with each other, the application layers of both machines must "speak" the same language or protocol. The protocol used by web applications is called HTTP (HyperText Transfer Protocol). It is a text-based protocol, c.a.d, whereby machines exchange lines of text over the network to communicate. These exchanges are standardized, meaning that the client has a set of messages to tell the server exactly what it wants, and the server also has a set of messages to provide the client with its response. This message exchange takes the following form:

Client --> Server

When the client makes a request to the web server, it sends

text lines in the format HTTP to indicate what it wants;
an empty line;
optionally a document.

Server --> Client

When the server responds to the client, it sends

text lines in the format HTTP to indicate what it is sending;
an empty line;
optionally a document.

Communications therefore follow the same format in both directions. In both cases, a document may be sent, even though it is rare for a client to send a document to the server. But the HTTP protocol provides for this. This is what allows, for example, subscribers of an ISP to upload various documents to their personal website hosted by that ISP. The exchanged documents can be of any type. Consider a browser requesting a web page containing images:

the browser connects to the web server and requests the page it wants. The requested resources are uniquely identified by URL (Uniform Resource Locator). The browser sends only HTTP headers and no document.
The server responds. It first sends HTTP headers indicating what type of response it is sending. This may be an error if the requested page does not exist. If the page exists, the server will indicate in the HTTP headers of its response that it will send a HTML document (HyperText Markup Language) following these headers. This document is a sequence of text lines in HTML format. A HTML text contains tags (markers) that provide the browser with instructions on how to display the text.
The client knows from the server’s HTTP headers that it will receive a HTML document. It will parse the document and may notice that it contains image references. These images are not included in the HTML document. It therefore sends a new request to the same web server to request the first image it needs. This request is identical to the one made in step 1, except that the requested resource is different. The server will process this request by sending the requested image to the client. This time, in its response, the headers will specify that the document sent is an image and not a HTML document.
The client retrieves the sent image. Steps 3 and 4 will be repeated until the client (usually a browser) has all the documents needed to display the entire page.

2.4.3. The HTTP protocol

Let’s explore the HTTP protocol using examples. What do a browser and a web server exchange?

The web service or HTTP service is a TCP-IP service that usually runs on port 80. It could run on a different port. In this case, the client browser would be required to specify this port in the URL request it sends. A URL request generally takes the following form:

protocol://[:port] machine/path/info

where

protocol	http for the web service. A browser can also act as a client for FTP, news, Telnet, and other services.
machine	name of the machine hosting the web service
port	Web service port. If it is 80, the port number can be omitted. This is the most common case
path	path to the requested resource
info	additional information provided to the server to specify the client's request

What does a browser do when a user requests to load a URL?

It opens a TCP-IP connection with the machine and port specified in the machine[:port] section of the URL. Opening a TCP-IP connection means creating a communication "pipe" between two machines. Once this pipe is created, all information exchanged between the two machines will pass through it. The creation of this TCP-IP connection does not yet involve the HTTP web protocol.
Once the TCP-IP pipe is created, the client will send its request to the web server by sending it lines of text (commands) in the HTTP format. It will send the path/info portion of the URL to the server
the server will respond in the same way and over the same channel
one of the two parties will decide to close the connection. This depends on the HTTP protocol used. With the HTTP 1.0 protocol, the server closes the connection after each of its responses. This forces a client that must make multiple requests to obtain the various documents that make up a web page to open a new connection for each request, which incurs a cost. With the HTTP/1.1 protocol, the client can instruct the server to keep the connection open until it tells the server to close it. It can therefore retrieve all the documents for a web page using a single connection and close the connection itself once the last document has been obtained. The server will detect this closure and close the connection as well.

To examine the exchanges between a client and a web server, we will use the [Advanced Rest Client] extension for the Chrome browser that we installed in Section 9.6. We will be in the following situation:

The web server can be any server. Here, we aim to examine the exchanges that will occur between the browser and the web server. Previously, we created the following static page:


<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>essai 1 : une page statique</title>
</head>
<body>
  <h1>Une page statique...</h1>
</body>
</html>

which we view in a browser:

We can see that the requested URL is: [http://localhost:9000/intro/exemple-01.html]. The web service machine is therefore localhost (=local machine) and port 9000. Let’s use the [Advanced Rest Client] application to request the same URL:

In [1], launch the application (in the [Applications] tab of a new Chrome tab);
in [2], select option [Request];
In [3], specify the target server: http://localhost:9000;
In [4], specify the requested URL: /intro/example-01.html;
in [5], any parameters are added to URL. None here;
In [6], specify the HTTP command used for the query, in this case GET.

This results in the following query:

The prepared request [7] is sent to the server by [8]. The response received is then as follows:

We mentioned earlier that client-server exchanges take the following form:

In [1], we see the headers HTTP sent by the browser in its request. It had no document to send;
In [2], we see the headers HTTP sent by the server in response. In [3], we see the document it sent.

In [3], we recognize the static page HTML that we placed on the web server.

Let’s examine the browser’s request HTTP:

GET /intro/exemple-01.html HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Content-Type: text/plain; charset=utf-8
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4

Line 1 was not displayed by the application;
Line 6: The browser identifies itself with the header [User-Agent];
line 7: the browser indicates that it is sending a text document (text/plain) in UTF-8 format to the server. In fact, here, the browser did not send any document;
line 8: the browser indicates that it accepts any type of document in response;
line 9: the browser specifies the accepted document formats;
line 10: the browser specifies the languages it wants in order of preference.

The server responded by sending the following headers: HTTP:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Last-Modified: Sat, 29 Nov 2014 07:31:43 GMT
Content-Type: text/html
Content-Length: 255
Date: Sat, 29 Nov 2014 08:20:52 GMT

line 1: was not displayed by the application;
line 2: the server identifies itself, in this case an Apache-Coyote server;
line 3: the date the sent document was last modified;
line 4: the type of document sent by the server. Here, a HTML document;
line 5: the size in bytes of the HTML document sent.
line 6: date and time of the response;

2.4.4. Conclusion

We have examined the structure of a web client’s request and the web server’s response to it using a few examples. The communication takes place via the HTTP protocol, a set of text-based commands exchanged between the two parties. The client’s request and the server’s response share the following structure:

The two standard commands for requesting a resource are GET and POST. The command GET is not accompanied by a document. The command POST, on the other hand, is accompanied by a document that is most often a string of characters containing all the values entered in a form. The HEAD command is used to request only the HTTP headers and is not accompanied by a document.

In response to a client request, the server sends a response with the same structure. The requested resource is transmitted in the [Document] section unless the client’s command was HEAD, in which case only the HTTP headers are sent.

2.5. The Basics of the HTML Language

A web browser can display various documents, the most common being the HTML document (HyperText Markup Language). This is formatted text with tags of the form <tag>text</tag>. Thus, the text <B>important</B> will display the text "important" in bold. There are standalone tags such as the <hr/> tag, which displays a horizontal line. We will not review all the tags that can be found in a HTML text. There are many WYSIWYG software tools that allow you to build a web page without writing a single line of HTML code. These tools automatically generate the HTML code for a layout created using the mouse and predefined controls. You can thus insert (using the mouse) a table into the page and then view the code generated by the software to discover the tags to use for defining a table in a web page. It’s as simple as that. Furthermore, knowledge of the HTML language is essential, since dynamic web applications must generate the HTML code themselves to send to the clients web server. This code is generated programmatically, and you must, of course, know what to generate so that the client receives the web page they want.

In short, there is no need to know the entire HTML language to start web programming. However, this knowledge is necessary and can be acquired through the use of WYSIWYG web page construction software such as DreamWeaver and dozens of others. Another way to discover the subtleties of the HTML language is to browse the web and view the source code of pages that feature interesting characteristics you are not yet familiar with.

2.5.1. An example

Consider the following example, which features some elements commonly found in a web document, such as:

a table;
an image;
a link.

A HTML document generally has the following form:

<html> <head> <title>Un titre</title> ... </head> <body attributs> ... </body></html>

The entire document is enclosed by the tags <html>...</html>. It consists of two parts:

<head>...</head>: this is the non-displayable part of the document. It provides information to the browser that will display the document. It often contains the <title>...</title> tag, which sets the text that will appear in the browser’s title bar. Other tags may be found here, notably tags defining the document’s keywords, which are then used by search engines. This section may also contain scripts, most often written in javascript or vbscript, which will be executed by the browser.

<body attributes>...</body>: this is the section that will be displayed by the browser. The HTML tags contained in this section tell the browser the "desired" visual layout for the document. Each browser will interpret these tags in its own way. Two browsers may therefore display the same web document differently. This is generally one of the headaches for web designers.

The code for our example document is as follows:


<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>balises</title>
</head>
 
<body style="height: 400px; width: 400px; background-image: url(images/standard.jpg)">
    <h1 style="text-align: center">Les balises HTML</h1>
    <hr />
    <table border="1">
        <thead>
            <tr>
                <th>Colonne 1</th>
                <th>Colonne 2</th>
                <th>Colonne 3</th>
            </tr>
        </thead>
        <tbody>
            <tr>
                <td>cellule(1,1)</td>
                <td style="width: 150px; text-align: center;">cellule(1,2)</td>
                <td>cellule(1,3)</td>
            </tr>
            <tr>
                <td>cellule(2,1)</td>
                <td>cellule(2,2)</td>
                <td>cellule(2,3</td>
            </tr>
        </tbody>
    </table>
 
    <table>
        <tr>
            <td>Une image</td>
            <td><img border="0" src="images/cerisier.jpg" /></td>
        </tr>
        <tr>
            <td>le site de l'ISTIA</td>
            <td><a href="http://istia.univ-angers.fr">ici</a></td>
        </tr>
    </table>
</body>
</html>

Element	tags and examples HTML
document title	<title>tags</title> (line 5) The text "tags" will appear in the browser's title bar when the document is displayed
horizontal bar	<hr/>: displays a horizontal line (line 10)
table	<table attributes>....</table>: to define the table (lines 11, 31) <thead>...</thead>: to define the column headers (lines 12, 18) <tbody>...</tbody>: to define the table content (lines 19, 30) <tr attributes>...</tr>: to define a row (lines 20, 24) <td attributes>...</td>: to define a cell (line 21) examples: <table border="1">...</table>: the border attribute defines the thickness of the table border <td style="width: 150px; text-align: center;">cell(1,2)</td>: defines a cell whose content will be cell(1,2). This content will be centered horizontally (text-align: center). The cell will have a width of 150 pixels (width: 150px)
image	<img border="0" src="/images/cerisier.jpg"/> (line 36): defines an image with no border (border="0") whose source file is /images/cerisier.jpg on the web server (src="images/cerisier.jpg"). This link is found on a web document obtained via URL http://localhost:port/intro/example-04.html. Therefore, the browser will request URL http://localhost:port/intro/images/cerisier.jpg to retrieve the image referenced here.
link	<a href="http://istia.univ-angers.fr">here</a> (line 40): makes the text here serve as a link to URL http://istia.univ-angers.fr.
page background	<body style="height:400px;width:400px;background-image:url(images/standard.jpg)"> (line 8): indicates that the image to be used as the page background is located at URL [images/standard.jpg] on the web server. In the context of our example, the browser will request the URL http://localhost:port/intro/images/standard.jpg to retrieve this background image. Furthermore, the body of the document will be displayed in a rectangle 400 pixels high and 400 pixels wide.

This simple example shows that to render the entire document, the browser must make three requests to the server:

http://localhost:port/intro/example-04.html to retrieve the source of the document
http://localhost:port/intro/images/cerisier.jpg to retrieve the image cerisier.jpg
http://localhost:port/intro/images/standard.jpg to retrieve the background image standard.jpg

2.5.2. A form HTML

The following example shows a form:

The code HTML that produces this display is as follows:


<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <title>formulaire</title>
  <script type="text/javascript">
    function effacer() {
      alert("Vous avez cliqué sur le bouton Effacer");
    }
  </script>
</head>
 
<body style="height: 400px; width: 400px; background-image: url(images/standard.jpg)">
  <h1 style="text-align: center">Formulaire HTML</h1>
  <form method="post" action="postFormulaire">
    <table>
      <tr>
        <td>Etes-vous marié(e)</td>
        <td>
          <input type="radio" value="Oui" name="R1" />Oui
          <input type="radio" name="R1" value="non" checked="checked" />Non
        </td>
      </tr>
      <tr>
        <td>Cases à cocher</td>
        <td>
          <input type="checkbox" name="C1" value="un" />1
          <input type="checkbox" name="C2" value="deux" checked="checked" />2
          <input type="checkbox" name="C3" value="trois" />3
        </td>
      </tr>
      <tr>
        <td>Champ de saisie</td>
        <td>
          <input type="text" name="txtSaisie" size="20" value="qqs mots" />
        </td>
      </tr>
      <tr>
        <td>Mot de passe</td>
        <td>
          <input type="password" name="txtMdp" size="20" value="unMotDePasse" />
        </td>
      </tr>
      <tr>
        <td>Boîte de saisie</td>
        <td>
          <textarea rows="2" name="areaSaisie" cols="20">
ligne1
ligne2
ligne3
</textarea>
        </td>
      </tr>
      <tr>
        <td>combo</td>
        <td>
          <select size="1" name="cmbValeurs">
            <option value="1">choix1</option>
            <option selected="selected" value="2">choix2</option>
            <option value="3">choix3</option>
          </select>
        </td>
      </tr>
      <tr>
        <td>liste à choix simple</td>
        <td>
          <select size="3" name="lst1">
            <option selected="selected" value="1">liste1</option>
            <option value="2">liste2</option>
            <option value="3">liste3</option>
            <option value="4">liste4</option>
            <option value="5">liste5</option>
          </select>
        </td>
      </tr>
      <tr>
        <td>liste à choix multiple</td>
        <td>
          <select size="3" name="lst2" multiple="multiple">
            <option value="1" selected="selected">liste1</option>
            <option value="2">liste2</option>
            <option selected="selected" value="3">liste3</option>
            <option value="4">liste4</option>
            <option value="5">liste5</option>
          </select>
        </td>
      </tr>
      <tr>
        <td>bouton</td>
        <td>
          <input type="button" value="Effacer" name="cmdEffacer" onclick="effacer()" />
        </td>
      </tr>
      <tr>
        <td>envoyer</td>
        <td>
          <input type="submit" value="Envoyer" name="cmdRenvoyer" />
        </td>
      </tr>
      <tr>
        <td>rétablir</td>
        <td>
          <input type="reset" value="Rétablir" name="cmdRétablir" />
        </td>
      </tr>
    </table>
    <input type="hidden" name="secret" value="uneValeur" />
  </form>
</body>
</html>

The visual control <--> tag mapping for HTML is as follows:

Check	tag HTML
form	<form method="post" action="...">
input field	<input type="text" name="txtSaisie" size="20" value="a few words" />
hidden input field	<input type="password" name="txtMdp" size="20" value="unMotDePasse" />
multiline input field	<textarea rows="2" name="areaSaisie" cols="20"> line1 line2 line3 </textarea>
radio buttons	<input type="radio" value="Yes" name="R1" />Yes <input type="radio" name="R1" value="No" checked="checked" />No
checkboxes	<input type="checkbox" name="C1" value="one" />1 <input type="checkbox" name="C2" value="two" checked="checked" />2 <input type="checkbox" name="C3" value="three" />3
Combo	<select size="1" name="cmbValeurs"> <option value="1">choice1</option> <option selected="selected" value="2">option2</option> <option value="3">option3</option> </select>
single-select list	<select size="3" name="lst1"> <option selected="selected" value="1">list1</option> <option value="2">list2</option> <option value="3">list3</option> <option value="4">list4</option> <option value="5">list5</option> </select>
multiple selection list	<select size="3" id="lst2" multiple="multiple"> <option value="1">list1</option> <option value="2">list2</option> <option selected="selected" value="3">list3</option> <option value="4">list4</option> <option value="5">list5</option> </select>
button type submit	<input type="submit" value="Send" name="cmdRenvoyer" />
reset button	<input type="reset" value="Reset" name="cmdRétablir" />
button	<input type="button" value="Clear" id="name" onclick="clear()" />

Let's review these different tags:

2.5.2.1. The form

form


<form method="post" action="postFormulaire">

HTML tag

<form name="..." method="..." action="...">...</form>

attributes

name="frmexemple": form name

method="..." : method used by the browser to send the values collected in the form to the web server

action="..." : URL to which the values collected in the form will be sent.

A web form is enclosed within the tags <form>...</form>. The form can have a name (name="xx"). This applies to all controls found within a form. The purpose of a form is to collect information entered by the user via the keyboard or mouse and send it to a web server URL. Which one? The one referenced in the action="URL" attribute. If this attribute is missing, the information will be sent to the server of the document in which the form is located. A web client can use two different methods called HTTP and PUT to send data to a web server. The method="method" attribute, with method set to GET or POST, in the <form> tag tells the browser which method to use to send the information collected in the form to the URL specified by the action="URL" attribute. When the method attribute is not specified, the GET method is used by default.

2.5.2.2. Text input fields

input field

HTML tag

<input type="..." name="..." size=".." value=".."/>

The input tag exists for various controls. The type attribute is used to distinguish between these different controls.

attributes

type="text": specifies that this is a text input field

type="password": the characters in the input field are replaced by asterisks (*). This is the only difference from a normal input field. This type of control is suitable for entering passwords.

size="20": number of characters visible in the field—does not prevent the entry of more characters

name="txtInput": name of the control

value="some words": text that will be displayed in the input field.

2.5.2.3. Multi-line input fields

multiline input field

line1

line2

line3

</textarea>

HTML tag	<textarea ...>text</textarea> displays a multi-line input field with text already inside
attributes	rows="2": number of lines cols="'20" : number of columns name="areaSaisie": control name

2.5.2.4. The radio buttons

radio buttons

<input type="radio" value="Yes" name="R1" />Yes

<input type="radio" name="R1" value="no" checked="checked" />No

HTML tag

<input type="radio" attribute2="value2" ..../>text

displays a radio button with text next to it.

attributes

name="radio": name of the control. Radio buttons with the same name form a mutually exclusive group: only one of them can be selected.

value="value": value assigned to the radio button. Do not confuse this value with the text displayed next to the radio button. The text is for display purposes only.

checked="checked": if this keyword is present, the radio button is selected; otherwise, it is not.

2.5.2.5. Checkboxes

checkboxes

<input type="checkbox" name="C1" value="one" />1

<input type="checkbox" name="C2" value="two" checked="checked" />2

<input type="checkbox" name="C3" value="three" />3

HTML tag

<input type="checkbox" attribute2="value2" ....>text

displays a checkbox with text next to it.

attributes

name="C1": control name. Checkboxes may or may not have the same name. Checkboxes with the same name form a group of associated checkboxes.

value="value": value assigned to the checkbox. Do not confuse this value with the text displayed next to the radio button. The latter is for display purposes only.

checked="checked": if this keyword is present, the checkbox is checked; otherwise, it is not.

2.5.2.6. The drop-down list (combo box)

Combo

<option value="1">choice1</option>

<option selected="selected" value="2">option2</option>

<option value="3">option3</option>

</select>

HTML tag

<select size=".." name="..">

<option [selected="selected"] value=”v”>...</option>

...

</select>

displays the text between the <option>...</option>

attributes

name="cmbValeurs": control name.

size="1": number of visible list items. size="1" makes the list equivalent to a combo box.

selected="selected": if this keyword is present for a list item, that item appears selected in the list. In our example above, the list item choice2 appears as the selected item in the combo box when it is first displayed.

value=”v”: if the item is selected by the user, this value ([v]) is posted to the server. If this attribute is absent, the displayed and selected text is posted to the server.

2.5.2.7. Single-selection list

single-select list

</select>

HTML tag	<select size=".." name=".."> <option [selected="selected"]>...</option> ... </select> displays the text between the tags <option>...</option>
attributes	are the same as for the drop-down list displaying only one item. This control differs from the previous drop-down list only in its size>1 attribute.

2.5.2.8. Multi-select list

single-select list

</select>

HTML tag	<select size=".." name=".." multiple="multiple"> <option [selected="selected"]>...</option> ... </select> displays the text between the <option>...</option>
attributes	multiple: allows the selection of multiple items in the list. In the example above, items list1 and list3 are both selected.

2.5.2.9. Button

button

HTML tag

<input type="button" value="..." name="..." onclick="clear()" ..../>

attributes

type="button": defines a button control. There are two other types of buttons: submit and reset.

value="Clear": the text displayed on the button

onclick="function()": allows you to define a function to be executed when the user clicks the button. This function is part of the scripts defined in the displayed web document. The preceding syntax is javascript syntax. If the scripts are written in vbscript, you would write onclick="function" without the parentheses. The syntax remains the same if parameters need to be passed to the function: onclick="function(val1, val2,...)"

In our example, clicking the Clear button calls the following javascript clear function:

function clear() {

alert("You clicked the Clear button");

}

</script>

The clear function displays a message:

2.5.2.10. Button type submit

Button type submit

HTML tag	<input type="submit" value="Send" name="cmdRenvoyer" />
attributes	type="submit": defines the button as a button for sending form data to the web server. When the user clicks this button, the browser will send the form data to the URL defined in the action attribute of the <form> tag, using the method specified by the method attribute of that same tag. value="Submit": the text displayed on the button

2.5.2.11. Reset button

reset button

HTML tag	<input type="reset" value="Reset" name="cmdRétablir"/>
attributes	type="reset": defines the button as a form reset button. When the user clicks this button, the browser will restore the form to the state in which it was received. value="Reset": the text displayed on the button

2.5.2.12. Hidden field

hidden field

HTML tag

<input type="hidden" name="..." value="..."/>

attributes

type="hidden": specifies that this is a hidden field. A hidden field is part of the form but is not displayed to the user. However, if the user were to ask their browser to display the source code, they would see the presence of the <input type="hidden" value="..."> tag and thus the value of the hidden field.

value="aValue": value of the hidden field.

What is the purpose of the hidden field? It allows the web server to retain information across a client’s requests. Consider a web shopping application. The customer purchases a first item art1 in quantity q1 on the first page of a catalog and then moves to a new page in the catalog. To remember that the customer purchased q1 items of art1, the server can place these two pieces of information in a hidden field in the web form on the new page. On this new page, the client purchases q2 units of item art2. When the data from this second form is sent to the server (submit), the server will not only receive the information (q2,art2) but also (q1,art1), which is also part of the form as a hidden field. The web server will then place the information (q1,art1) and (q2,art2) into a new hidden field and send a new catalog page. And so on.

2.5.3. Sending form values to a web server by a web client

We mentioned in the previous study that the web client has two methods for sending the values of a form it has displayed to a web server: the methods GET and POST. Let’s look at an example to see the difference between the two methods.

2.5.3.1. GET method

Let's run an initial test, where in the document's HTML code, the <form> tag is defined as follows:


<form method="get" action="doNothing">

When the user clicks the [1] button, the values entered in the form will be sent to the Spring controller [2]. We have seen that the form values will be sent to the URL [doNothing]:


<form method="get" action="doNothing">

The [doNothing] action is defined in the [MyController] [2] controller as follows:


    // ----------------------- render an empty stream [Content-Length=0]
    @RequestMapping(value = "/doNothing")
    @ResponseBody
    public void doNothing() {
}

line 1: the action processes URL [/doNothing], so in reality [/context/doNothing], where [context] is the context or name of the web application, here [/intro];
line 3: the annotation [@ResponseBody] indicates that the result of the annotated method must be sent directly to the client;
line 4: the method returns nothing. Therefore, the client will receive an empty response from the server.

We only want to know how the browser transmits the entered values to the web server. To do this, we will use a debugging tool available in Chrome. We activate it by pressing CTRL-Shift-I (Shift key) [3]:

Since we are interested in the network traffic between the browser and the web server, we open the [Network] tab above and then click the [Envoyer] button on the form. This is a [submit] button inside a [form] tag. The browser responds to the click by requesting the URL [/intro/doNothing] specified in the [action] attribute of the [form] tag, using the method GET specified in the [method] attribute. We then obtain the following information:

The screenshot above shows the URL requested by the browser after clicking the [envoyer] button. It does indeed request the expected URL ([/intro/doNothing]), but appends additional information consisting of the values entered in the form. To get more information, we click on the link above:

Above [1, 2], we see the HTTP headers sent by the browser. They have been formatted here. To view the raw text of these headers, we follow the link [view source] [3, 4]. The full text is as follows:

GET /intro/doNothing?R1=non&C2=deux&txtSaisie=qqs+mots&txtMdp=unMotDePasse&areaSaisie=ligne1%0D%0Aligne2%0D%0Aligne3%0D%0A&cmbValeurs=2&lst1=1&lst2=1&lst2=3&cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Referer: http://localhost:9000/intro/exemple-05.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4

We see elements we’ve encountered before. Others appear for the first time:

Connection: keep-alive	the client asks the server not to close the connection after its response. This will allow the client to use the same connection for a subsequent request. The connection does not remain open indefinitely. The server will close it after a period of inactivity.
Referer	The URL that was displayed in the browser when the new request was made.

The new entry is line 1 in the information following the URL. We can see that the choices made in the form are reflected in the URL. The values entered by the user in the form were passed in the GET URL?param1=value1&param2=value2&... HTTP/1.1 where the parameters are the names (name attribute) of the web form controls and the values are the values associated with them. Below is a three-column table:

Column 1: contains the definition of a HTML control from the example;
Column 2: shows how this control appears in a browser;
Column 3: shows the value sent to the server by the browser for the control in Column 1 in the form it takes in the GET request from the example.

HTML control	Visual	returned value(s)
<input type="radio" value="Yes" name="R1"/>Yes <input type="radio" name="R1" value="no" checked="checked"/>No		R1=Yes - the value of the "value" attribute of the radio button selected by the user.
<input type="checkbox" name="C1" value="one"/>1 <input type="checkbox" name="C2" value="two" checked="checked"/>2 <input type="checkbox" name="C3" value="three"/>3		C1=one C2=two - values of the value attributes of the checkboxes selected by the user
<input type="text" name="txtSaisie" size="20" value="a few words"/>		txtInput=Web+programming - text typed by the user in the input field. Spaces have been replaced by the + sign
<input type="password" name="txtMdp" size="20" value="unMotDePasse"/>		txtPassword=thisissecret - text typed by the user in the input field
<textarea rows="2" name="areaSaisie" cols="20"> line1 line2 line3 </textarea>		inputArea=the+basics+of+Web%0D%0A Web+programming - text typed by the user in the input field. %OD%OA is the end-of-line marker. Spaces have been replaced by the + sign
<select size="1" name="cmbValeurs"> <option value='1'>choice1</option> <option selected="selected" value='2'>choice2</option> <option value='3'>option3</option> </select>		cmbValues=3 - [value] attribute of the element selected by the user
<select size="3" name="lst1"> <option selected="selected" value='1'>list1</option> <option value='2'>list2</option> <option value='3'>list3</option> <option value='4'>list4</option> <option value='5'>list5</option> </select>		lst1=3 - [value] attribute of the element selected by the user
<select size="3" name="lst2" multiple="multiple"> <option selected="selected" value='1'>list1</option> <option value='2'>list2</option> <option selected="selected" value='3'>list3</option> <option value='4'>list4</option> <option value='5'>list5</option> </select>		lst2=1 lst2=3 - [value] attributes of the elements selected by the user
<input type="submit" value="Send" name="cmdRenvoyer"/>		cmdResend=Send - name and value attribute of the button used to send the form data to the server
<input type="hidden" name="secret" value="uneValeur"/>		secret=aValue - value attribute of the hidden field

2.5.3.2. Method POST

We modify the HTML document so that the browser now uses the POST method to send the form values to the web server:


  <form method="post" action="doNothing">

We fill out the form as we did for the GET method and submit the parameters to the server using the [Envoyer] button. As done in the previous paragraph on page 62, we can view the HTTP headers of the request sent by the browser in Chrome:

POST /intro/doNothing HTTP/1.1
Host: localhost:9000
Connection: keep-alive
Content-Length: 172
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Origin: http://localhost:9000
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:9000/intro/exemple-05.html
Accept-Encoding: gzip, deflate
Accept-Language: fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4

R1=non&C2=deux&txtSaisie=qqs+mots&txtMdp=unMotDePasse&areaSaisie=ligne1%0D%0Aligne2%0D%0Aligne3%0D%0A&cmbValeurs=2&lst1=1&lst2=1&lst2=3&cmdRenvoyer=Envoyer&secret=uneValeur

New entries appear in the client's query HTTP:

POST URL HTTP/1.1	The GET request has been replaced by a POST request. The parameters are no longer present in this first line of the request. We can see that they are now placed (line 15) after the request HTTP, following a blank line. Their encoding is identical to that in the request GET.
Content-Length	number of characters "posted", c.a.d. The number of characters the web server must read after receiving the headers HTTP to retrieve the document sent by the client. The document in question here is the list of form values.
Content-type	specifies the type of document the client will send after the headers HTTP. The type [application/x-www-form-urlencoded] indicates that it is a document containing form values.

There are two methods for transmitting data to a web server: GET and POST. Is one method better than the other? We have seen that if form values were sent by the browser using the GET method, the browser displayed the requested URL in its Address field in the form URL?param1=val1&param2=val2&.... This can be seen as either an advantage or a disadvantage:

an advantage if you want to allow the user to add this configured URL to their bookmarks;
a disadvantage if you do not want the user to have access to certain information in the form, such as hidden fields.

Going forward, we will use the POST method almost exclusively in our forms.

2.6. Conclusion

This chapter has introduced various basic concepts of web development:

client-server communication via the HTTP protocol;
document design using the HTML language;
the design of input forms.

We saw an example of how a client could send information to the web server. We did not cover how the server could

retrieve this information;
process it;
send the client a dynamic response based on the result of the processing.

This is the realm of web programming, a topic we will cover in the next chapter with an introduction to Spring technology MVC.