eveloping Web applications has come a long way since the first days of HTML when everything had to be coded by hand. I remember the days before there were smart server-side capabilities such as PHP or JSP when, if you wanted your Web site driven from a database, you had an application read the data and create static pages that you then linked into a navigation system. It was unwieldy, because every time your database changed, you had to regenerate the entire site.
As server-side technologies such as CGI, ASP, and others evolved, these pre-generated pages became a thing of the past. Instead, you could generate pages 'on-the-fly' by having the page query your database for you, based on the current context, and create the HTML code to display the information on-demand. This was a beautiful thing, separating your implementation from your data, so that changes in your data set (as mentioned above) wouldn't break your site.
This then led to the next issuepages written with these technologies were either written in code (such as C with CGI, or Java with Servlets) which contained lots of HTML-writing code snippets, or written with numerous code segments embedded in HTML (such as PHP or ASP). This led to problems as increasingly sophisticated Web page designs got harder and harder to 'activate' with data, and become increasingly brittle when dealing with change requests.
Here is where Jakarta Velocity comes inmaking it so you can have 'active' Web pages, but where the design and the implementation details are kept neatly separate through the use of templates. Using Velocity, a designer can design a page and put inactive placeholders on the page that the developer will use to activate the page. You'll see this by example a little later. It should be noted that this isn't the only use for Velocityit is in fact a generic template engine that can be used for outputting any kind of text, but Web pages are obviously a very useful example.
The problems that Velocity will help you to solve are perhaps best demonstrated with an example. Using a data-driven, Web-based report generation scenario, you'll work through the various methods that have been used to fully understand the drawbacks of doing it with the HTML-in-code approach of a servlet, the code-in-HTML approach of JSP or PHP, and the new option of template driven development that Jakarta Velocity offers.
Scenario: Sales Report
|Figure 1. Sample Sales Report: This is a report mockup, intended to show developers what a finished report should look like.|
The typical scenario for building a Web application is that the business owners for the application specify what they want, and how they want it to appear. A designer or artist then usually generates a mockup of the application's pages using an HTML design tool such as Microsoft FrontPage or Macromedia Dreamweaver, or a graphic editor such as Photoshop. In this example, the business owner wants an application to generate a sales report from a customer relationship management (CRM) database and an order tracking system, and he wants it to look similar to Figure 1
This report was mocked up with Microsoft FrontPage, so the sensible thing for a developer to do is to use its HTML as a starting point and embed the required on-demand data-driven information in it at runtime. You can see the mockup HTML in Listing 1.