Download full Guide to Web Development with Java - Understanding Website Creation 2nd Edition Tim Downey ebook all chapters
Download full Guide to Web Development with Java - Understanding Website Creation 2nd Edition Tim Downey ebook all chapters
com
https://textbookfull.com/product/guide-to-web-development-
with-java-understanding-website-creation-2nd-edition-tim-
downey/
OR CLICK BUTTON
DOWNLOAD NOW
https://textbookfull.com/product/learn-java-for-web-development-
modern-java-web-development-layka-vishal/
textboxfull.com
https://textbookfull.com/product/think-java-how-to-think-like-a-
computer-scientist-2nd-edition-allen-b-downey/
textboxfull.com
Flask Web Development Developing Web Applications With
Python 2nd Edition Miguel Grinberg
https://textbookfull.com/product/flask-web-development-developing-web-
applications-with-python-2nd-edition-miguel-grinberg/
textboxfull.com
https://textbookfull.com/product/tango-with-django-a-beginners-guide-
to-web-development-with-python-django-1-9-1st-edition-leif-azzopardi/
textboxfull.com
https://textbookfull.com/product/the-definitive-guide-to-jsf-in-java-
ee-8-building-web-applications-with-javaserver-faces-bauke-scholtz/
textboxfull.com
Texts in Computer Science
Tim Downey
Guide to Web
Development
with Java
Understanding Website Creation
Second Edition
Texts in Computer Science
Series Editors
David Gries, Department of Computer Science, Cornell University, Ithaca, NY,
USA
Orit Hazzan , Faculty of Education in Technology and Science, Technion—Israel
Institute of Technology, Haifa, Israel
More information about this series at http://www.springer.com/series/3191
Tim Downey
Guide to Web
Development with Java
Understanding Website Creation
Second Edition
123
Tim Downey
School of Computing
and Information Sciences
Florida International University
Miami, FL, USA
This Springer imprint is published by the registered company Springer Nature Switzerland AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
To Bobbi, my sweetheart, with all my love.
The magic continues.
Preface
This book is about developing web applications. Over the years, more and more
frameworks have appeared that hide the details of the communication between the
browser and the server. These packages are fantastic for developing applications,
but an understanding of the underlying process can help understand the reason that
frameworks do what they do.
In writing this book, I read the Spring documentation in detail and reviewed many
questions from Stack Overflow. The problems I encountered were that many sear-
ches did not return the most current version of documentation. Frequently, I had to
check that I wasn’t reading about version 1 features instead of version 5. Similarly,
many relevant answers to questions are buried deep in the search results, since older
answers have been around much longer and appear at the top of the search.
My hope is that this book will present material from the basics of HTML and
HTTP to the intricacies of web services in a step-by-step manner, adding only a few
details at a time. Some topics have multiple implementations that produce similar
results. I hope that the distinctions between these implementations are made clear.
The book develops a framework in the first few chapters and then switches to the
Spring framework for implementing websites. There are many frameworks on the
market. Spring is popular and Spring Boot is an excellent introductory package.
I want students to understand the actual details that a framework hides, and to use a
framework to solve problems. In the future, when they are introduced to other
frameworks, they will understand them better.
I am grateful to the community of web developers, who have provided all the
excellent tools for creating web applications: Apache, Tomcat, Hibernate, Java
Servlets, Java Server Pages, NetBeans, Eclipse, Log4j, Apache Commons, Google
web services, FedEx web services, PayPal web services, JBoss Community, Spring,
and Maven.
I am thankful to Bobbi, my sweetheart, for all of her love and support. Without
Bobbi, this book would not have been finished. I also want to thank Kip Irvine for
encouraging me to write. Without Kip, this book would not have been started.
vii
Contents
ix
x Contents
2 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.1 Sending Data to Another Form . . . . . . . . . . . . . . . . . . . . . . . . 46
2.1.1 Action Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.1.2 Hidden Field Technique . . . . . . . . . . . . . . . . . . . . . . . 49
2.1.3 Sending Data to Either of Two Pages . . . . . . . . . . . . . 53
2.2 Using a Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.2.1 Controller Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.2.2 JSP Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.2.3 JSPs Versus Servlets . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.4 Controller Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.2.5 Servlet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.2.6 Servlet Directory Structure . . . . . . . . . . . . . . . . . . . . . 71
2.2.7 Servlet Engine for a Servlet . . . . . . . . . . . . . . . . . . . . 74
2.3 Maven Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.3.1 Automatic Deployment . . . . . . . . . . . . . . . . . . . . . . . . 75
2.3.2 Debugging Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.5 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3 Java Beans and Member Variables . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.1 Application: Start Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.2 Java Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.2.1 Creating a Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.2.2 Using the Bean in a Web Application . . . . . . . . . . . . . 90
3.3 Application: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.1 Mapping: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.3.2 Controller: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.3.3 Data Access in a View . . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.4 Views: Data Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.4 Application: Default Validation . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4.1 Java Bean: Default Validation . . . . . . . . . . . . . . . . . . . 96
3.4.2 Controller: Default Validation . . . . . . . . . . . . . . . . . . . 98
3.5 Member Variables in Servlets . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.1 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.5.2 The Problem with Member Variables . . . . . . . . . . . . . 100
3.5.3 Local Versus Member Variables . . . . . . . . . . . . . . . . . 103
3.6 Application: Shared Variable Error . . . . . . . . . . . . . . . . . . . . . 104
3.6.1 Controller: Shared Variable Error . . . . . . . . . . . . . . . . 104
3.7 Application: Restructured Controller . . . . . . . . . . . . . . . . . . . . 107
3.7.1 Creating the Helper Base . . . . . . . . . . . . . . . . . . . . . . 108
3.7.2 Creating the Controller Helper . . . . . . . . . . . . . . . . . . 109
3.7.3 Views: Restructured Controller . . . . . . . . . . . . . . . . . . 112
3.7.4 Controller: Restructured Controller . . . . . . . . . . . . . . . 114
Contents xi
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Web Applications and Maven
1
This chapter explains how information is sent between a browser and a server. It
begins with descriptions of the request from a browser and a response from a server.
Each has a format that is determined by the Hypertext Transfer Protocol [HTTP].
Basic HTML tags are introduced next, followed by HTML forms for collecting
data. Data is easily passed from one page to another, but the data cannot be
processed without a dynamic engine like a servlet engine. Maven is introduced as a
development environment that easily incorporates a servlet engine into an appli-
cation. Using Maven, a web server can be started that hosts a web application that
can be compiled and run. The chapter explains markup languages, with a detailed
description of the Hypertext Markup Language [HTML], which sends formatted
content from the server to the browser. An important feature of HTML is its ability
to easily request additional information from the server through the use of hypertext
links. HTML forms are covered. These send data from the browser back to the
server. Information from the form must be formatted so that it can be sent over the
web. The browser and server handle encoding and decoding the data.
Simple web pages cannot process form data that is sent to them. One way to
process form data is to use a web application and a Java Server Page [JSP]. In a
JSP, the Expression Language [EL] simplifies access to the form data and can be
used to initialise the form elements with the form data that is sent to the page.
JSPs are processed by a program known as a servlet engine. The servlet engine
receives the request and response data from the web server and processes the
request from the browser. The servlet engine translates all JSPs into programs
known as servlets.
Servlets and JSPs must be run from a servlet engine. Maven has the ability to
embed a Tomcat servlet engine into the application.
Whenever someone accesses a web page on the Internet, two computers commu-
nicate. One computer has a software program known as a browser, the other
computer has a software program known as a web server. The browser sends a
request to the server and the server sends a response to the browser. The request
contains the name of the page that is being requested and information about the
browser that is making the request. The response contains the page that was
requested (if it is available), information about the page, and information about the
server. Figure 1.1 depicts the aspects of the request and response.
When the browser makes the request, it mentions the protocol that it is using:
HTTP/1.1. When the server sends the response, it also identifies the protocol it is
using: HTTP/1.1. A protocol is not a language; it is a set of rules that must be
followed. For instance, one rule in HTTP is that the first line of a request will
contain the type of request, the address of the page on the server and the version of
the protocol that the browser is using. Another rule is that the first line of the
response will contain the version of the protocol that the server is using, a numeric
code indicating the success of the request and a sentence describing the code.
Protocols are used in many places, not just with computers. When the leaders of
two countries meet, they must decide on a common protocol in order to commu-
nicate. Do they bow or shake hands when they meet? Do they eat with chopsticks or
silverware? It is the same situation for computers, in order for the browser and
server to communicate, they must decide on a common protocol.
Fig. 1.1 The request and response have specific formats, as specified by HTTP
1.1 Hypertext Transfer Protocol 3
The request from the browser has the following format in HTTP:
a. The first line contains the type of request, the name of the requested page and
the protocol that is being used.
b. Subsequent lines are the request headers. They contain information about the
browser and the request.
c. A blank line in the request indicates the end of the request headers
d. In a POST request, additional information can be included after the blank line.
Typical information that is contained in the request headers is the brand of the
browser that is making the request, the types of content that the browser prefers, the
languages and character set that the browser prefers and the type of connection that
is being used. The names of these request headers are User-agent, Accept,
Accept-language and Accept-charset, respectively (Table 1.1).
The response from the server has the following format in HTTP:
a. The first line contains the protocol being used, the status code and a brief
description of the status.
b. Subsequent lines are the response headers. They contain information about the
server and the response.
c. A blank line in the response indicates the end of the response headers.
d. In a successful response, the content of the page will be sent after the blank line.
Typical information that is contained in the response headers is the brand of the
server that is making the response, the type of the file that is being returned and the
number of characters that are in the file. The names of these response headers are
Server, Content-Type and Content-length, respectively (Table 1.2).
The server must also identify the type of information that is being sent. This is
known as the Content Type. Different content types define text, graphics, spread-
sheets, word processors and more.
These content types are expressed as Multipurpose Internet Mail Exten-
sions [MIME] types. MIME types are used by web servers to declare the type of
content that is being sent. MIME types are used by the browser to decode the type
of content that is being received. If additional data is included with the request, the
browser uses special MIME types and additional request headers to inform the
server. The server and browser will each contain a file that has a table of MIME
types with the associated file extension for that type.
The basic structure of a MIME type is a general type, a slash and a specific type.
For example, the general type for text has several specific types, for plain text,
HTML text and style sheet text. These types are represented as text/plain, text/html
and text/css, respectively. When the server sends a file to the browser, it will also
include the MIME type for the file in the header that is sent to the browser.
MIME types are universal. All systems have agreed to use MIME types to
identify the content of a file transmitted over the web. File extensions are too
limiting for this purpose. Many different word processor programs might use the
extension .doc to identify a file. For instance, .doc might refer to an MS WORD
document or to an MS WORDPAD document. It is impossible to tell from the
extension which program actually created the program. In addition, other programs
could use the .doc extension to identify a program: for instance, WordPerfect could
also use the .doc extension. Using the extension to identify the content of the file
would be too confusing.
The most common content type on the web is HTML text, represented as the
MIME type text/html.
Some of these would mean that a word was omitted (^), that two letters were
transposed (a sideways '' S ',' enclosing the transposed letters), or that a new para-
graph was needed (a backwards, double-stemmed '' P '). ' These marks were invalu-
able to the teacher who had to correct the paper because they conveyed a lot of
meaning in just a few pen strokes. Imagine if a program could accept such a paper
that is covered with markup, read the markup and generate a new version with all
the corrections made.
There are other forms of markup languages. The script of a play has a markup
language that describes the action that is proceeding while the dialog takes place.
For instance, the following is a hypothetical script for the 3 Stooges:
HTML is the markup language for the web. It is what allows the browser to display
colours, fonts, links and graphics. All markup is enclosed within the angle brack-
ets <and>. Directly adjacent to the opening bracket is the name of the tag. Addi-
tional attributes can be included after the name of the tag and before the closing
bracket.
HTML tags are intermixed with plain text. The plain textis what the viewer of a
web page will see. The HTML tags are commands to the browser for displaying the
6 1 Web Applications and Maven
text. In this example, the plain text ‘This text is strong’ is enclosed within the
HTML tags for making text look strong:
The viewer of the web page would not see the tags, but would see the text
rendered strongly. For most browsers, strong text is bold, and the sentence would
appear as:
This text is strong
HTML has two types of tags: singletons and paired tags.
Singletons have a limited amount of text embedded within them as attributes or
they have no text at all. Singletons only have one tag. Table 1.3 gives two examples
of singleton tags.
Paired tags are designed to contain many words and other tags. These tags have an
opening and a closing tag. The text that they control is placed between the opening and
closing tags. The closing tag is the same as the opening tag, except the tag name is
preceded by a forward slash /. Table 1.4 gives four examples of paired tags.
The html tags enclose all the other tags and text in the document. It only contains
the following two sections.
The head tags enclose tags that inform the browser about how to display the
entire page. These control how the page appears in the browser, but do not
8 1 Web Applications and Maven
contain any content for the page. This paired tag belongs within the paired html
tags.
<body> body tags </body>
The body tags contain all the plain text and HTML tags that are to be displayed
in the browser window. This paired tag belongs within the paired html tags.
While the body section contains the normal HTML tags discussed in this chapter,
like strong and em, the head section contains special markup tags that indicate
how the browser should display the page. The meta and title tags belong in the head
section.
The title tags enclose the text that will display in the title bar of the browser
window.
The meta tag is a singleton that indicates extra information for the browser. This
tag can be repeated to include different information for the browser. A standard
page should include a meta tag with charset='' utf-8 '.' This indicates the character
set for the language that is being used to display the page.
HTML Validation
The WWW Consortium [W3C] publishes the HTML standard and provides tools for
HTML validation that will test that a page has the correct HTML structure. In order
to comply with the HTML specification, all web pages should have the following
structure.
<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>Simple Page</title>
</head>
<body>
<p>
This is a <em>simple</em> web page.
</body>
</html>
a. The DOCTYPE defines the type of markup that is being used. It precedes the
html tag because it defines which version of HTML is being used.
1.2 Markup Language 9
b. All the tags and plaintext for the page are contained within the paired html
tags.
c. The DOCTYPE and meta tags are required if the page is to be validated by W3C
for correct HTML syntax. Go to https://www.w3.org to access the HTML
validator.
There is no excuse for a web page to contain errors. With the use of the vali-
dation tool at https://www.w3.org, all HTML pages should be validated to ensure
that they contain all the basic tags.
Layout versus Style
Two types of information are contained in each HTML page: layout and style. The
basic layout is covered in this chapter; advanced layout and style are covered in
Chap. 7. Style information contains things like the colours and font for the page.
The recommended way to handle style and layout is to place all the layout tags in
the HTML page and to place all the style information in a separate file, called a
style sheet. For the interested student, the HTML and style information from
Chap. 7 can be read at any time.
Hypertext Markup Language Five [HTML5] is the latest version of the HTML
standard. In the previous versions, tags could specify the style of a page. In the new
version, those tags have been deprecated. In order to validate that a page conforms
to version 5, the tags that specify specific style cannot be used.
In previous versions of the HTML standard, different DOCTYPE statements
could be used for HTML pages: strict and transitional. The strict one was the
recommended one, since it enforced the rule that all style information be contained
in a separate file. Version five has no choices for the DOCTYPE: all pages must use
strict HTML. All pages for this book will use the new DOCTYPE for HTML5.
<!DOCTYPE HTML>
single space. In order to insert a new line, tab or multiple spaces in an HTML page,
markup must be used: if it is not plain text, then it must be placed in markup.
Browsers take word wrap one step further. Browsers will compress all con-
secutive white space characters into a single space character. The common white
space characters are the space, the tab and the new line character. If five spaces start
a line, they will be compressed into one space.
The following listing contains a web page that has a poem.
<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>A Poem</title>
</head>
<body>
Roses are red
Violets are blue
This could be a poem
But not a haiku
A haiku has a fixed structure. The first line has five
syllables, the second line has seven syllables and the
third line has five syllables. Therefore, the previous
poem cannot be a haiku.
</body>
</html>
Even though the poem has four lines, the poem will appear as one line in the
browser. This is because no markup was added to indicate that one line has ended
and another line should begin. The browser will wrap to a new line if the poem
would extend beyond the right margin of the browser.
Try It
https://bytesizebook.com/guide-boot/ch1/poem.html
Open the link in a browser and view the poem (Fig. 1.3). Resize the window and
note how the browser will break the text in different places. If the window is large
enough, the entire page will be displayed on one line.
Line Breaks
Two of the tags that can start a new line are <br> and <p>. The <br> tag is short
for breakand starts a new line directly under the current line. It is a singleton tag, so
it does not have a closing tag. The <p> tag is short for paragraphand skips at least
one line and then starts a new line. It is a paired tag, so it is closed with
the </p> tag.
As was mentioned above, browsers have the ability to interpret HTML even if
some tags are missing. The closing paragraph tag is such a tag. It is not possible to
nest one paragraph inside another, so if the browser encounters two paragraph tags
without closing tags, as in <p> One <p> Two, then it will interpret this as <
p> One </p> <p> Two </p>. Even the validators at w3.org will accept HTML
that does not have closing paragraph tags.
Listing 1.1 contains the HTML page for the poem, using markup for line breaks
and paragraph tags.
<!DOCTYPE HTML>
<html>
<head>
<meta charset=''utf-8''>
<title>A Poem</title>
</head>
<body>
<p>
Roses are red<br>
Violets are blue<br>
This could be a poem<br>
But not a haiku<br>
<p>
A haiku has a fixed structure. The first line has five
syllables, the second line has seven syllables and the
third line has five syllables. Therefore, the previous
poem cannot be a haiku.
</body>
</html>
Listing 1.1 A four-line poem with markup for line breaks HTML
12 1 Web Applications and Maven
Fig. 1.4 How the formatted poem will appear in the browser
When displayed in a browser, each line of the poem will appear on a separate line.
The paragraph that follows the poem will still be displayed using word wrap, since
no line breaks were inserted into it.
Try It
https://bytesizebook.com/guide-boot/ch1/poem_formatted.html
Open the page in a browser to see how it looks (Fig. 1.4). Resize the window and
note that the poem displays on four lines, unless the window is very small.
Most browsers have an option for viewing the actual HTML that was sent from
the server. If you view the source, you will see the same HTML code that was
displayed in Listing 1.1.
Anchor Tag
The tag for a hypertext link is the paired tag <a> , which is short for anchor.
<a href=''hidden_URL_of_a_file''>
Visible text in browser
</a>
Note that the text that is visible in the browser is not inside a tag, but that the
URL of the file is. This is an example of a tag that has additional information stored
in it. The additional information is called an attribute. The URL of the page is
stored in an attribute named href. Attributes in HTML tags provide extra infor-
mation that is not visible in the page in the browser.
This agrees with the basic definition of HTML as having plain text and tags. The
tags contain extra information about how to display the plain text. In this case,
when the user clicks on the plain text, the browser will read the URL from the href
and request that page from the server.
It may not seem apparent why this tag is called an anchor tag. An anchor tag in
HTML is like the anchor of a ship. The anchor for a ship connects two parts: the
ship, which is visible from the surface of the water, and the bottom of the ocean.
When the anchor is in use, it is not in the ship, it is in the bottom of the ocean. The
anchor HTML tag connects the visible text in the browser to the physical location
of a file.
Absolute and Relative References
The href attribute of the anchor tag contains the URL of the destination page. When
using the anchor tag to reference other pages on the web, you must know the
complete URL of the resource in order to create a link to it. However, depending on
where the resource is located, you may be able to simplify the address of the page
by using a relative reference.
Absolute
If the resource is not on the same server, then you must specify the entire URL,
starting with http://. This is known as an absolute reference.
<a href=''https://server.com/path/page.html''>
Some Page Somewhere on the web
</a>
<a href=''/path/from/root/page.html''>
Some Page on the Current Server
</a>
<a href=''page.html''>
Some Page
</a>
<a href=''subdir/of/current/dir/page.html''>
Some Page in Some Subdir
</a>
a. Absolute
b. Relative from document root
c. Relative from current directory.
a. If the URL begins with a protocol (like http://, ftp://, or telnet://), then it is an
absolute reference to that location.
b. If the URL begins with a /, then it is a relative reference from the document root
of the current server.
c. In all other cases, the URL is a relative reference from the current directory.
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
textbookfull.com