Guide to Web Development with Java -

Understanding Website Creation 2nd Edition Tim

Downey pdf download

https://textbookfull.com/product/guide-to-web-development-with-
java-understanding-website-creation-2nd-edition-tim-downey/

Download more ebook from https://textbookfull.com

We believe these products will be a great fit for you. Click
the link to download now, or visit textbookfull.com
to discover even more!

Learn Java for Web Development Modern Java Web

Development Layka Vishal

https://textbookfull.com/product/learn-java-for-web-development-
modern-java-web-development-layka-vishal/

Website Hosting and Migration with Amazon Web Services:

A Practical Guide to Moving Your Website to AWS 1st
Edition Jason Nadon (Auth.)

https://textbookfull.com/product/website-hosting-and-migration-
with-amazon-web-services-a-practical-guide-to-moving-your-
website-to-aws-1st-edition-jason-nadon-auth/

Web Development for beginners Learn HTML CSS Javascript

step by step with this Coding Guide Programming Guide
for beginners Website development 1st Edition Mastery

https://textbookfull.com/product/web-development-for-beginners-
learn-html-css-javascript-step-by-step-with-this-coding-guide-
programming-guide-for-beginners-website-development-1st-edition-
mastery/

Think Java How to Think Like a Computer Scientist 2nd

Edition Allen B. Downey

https://textbookfull.com/product/think-java-how-to-think-like-a-
computer-scientist-2nd-edition-allen-b-downey/
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/

Web App Development Made Simple with Streamlit A web

developer s guide to effortless web app development
deployment 1 / converted Edition Rosario Moscato

https://textbookfull.com/product/web-app-development-made-simple-
with-streamlit-a-web-developer-s-guide-to-effortless-web-app-
development-deployment-1-converted-edition-rosario-moscato/

Complete Vue js 2 Web Development Practical guide to

building end to end web development solutions with Vue
js 2 1st Edition Mike Street

https://textbookfull.com/product/complete-vue-js-2-web-
development-practical-guide-to-building-end-to-end-web-
development-solutions-with-vue-js-2-1st-edition-mike-street/

Tango With Django: A beginner’s Guide to Web

Development With Python / Django 1.9 1st Edition Leif
Azzopardi

https://textbookfull.com/product/tango-with-django-a-beginners-
guide-to-web-development-with-python-django-1-9-1st-edition-leif-
azzopardi/

The Definitive Guide to JSF in Java EE 8: Building Web

Applications with JavaServer Faces Bauke Scholtz

https://textbookfull.com/product/the-definitive-guide-to-jsf-in-
java-ee-8-building-web-applications-with-javaserver-faces-bauke-
scholtz/
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

ISSN 1868-0941 ISSN 1868-095X (electronic)

Texts in Computer Science
ISBN 978-3-030-62273-2 ISBN 978-3-030-62274-9 (eBook)
https://doi.org/10.1007/978-3-030-62274-9
1st edition: © Springer-Verlag London Limited 2012
2nd edition: © Springer Nature Switzerland AG 2021
This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part
of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations,
recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission
or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar
methodology now known or hereafter developed.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this
publication does not imply, even in the absence of a specific statement, that such names are exempt from
the relevant protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this
book are believed to be true and accurate at the date of publication. Neither the publisher nor the
authors or the editors give a warranty, expressed or implied, with respect to the material contained
herein or for any errors or omissions that may have been made. The publisher remains neutral with regard
to jurisdictional claims in published maps and institutional affiliations.

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.

Miami, USA Tim Downey

vii
Contents

1 Web Applications and Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Request Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Response Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Content Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Markup Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Hypertext Markup Language . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Basic Tags for a Web Page . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 What is the HT in HTML? . . . . . . . . . . . . . . . . . . . . . 12
1.3 HTML Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.1 Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Representing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3.3 Transmitting Data Over the Web . . . . . . . . . . . . . . . . . 19
1.4 Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1 Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.1 Maven Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.2 Maven Web Application . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.3 Maven from the Command Line . . . . . . . . . . . . . . . . . 24
1.5.4 Maven in an IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.5.5 Maven: Adding A Servlet Engine . . . . . . . . . . . . . . . . 26
1.6 Processing Form Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.1 JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.2 Initialising Form Elements . . . . . . . . . . . . . . . . . . . . . 30
1.7 The Truth About JSPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7.1 Servlet for a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7.2 Handling a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.8 Tomcat and IDEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.8.1 Web Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.10 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

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

3.7.5 Restructured Controller Analysis . . . . . . . . . . . . . . . . . 114

3.7.6 File Structure: Restructured Controller . . . . . . . . . . . . . 114
3.8 Model, View, Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.10 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.1 Spring Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.1.1 Power of Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.1.2 Injection Through Autowiring . . . . . . . . . . . . . . . . . . . 123
4.2 Application: Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.2.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2.2 Command Line Arguments . . . . . . . . . . . . . . . . . . . . . 133
4.2.3 Main Class: Command Line . . . . . . . . . . . . . . . . . . . . 133
4.3 Application: Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.3.1 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3.2 Servlets and Controllers . . . . . . . . . . . . . . . . . . . . . . . 137
4.3.3 Static Content Locations . . . . . . . . . . . . . . . . . . . . . . . 139
4.3.4 Location of the View Pages . . . . . . . . . . . . . . . . . . . . 139
4.3.5 Request Data Interface . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3.6 Bean Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.3.7 Singleton Controllers . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.3.8 Retrieving HTTP Variables . . . . . . . . . . . . . . . . . . . . . 150
4.4 Application: Spring Restructured Controller . . . . . . . . . . . . . . . 151
4.4.1 Modified Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.5 Maven Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.5.1 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.5.2 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.7 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5 Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.1 Eliminating Hidden Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.1.1 Session Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.1.2 Spring Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
5.1.3 Modifying the Controller . . . . . . . . . . . . . . . . . . . . . . 175
5.2 Controller Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.2.1 Encapsulating with Methods . . . . . . . . . . . . . . . . . . . . 179
5.2.2 Multiple Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.3 POST Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.3.1 POST Versus GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.3.2 Using Post . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
xii Contents

5.4 Replacing the Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

5.4.1 Adding to the Model . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.4.2 Model in a View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.4.3 Model in a Controller . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.5 Navigation Without the Query String . . . . . . . . . . . . . . . . . . . . 196
5.5.1 Using Path Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.5.2 Default Request Mapping . . . . . . . . . . . . . . . . . . . . . . 198
5.6 Session Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.6.1 Class Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.6.2 Parameter Annotation . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.6.3 Logical Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.6.4 Conversational Storage . . . . . . . . . . . . . . . . . . . . . . . . 204
5.6.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.7 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.7.1 Logback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.7.2 Configuring the Logger . . . . . . . . . . . . . . . . . . . . . . . . 207
5.7.3 Retrieving the Logger . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.7.4 Adding a Logger in the Bean . . . . . . . . . . . . . . . . . . . 212
5.8 Application: Enhanced Controller . . . . . . . . . . . . . . . . . . . . . . 213
5.8.1 Views: Enhanced Controller . . . . . . . . . . . . . . . . . . . . 214
5.8.2 Model: Enhanced Controller . . . . . . . . . . . . . . . . . . . . 216
5.8.3 Controller: Enhanced Controller . . . . . . . . . . . . . . . . . 218
5.9 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
5.10 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.11 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6 Validation and Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.1 Required Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
6.1.1 Regular Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.1.2 Required Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.2 Application: Required Validation . . . . . . . . . . . . . . . . . . . . . . . 240
6.2.1 Views: Required Validation . . . . . . . . . . . . . . . . . . . . 241
6.2.2 Model: Required Validation . . . . . . . . . . . . . . . . . . . . 242
6.2.3 Controller: Required Validation . . . . . . . . . . . . . . . . . . 243
6.3 Additional Binders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.3.1 Custom Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.3.2 Custom Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.4 Java Persistence API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.1 JPA Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
6.4.2 Persistent Annotations . . . . . . . . . . . . . . . . . . . . . . . . 256
6.4.3 Accessing the Database . . . . . . . . . . . . . . . . . . . . . . . 259
6.4.4 Data Persistence in Hibernate . . . . . . . . . . . . . . . . . . . 275
6.5 Application: Persistent Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Contents xiii

6.5.1 Views: Persistent Data . . . . . . . . . . . . . . . . . . . . . . . . 277

6.5.2 Repository: Persistent Data . . . . . . . . . . . . . . . . . . . . . 278
6.5.3 Controller: Persistent Data . . . . . . . . . . . . . . . . . . . . . 278
6.6 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
6.8 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
7 Advanced HTML and Form Elements . . . . . . . . . . . . . . . . . . . . . . 287
7.1 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.2 HTML Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
7.2.1 In-Line and Block Tags . . . . . . . . . . . . . . . . . . . . . . . 289
7.2.2 General Style Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
7.2.3 Layout Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
7.3 Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
7.3.1 Adding Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
7.3.2 Defining Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
7.3.3 Custom Layout with CSS . . . . . . . . . . . . . . . . . . . . . . 303
7.4 Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
7.4.1 Input Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
7.4.2 Textarea Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.4.3 Select Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
7.5 Spring Form Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7.5.1 Spring Input Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
7.5.2 Spring Textarea Tag . . . . . . . . . . . . . . . . . . . . . . . . . . 315
7.5.3 Spring Select Elements . . . . . . . . . . . . . . . . . . . . . . . . 315
7.5.4 Initialising Form Elements . . . . . . . . . . . . . . . . . . . . . 316
7.6 Bean Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.6.1 Bean Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
7.6.2 Filling the Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
7.6.3 Accessing Multiple-Valued Properties . . . . . . . . . . . . . 319
7.7 Application: Complex Elements . . . . . . . . . . . . . . . . . . . . . . . . 320
7.7.1 Controller: Complex Elements . . . . . . . . . . . . . . . . . . . 320
7.7.2 Views: Complex Elements . . . . . . . . . . . . . . . . . . . . . 321
7.7.3 Model: Complex Elements . . . . . . . . . . . . . . . . . . . . . 324
7.8 Validating Multiple Choices . . . . . . . . . . . . . . . . . . . . . . . . . . 326
7.9 Application: Complex Validation . . . . . . . . . . . . . . . . . . . . . . . 327
7.9.1 Model: Complex Validation . . . . . . . . . . . . . . . . . . . . 327
7.9.2 Views: Complex Validation . . . . . . . . . . . . . . . . . . . . 328
7.9.3 Controller: Complex Validation . . . . . . . . . . . . . . . . . . 329
7.10 Saving Multiple Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
7.11 Application: Complex Persistent . . . . . . . . . . . . . . . . . . . . . . . 332
7.11.1 Model: Complex Persistent . . . . . . . . . . . . . . . . . . . . . 332
7.11.2 Views: Complex Persistent . . . . . . . . . . . . . . . . . . . . . 332
xiv Contents

7.11.3 Repository: Complex Persistent . . . . . . . . . . . . . . . . . . 333

7.11.4 Controller: Complex Persistent . . . . . . . . . . . . . . . . . . 334
7.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
7.13 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
8 Accounts–Cookies–Carts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
8.1 Retrieving From The Database . . . . . . . . . . . . . . . . . . . . . . . . 344
8.1.1 Finding a Row . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
8.1.2 Validating a Single Property . . . . . . . . . . . . . . . . . . . . 346
8.1.3 Retrieving a Record . . . . . . . . . . . . . . . . . . . . . . . . . . 347
8.2 Application: Account Login . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
8.2.1 Model: Account Login . . . . . . . . . . . . . . . . . . . . . . . . 350
8.2.2 Views: Account Login . . . . . . . . . . . . . . . . . . . . . . . . 352
8.2.3 Controller: Account Login . . . . . . . . . . . . . . . . . . . . . 353
8.3 Removing Rows from the Database . . . . . . . . . . . . . . . . . . . . . 355
8.3.1 Delete Fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8.3.2 Delete Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
8.3.3 Controller: Delete Record . . . . . . . . . . . . . . . . . . . . . . 356
8.4 Application: Account Removal . . . . . . . . . . . . . . . . . . . . . . . . 357
8.4.1 Views: Account Removal . . . . . . . . . . . . . . . . . . . . . . 357
8.4.2 Controller: Account Removal . . . . . . . . . . . . . . . . . . . 357
8.5 Account Number in Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
8.5.1 Handler Modifications for the Path . . . . . . . . . . . . . . . 359
8.5.2 Model: Path Controller . . . . . . . . . . . . . . . . . . . . . . . . 362
8.5.3 Controller: Path Controller . . . . . . . . . . . . . . . . . . . . . 362
8.5.4 Views: Path Controller . . . . . . . . . . . . . . . . . . . . . . . . 364
8.6 Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
8.6.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
8.6.2 Cookie Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
8.7 Application: Cookie Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.7.1 View: Cookie Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
8.7.2 Showing Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
8.7.3 Setting Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
8.7.4 Deleting Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
8.7.5 Finding Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
8.7.6 Path Specific Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 372
8.8 Application: Account Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 373
8.8.1 Views: Account Cookie . . . . . . . . . . . . . . . . . . . . . . . 373
8.8.2 Controller: Account Cookie . . . . . . . . . . . . . . . . . . . . 374
8.9 Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
8.9.1 Cart Item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
8.9.2 Create Cart Item Database . . . . . . . . . . . . . . . . . . . . . 384
8.9.3 Model: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . 386
Contents xv

8.10 Application: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . 390

8.10.1 Design Choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
8.10.2 Controller: Browse . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
8.10.3 Controller: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . 393
8.10.4 Views: Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . 395
8.10.5 Shopping Cart: Enhancement . . . . . . . . . . . . . . . . . . . 400
8.11 Persistent Shopping Cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
8.12 Application: Persistent Shopping Cart . . . . . . . . . . . . . . . . . . . 402
8.12.1 Model: Persistent Shopping Cart . . . . . . . . . . . . . . . . . 402
8.12.2 Views: Persistent Shopping Cart . . . . . . . . . . . . . . . . . 403
8.12.3 Repository: Persistent Shopping Cart . . . . . . . . . . . . . . 405
8.12.4 Controller: Persistent Shopping Cart . . . . . . . . . . . . . . 405
8.13 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
8.14 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
9 Web Services and Legacy Databases . . . . . . . . . . . . . . . . . . . . . . . . 411
9.1 Application: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.1.1 Model: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . 412
9.1.2 Handler: Process Google Maps . . . . . . . . . . . . . . . . . . 413
9.1.3 Views: Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . 413
9.1.4 API Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
9.2 FedEx: Rate Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
9.2.1 Expanding the WSDL File . . . . . . . . . . . . . . . . . . . . . 416
9.2.2 FedEx: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
9.2.3 Application: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.2.4 Model: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
9.2.5 Views: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
9.2.6 Controller: FedEx . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
9.3 PayPal Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
9.3.1 Credentials: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
9.3.2 Application: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . 431
9.3.3 Controller: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
9.3.4 Views: PayPal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
9.3.5 Application: PayPal with Oauth . . . . . . . . . . . . . . . . . 434
9.4 Legacy Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
9.4.1 Eclipse Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
9.4.2 Install the Database Driver . . . . . . . . . . . . . . . . . . . . . 443
9.4.3 Hibernate Console . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
9.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
9.6 Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
10 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
10.1 Spring: Object Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
10.2 Classpath and Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
xvi Contents

10.2.1 Usual Suspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453

10.2.2 What is a Package? . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3.1 Configuring MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . 454
10.3.2 MySql Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
10.4 Old School . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
10.4.1 Validation the Hard Way . . . . . . . . . . . . . . . . . . . . . . 456
10.4.2 Initialising Complex Elements . . . . . . . . . . . . . . . . . . . 463
10.4.3 Application: Old SchoolInitialised Complex
Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
10.5 Source Code of Complicated Controllers . . . . . . . . . . . . . . . . . 480
10.5.1 Servlet for a JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
10.5.2 Controller Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
10.5.3 Restructured Controller . . . . . . . . . . . . . . . . . . . . . . . . 484
10.5.4 Spring Restructured Controller . . . . . . . . . . . . . . . . . . 485
10.5.5 Enhanced Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 486
10.5.6 Persistent Controller . . . . . . . . . . . . . . . . . . . . . . . . . . 488
10.5.7 Complex Persistent Controller . . . . . . . . . . . . . . . . . . . 490
10.5.8 Account Path and Shopping Cart . . . . . . . . . . . . . . . . . 493

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.

© Springer Nature Switzerland AG 2021 1

T. Downey, Guide to Web Development with Java, Texts in Computer Science,
https://doi.org/10.1007/978-3-030-62274-9_1
2 1 Web Applications and Maven

1.1 Hypertext Transfer Protocol

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

1.1.1 Request Format

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).

1.1.2 Response Format

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).

Table 1.1 Common request headers

User-agent Identifies the type of browser that made the request
Accept Specifies the MIME types that the browser prefers
Accept-language Indicates the user’s preferred language, if multiple versions of the
document exist
Accept-charset Indicates the user’s preferred character set. Different character sets can
display characters from different languages
4 1 Web Applications and Maven

Table 1.2 Common response headers

Server Identifies the type of server that made the response
Content-type Identifies the MIME type of the response
Content-length Contains the number of characters that are in the response

1.1.3 Content Type

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.

1.2 Markup Language

I am confident that most students have seen a markup language. I remember my

days in English composition classes: my returned papers would always have cryptic
squiggles written all over them (Fig. 1.2).
1.2 Markup Language 5

Fig. 1.2 Editors use markup to annotate text

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:

Moe: Oh, a wise guy, huh? <Pulls Larry’s hair>

Larry: It wasn’t me. <Hits Curly in the stomach>
Moe: What are you doing? <Tries to poke Curly in the eye>
Curly: Nyuk, nyuk, nyuk. <Places hand in front of eyes>
Moe: Ignoramus. <Bonks Curly on top of the head>

Every markup language has two parts.

a. The plain text

b. The markup, which contains additional information about the plain text.

1.2.1 Hypertext Markup Language

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:

<strong> This text is strong</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.

Table 1.3 Examples of singletons

Tag Explanation
<br> Insert a line break into the document
<input> Insert a form element into the document. This is a tag that has additional
attributes, which will be explained below

Table 1.4 Examples of paired tags

Tag Explanation
<strong> strong </strong> Typically, the enclosed text is rendered in a thicker
font
<ins> inserted </ins> Typically, the enclosed text is rendered with an
underline
<em> emphasised </em> Typically, the enclosed text is rendered in an italic font
<p> paragraph </p> The enclosed text will have at least one empty line
preceding it

Table 1.5 Two essential form element types

Type Example
text <input type=''text'' name=''hobby'' value=''''>
The value attribute is the text that appears within the element when the page is
loaded
submit <input type=''submit'' name=''nextButton'' value=''Next''>
The value attribute is the text that appears on the button in the browser
1.2 Markup Language 7

1.2.2 Basic Tags for a Web Page

We are very sophisticated listeners. We can understand many different accents. We

can understand when words are slurred together. However, if we were to write out
the phonetic transcription of our statements, they would be unreadable. There is a
correct way to write our language, but a sophisticated listener can detect and correct
many errors in pronunciation.
For instance, most English speakers would understand me if I asked the question
Jeet yet?
In print, it is incomprehensible. A proper response might be
No, joo?
Or,
Yeah, I ate.
As we become more proficient in a language, we are able to understand it, even
when people do not enunciate clearly.
In the same way, all markup languages have a format that must be followed in
order to be correct. Some language interpreters are more sophisticated than others
and can detect and correct mistakes in the written format. For example, a paragraph
tag in HTML is a paired tag and most browsers will render paragraphs correctly,
even if the closing paragraph tag is missing. The reason is that paragraph tags
cannot be nested one inside the other, so when a browser encounters a new <p> tag
before seeing the closing </p> for the current paragraph, the browser inserts a
closing </p> and then begins the new paragraph. However, if an XML interpreter
read the same HTML file with the missing </p> tag, the interpreter would report
an error instead of continuing to parse the file. It is better to code all the tags that are
defined for a well-formed HTML document, than to rely on browsers to fill in the
missing details.
Standard Tags
The HTML specification defines a group of standard tags that control the structure
of the HTML document. These three tags contain all the information for the page.

<html> html code </html>

The html tags enclose all the other tags and text in the document. It only contains
the following two sections.

<head> browser command tags </head>

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.

<title> title text </title>

The title tags enclose the text that will display in the title bar of the browser
window.

<meta charset = ''UTF-8''>

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.

i. Place a head section within the paired html tags.

A. Place a paired title tag within the head section.

B. Place a singleton meta tag for the character set within the head section.

ii. Place a body section 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>

Word Wrap and White Space

Most of us type text in a word processor and let the program determine where the
line breaks belong. This is known as word wrap. The only time that we are required
to hit the enter key is when we want to start a new paragraph.
Browsers will use word wrap to display text, even if the enter key is pressed.
Browsers will treat a new line character, a tab character and multiple spaces as a
10 1 Web Applications and Maven

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

Fig. 1.3 How the poem will appear in the browser

1.2 Markup Language 11

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.

1.2.3 What is the HT in HTML?

The HT in HTMLstands for Hypertext. Hypertext is the ability to click on a link in

one page and have another page open. If you have ever clicked on a link in a web
page to open another page, then you have used a hypertext link.
A hypertext linkhas two parts: the location of the new page and the link text that
appears in the browser. The location of the pages is specified as a Uniform Resource
Locator [URL], which contains four parts: protocol, server, path and name. The
protocol could be http, ftp, telnet or others. The protocol is followed by a colon and
two slashes (://). After the protocol is the server. The server is followed by a slash
and the path of the directory that contains the resource. The name of the resource
follows the path. protocol://server/path/name.
The URL of the hypertext link is not displayed in the web page, but it is
associated with the underlined text on the web page. Another way to say this is that
the URL has to be included in the markup, since it does not appear as plain text.
1.2 Markup Language 13

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>

Relative to the Root

If the resource is on the same server, but is not descended from the current
directory, then include the full path from the document root, starting with a /.
14 1 Web Applications and Maven

<a href=''/path/from/root/page.html''>
Some Page on the Current Server
</a>

In the Current Folder

If the resource is in the same directory as the HTML page that references it, then
only include the file name, not the server or the directory.

<a href=''page.html''>
Some Page
</a>

Descended from the Current Folder

If the resource is in a subdirectory of the directory where the HTML page that
references it is located, then include the name of the subdirectory and the file name.

<a href=''subdir/of/current/dir/page.html''>
Some Page in Some Subdir
</a>

References have three types.

a. Absolute
b. Relative from document root
c. Relative from current directory.

Just a few rules determine the kind of reference.

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.

Calculating Relative References

To calculate a relative reference, start with the absolute reference of the current
page and the absolute reference to the new page. For instance, suppose that the
current page and the next page are referenced as
https://www.bytesizebook.com/guide-boot/ch1/poem.html
https://www.bytesizebook.com/guide-boot/ch1/poem_formatted.html
 Another Random Document on
Scribd Without Any Related Topics
law in creating the Project Gutenberg™ collection. Despite these
efforts, Project Gutenberg™ electronic works, and the medium
on which they may be stored, may contain “Defects,” such as,
but not limited to, incomplete, inaccurate or corrupt data,
transcription errors, a copyright or other intellectual property
infringement, a defective or damaged disk or other medium, a
computer virus, or computer codes that damage or cannot be
read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except

for the “Right of Replacement or Refund” described in
paragraph 1.F.3, the Project Gutenberg Literary Archive
Foundation, the owner of the Project Gutenberg™ trademark,
and any other party distributing a Project Gutenberg™ electronic
work under this agreement, disclaim all liability to you for
damages, costs and expenses, including legal fees. YOU AGREE
THAT YOU HAVE NO REMEDIES FOR NEGLIGENCE, STRICT
LIABILITY, BREACH OF WARRANTY OR BREACH OF CONTRACT
EXCEPT THOSE PROVIDED IN PARAGRAPH 1.F.3. YOU AGREE
THAT THE FOUNDATION, THE TRADEMARK OWNER, AND ANY
DISTRIBUTOR UNDER THIS AGREEMENT WILL NOT BE LIABLE
TO YOU FOR ACTUAL, DIRECT, INDIRECT, CONSEQUENTIAL,
PUNITIVE OR INCIDENTAL DAMAGES EVEN IF YOU GIVE
NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of
receiving it, you can receive a refund of the money (if any) you
paid for it by sending a written explanation to the person you
received the work from. If you received the work on a physical
medium, you must return the medium with your written
explanation. The person or entity that provided you with the
defective work may elect to provide a replacement copy in lieu
of a refund. If you received the work electronically, the person
or entity providing it to you may choose to give you a second
opportunity to receive the work electronically in lieu of a refund.
If the second copy is also defective, you may demand a refund
in writing without further opportunities to fix the problem.

1.F.4. Except for the limited right of replacement or refund set

forth in paragraph 1.F.3, this work is provided to you ‘AS-IS’,
WITH NO OTHER WARRANTIES OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of
damages. If any disclaimer or limitation set forth in this
agreement violates the law of the state applicable to this
agreement, the agreement shall be interpreted to make the
maximum disclaimer or limitation permitted by the applicable
state law. The invalidity or unenforceability of any provision of
this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the

Foundation, the trademark owner, any agent or employee of the
Foundation, anyone providing copies of Project Gutenberg™
electronic works in accordance with this agreement, and any
volunteers associated with the production, promotion and
distribution of Project Gutenberg™ electronic works, harmless
from all liability, costs and expenses, including legal fees, that
arise directly or indirectly from any of the following which you
do or cause to occur: (a) distribution of this or any Project
Gutenberg™ work, (b) alteration, modification, or additions or
deletions to any Project Gutenberg™ work, and (c) any Defect
you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new
computers. It exists because of the efforts of hundreds of
volunteers and donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project
Gutenberg™’s goals and ensuring that the Project Gutenberg™
collection will remain freely available for generations to come. In
2001, the Project Gutenberg Literary Archive Foundation was
created to provide a secure and permanent future for Project
Gutenberg™ and future generations. To learn more about the
Project Gutenberg Literary Archive Foundation and how your
efforts and donations can help, see Sections 3 and 4 and the
Foundation information page at www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-
profit 501(c)(3) educational corporation organized under the
laws of the state of Mississippi and granted tax exempt status
by the Internal Revenue Service. The Foundation’s EIN or
federal tax identification number is 64-6221541. Contributions
to the Project Gutenberg Literary Archive Foundation are tax
deductible to the full extent permitted by U.S. federal laws and
your state’s laws.

The Foundation’s business office is located at 809 North 1500

West, Salt Lake City, UT 84116, (801) 596-1887. Email contact
links and up to date contact information can be found at the
Foundation’s website and official page at
www.gutenberg.org/contact
 Section 4. Information about Donations to
the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission
of increasing the number of public domain and licensed works
that can be freely distributed in machine-readable form
accessible by the widest array of equipment including outdated
equipment. Many small donations ($1 to $5,000) are particularly
important to maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws

regulating charities and charitable donations in all 50 states of
the United States. Compliance requirements are not uniform
and it takes a considerable effort, much paperwork and many
fees to meet and keep up with these requirements. We do not
solicit donations in locations where we have not received written
confirmation of compliance. To SEND DONATIONS or determine
the status of compliance for any particular state visit
www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states

where we have not met the solicitation requirements, we know
of no prohibition against accepting unsolicited donations from
donors in such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot

make any statements concerning tax treatment of donations
received from outside the United States. U.S. laws alone swamp
our small staff.

Please check the Project Gutenberg web pages for current

donation methods and addresses. Donations are accepted in a
number of other ways including checks, online payments and
credit card donations. To donate, please visit:
www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could
be freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose
network of volunteer support.

Project Gutenberg™ eBooks are often created from several

printed editions, all of which are confirmed as not protected by
copyright in the U.S. unless a copyright notice is included. Thus,
we do not necessarily keep eBooks in compliance with any
particular paper edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg
Literary Archive Foundation, how to help produce our new
eBooks, and how to subscribe to our email newsletter to hear
about new eBooks.
back
back
back
back
back
back
back
back
back
back
back
back
back
back
back
back
back
Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade

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.

Let us accompany you on the journey of exploring knowledge and

personal growth!

textbookfull.com