Head First Servlets and JSP, 2nd Edition

JSP is what happened when somebody introduced Java to HTML

Putting Java into HTML is a solution for two issues:

1 Not all HTML page designers know Java

App developers know Java. Web page designers know HTML. With JSP, Java developers can do Java, and HTML developers can do web pages.

2 Formatting HTML into a String literal is REALLY ugly

Putting even marginally complex HTML into the argument to a println() is a compiler error waiting to happen. You might have to do a ton of work to get the HTML formatted properly in a way that still works in the client’s browser, yet satisfies Java rules for what’s allowed in a String literal. You can’t have carriage returns, for example, yet most of the HTML you’ll pull from a web page editor will have real carriage returns in the source. Quotes can be a problem too—a lot of HTML tags use quotes around attribute values, for example. And you know what happens when the compiler sees a double quote... it thinks, “This must be the end of the String literal.” Sure, you can go back and replace each of your double quotes with escape codes... but it all gets insanely error prone.

Q:

Q: Wait... there’s still something wrong here! Benefit number one says “Not all page designers know Java...” but the HTML page designer still has to write Java inside the JSP page!! JSP lets the Java programmer off the hook for writing HTML, but it doesn’t really help the HTML designer. It might be easier to write HTML in a JSP rather than in a println(), but the HTML developer still has to know Java.

A:

A: Looks that way, doesn’t it? But with the new JSP spec, and by following best practices, the page designer should be putting very little (or no) real Java into a JSP. They do have to learn something... but it’s more like putting in labels that call real Java methods rather than embedding the actual Java code into the page itself. They have to learn JSP syntax, but not the Java language.

Bullet Points

• HTTP stands for Hypertext Transfer Protocol, and is the network protocol used on the Web. It runs on top of TCP/IP.

• HTTP uses a request/response model—the client makes an HTTP request, and the web server gives back an HTTP response that the browser then figures out how to handle (depending on the content type of the response).

• If the response from the server is an HTML page, the HTML is added to the HTTP response.

• An HTTP request includes the request URL (the resource the client is trying to access), the HTTP method (GET, POST, etc.), and (optionally) form parameter data (also called the “query string”).

• An HTTP response includes a status code, the content-type (also known as MIME type), and the actual content of the response (HTML, image, etc.)

• A GET request appends form data to the end of the URL.

• A POST request includes form data in the body of the request.

• A MIME type tells the browser what kind of data the browser is about to receive so that the browser will know what to do with it (render the HTML, display the graphic, play the music, etc.)

• URL stands for Uniform Resource Locator. Every resource on the web has its own unique address in this format. It starts with a protocol, followed by the server name, an optional port number, and usually a specific path and resource name. It can also include an optional query string, if the URL is for a GET request.

• Web servers are good at serving static HTML pages, but if you need dynamically-generated data in the page (the current time, for example), you need some kind of helper app that can work with the server. The non-Java term for these helper apps (most often written in Perl) is CGI (which stands for Common Gateway Interface).

• Putting HTML inside a println() statement is ugly and error-prone, but JSPs solve that problem by letting you put Java into an HTML page rather than putting HTML into Java code.