Last month, we wrote some simple servlets that allow us to create and view a web log, sometimes known as blog. Since JSPs are translated into servlets, there is no reason why we cannot create a JSP that accomplishes the same thing as that servlet. It will obviously look a bit different, but the effect should be the same.
Listing 5 contains a JSP (showblog.jsp) that performs the same task as the ShowBlog servlet from last month. In other words, this JSP prints the contents of my web log, as stored in a PostgreSQL database table, sorted from the newest entry to the oldest.
I should note right now that showblog.jsp is a terrible example of how to write JSPs; it is simply meant to demonstrate what is possible, not what is elegant or best. (We'll discuss such issues over the next two months, when we discuss JavaBeans and custom tag libraries.)
Let's go through this JSP, so that you can see exactly how it works.
We begin with two “page” directives. These directives allow us to set up the basic configuration for our JSP, beginning with the MIME ContentType header the page will return, and even permit us to specify the programming language to be interspersed with the nonprogrammatic text. While such functionality does not actually exist, it's theoretically possible to write JSPs that use Perl to produce XML, or Python to produce PNG images.
Notice how we can name one or more attributes in our page directive. The first line of showblog.jsp sets both the language and the ContentType attributes. The second line indicates that the resulting servlet should import the packages within java.sql, which will allow us to connect to our relational database server (PostgreSQL in this case) using JDBC.
After a tiny bit of introductory HTML, we drop deep into Java. We create an SQL connection object and use it to connect to our PostgreSQL server. We retrieve data from the database, and then iterate over the ResultSet on a row-by-row basis.
As I indicated above, this is a terrible way to write JSPs. Not only will the performance be terrible because of the many database connections being created and destroyed, but we have created a horrible mishmash of code and HTML. Indeed, the only thing we seem to have saved here is a bit of effort writing out.println() for producing HTML output.
Moreover, much of the intent behind JSPs is to remove code from the HTML pages, allowing nonprogrammers to create dynamic pages with a minimum of effort. If we must insert this much code in order to create dynamic pages, chances are fairly slim that a nonprogrammer will want to try their hand at web development.
Moreover, our translation of the ShowBlog servlet to a JSP resulted in the removal of several exception-handling routines. Our servlet was intelligent enough to handle the disappearance of the PostgreSQL server and could produce a reasonable error message. Our JSP, by contrast, produced a backtrace containing error messages. This backtrace is useful for developers but is neither friendly nor useful for the end user who will visit our site (in all fairness, we can set the errorPage attribute in the page directive, such that errors are forwarded to a different JSP).
A good solution would remove as much code as possible from JSPs, allowing nonprogrammers to make use of that code in a standard way and separating the programmatic and nonprogrammatic content. And indeed, JSPs come with support for JavaBeans, where each “bean” is actually an object with a variety of methods we can use from within a JSP, using special <jsp: > actions. The trick to a successful JSP deployment depends on, in no small part, an intelligent use of JavaBeans. Moreover, JSPs allow us to create our own tag libraries defining custom actions, so that we can replace even more code with tags that resemble the assorted <jsp: > actions.
JavaServer Pages, or JSPs, provide a coating of syntactic sugar around servlets, which can sometimes be difficult for nonprogrammers to learn. However, this month's most complex example of a JSP demonstrates that they can easily get out of control, containing close to as much code as a typical servlet. While it is easier to work with JSPs overall, the supposed benefits of separate code from HTML fall by the wayside as the JSPs get more complex.
Next month, we will look at JavaBeans, which allow us to push quite a bit of programming to classes defined and maintained outside of the JSP. Following that, we will look at JSP's custom tag libraries, which make it possible to create our own little languages for use inside of our JSPs.
- Android Candy: Google Keep
- Handling the workloads of the Future
- How Can We Get Business to Care about Freedom, Openness and Interoperability?
- Readers' Choice Awards 2014
- diff -u: What's New in Kernel Development
- Days Between Dates?
- Synchronize Your Life with ownCloud
- A five year deal with Microsoft to dump Novell/SUSE
- Computing without a Computer
Editorial Advisory Panel
Thank you to our 2014 Editorial Advisors!
- Jeff Parent
- Brad Baillio
- Nick Baronian
- Steve Case
- Chadalavada Kalyana
- Caleb Cullen
- Keir Davis
- Michael Eager
- Nick Faltys
- Dennis Frey
- Philip Jacob
- Jay Kruizenga
- Steve Marquez
- Dave McAllister
- Craig Oda
- Mike Roberts
- Chris Stark
- Patrick Swartz
- David Lynch
- Alicia Gibb
- Thomas Quinlan
- Carson McDonald
- Kristen Shoemaker
- Charnell Luchich
- James Walker
- Victor Gregorio
- Hari Boukis
- Brian Conner
- David Lane