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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
|Secure Server Deployments in Hostile Territory, Part II||Jul 29, 2015|
|Hacking a Safe with Bash||Jul 28, 2015|
|KDE Reveals Plasma Mobile||Jul 28, 2015|
|Huge Package Overhaul for Debian and Ubuntu||Jul 23, 2015|
|diff -u: What's New in Kernel Development||Jul 22, 2015|
|Shashlik - a Tasty New Android Simulator||Jul 21, 2015|
- Secure Server Deployments in Hostile Territory, Part II
- Hacking a Safe with Bash
- KDE Reveals Plasma Mobile
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- General Relativity in Python