We use the technology of Java server pages for the dynamic pages. This page makes use of the query interpreter and shows the form and table from the server. As a first step in the development of the dynamic pages we made sure that we can work with Unicode. For this purpose the JSP page includes a @page contentType directive so that the response is generated in UTF-8. We will do our processing of a request without any sessions. Therefore we also use a @page session directive with the value false:

<%@page session="false"%><%@page contentType="text/html; charset=UTF-8"%>

The subsequent doc type tag informs the browser about the used HTML version. The title tag gives a title to the page. Everything in a dynamic page that is between <% and %> is only processed on the server side and not seen at the client side. So after the HTML page generation the only trace of our use of an UTF-8 encoding will be found in the http-equiv meta-tag. The page becomes self-contained concerning the encoding information.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html; charset=UTF-8" http-equiv="content-type">
  <title>Deployment Study - Servlet</title>

The HTML page has two different invocations. The first time the HTML page is invoked without parameters. The second time when the form has been filled it is invoked with the form field values submitted. The HTML page thus starts with conditionally reading off the parameters. The JSP page also includes a setCharacterEncoding() invocation so that a request in UTF-8 can be processed:

    String firstname;
    String name;
    String agefrom;
    String ageto;
    String salaryfrom;
    String salaryto;
    if (request.getParameter("search") != null) {
        firstname = request.getParameter("firstname");
        name = request.getParameter("name");
        agefrom = request.getParameter("agefrom");
        ageto = request.getParameter("ageto");
        salaryfrom = request.getParameter("salaryfrom");
        salaryto = request.getParameter("salaryto");

The generation of the HTML includes two parts. For the first responsibility of letting the end-user specify the search criteria, we will generate a form. This form basically consists of input fields for the search criteria. Similar to the terminal application and the standalone application we will use strings. Since these strings are now generated together with HTML of the form, we need to XML escape them to prevent cross side scripting. Here is an excerpt how the input fields for the name criteria and part of the age criteria are generated:

        <td colspan="4"><input name="name" type="text" size="12"
        <td><input style="text-align: right;" name="agefrom"
    type="text" size="3"

For the second responsibility of providing the query results to the end-user, we will generate a table. For this purpose the HTML page uses the data holder and the query interpreter. The sequence for the initialization thus first calls the data holder to initialize the knowledge base if necessary. It then retrieves the knowledge base from the class variable of the data holder. The table is only generated when parameters have been provided:

    if (request.getParameter("search") != null) {
        try {
  query =

The column headings of the table are now easily generated from the column identifiers returned by the query interpreter. The data cells of the table are then generated by iterating through the result rows. For number columns the data cell will be right aligned. String columns will receive the default left alignment of a data cell. The column headings and the data cells are both XML escaped:

            for (int i = 00; i < cols.length; i++) {
            for (int j = 0; j < rows.length; j++) {
                Object[] row = rows[j];
                for (int i = 0; i < row.length; i++) {
                    if (cols[i].endsWith("#")) {
%><td align="right"><%=matula.util.system.ForeignXml.sysTextEscape(
                    } else {

In XML escaping the column headings and the data cells we are overcautious here. We could argue that we know our data, and that XML escaping is not necessary since we know that our data does not contain XML sensitive characters. This might hold for the moment but in the long run the data could change. So when we do the coding already now we don’t have to do it later. And we can use XML sensitive characters any time in the data.