The problem

When I worked at ESRI, I worked on the .net version of ArcGIS Server Manager, which is a web-based front-end for ESRI’s ArcGIS Server products. The Java team also has a Java version of the product based on the same UI spec. I was the only .net developer on the .net version while the Java team had 2 ½ developers on the Java version, but I was constantly ahead in features. I was proudly thinking that I am a much better developer than my peers on the Java team.

However, a recent project changed my thinking. My current employer is migrating some VB6 based projects to Java. I developed a web service in Java. At the end of project, I have some time left. So I decide to develop a few simple CRUD pages for the configuration table. The idea is fairly simple: I want to develop a page that lists the records in the table. It has a single form at the end of the page that allows me to insert a new record, as seen in the picture below:

When I try to edit the record, the page will enter the edit mode. The row that I try to edit would contain some textboxes. The edit/delete link would change to update and cancel. The insert form would be hiden, as seen in the picture below:

 

This is a fairly standard feature in asp.net. I can develop a page like this in a few clicks in less than an hour. However, in Java/JSP, I search the Google with words like “Java and RAD” but could not find any rapid application development solution that is simple to use.

The solution

I did a survey on how Java developers do similar things with JSP. JSP allows scriptlets, like ASP developers embed script inside the ASP page. However, it is not good practice to embed lots of code in the contents page. Servlet is a good place for code. You cannot embed Servlet in an JSP page. A typical pattern is that people will have a page post to a Servlet (controller) to do all the processing. The servlet will then forward/redirect to a JSP page (View) to display the result. That is a good practice except the view could need lots of scriptlets if there are lots of conditional rendering. It is possible to embed Java Bean in JSP. However, Java Bean does not have access to Http context. To gain access to the Http context, one would have to develop custom Jsp tags.

Since my goal is to develop a CRUD page that allows me to edit an simple table, here is the design approach that I take. I have one JSP page and 3 servlets. The 3 servlets are used for handling insert, delete and update. The JSP is reponsible for displaying the data. It also contains scriplets to switch between normal and edit mode:

1. Normal mode: Display the table normally. Show the insert form.
2. Edit mode: Display the row being edited as textboxes. Display the button of the row as Update and Cancel. Hide the insert form.

Here is the code:

boolean editMode = (request.getParameter("kc") != null);

if (editMode) {

    action = "updateConfig?kc=" + request.getParameter("kc") + "&kk=" + request.getParameter("kk");

} else {

    action = "addConfig";

}

<form action="<%= action %>" method="post">

    <table>

        <tr>

            <th>Configurationth>

            <th>Keyth>

            <th>Valueth>

            <th>th>

        tr>

<%

while(rs.next()) {

%>

<% if (editMode && rs.getString("CONFIG_NAME").equals(request.getParameter("kc")) && rs.getString("KEY").equals(request.getParameter("kk"))) {%>

        <tr>

            <td><%= rs.getString("CONFIG_NAME") %>td>

            <td><INPUT type="text" name="key" size="20" maxlength="64" value='<%= rs.getString("KEY") %>'>td>

            <td><INPUT type="text" name="value" size="20" maxlength="254" value='<%= rs.getString("VALUE") %>'>td>

            <td><INPUT type="submit" value="update"><a href='config.jsp'>cancela>td>

        tr>

<% } else { %>

        <tr>

             <td><%= rs.getString("CONFIG_NAME") %>td>

             <td><%= rs.getString("KEY") %>td>

             <td><%= rs.getString("VALUE") %>td>

             <td>

                 <a href='config.jsp?kc=<%= rs.getString("CONFIG_NAME") %>&kk=<%= rs.getString("KEY") %>'>edita>

                 <a href='deleteConfig?kc=<%= rs.getString("CONFIG_NAME") %>&kk=<%= rs.getString("KEY") %>'>deletea>

             td>

         tr>

<% }

}

%>

<% if (!editMode) {%>

         <tr>

             <td><INPUT type="text" name="configName" size="20" maxlength="64">td>

             <td><INPUT type="text" name="key" size="20" maxlength="64">td>

             <td><INPUT type="text" name="value" size="20" maxlength="254">td>

             <td><INPUT type="submit" value="insert">td>

          tr>

<% } %>

      table>

form>

I felt that I go back 10 years in time and become an asp programmer again. So here is what I think why at ESRI my peers on the Java team are so much slower than me:

1. JSP does not have an efficient method like code-behind in asp.net that allows close interaction between code and view.
2. The MVC frameworks like Struts that is main stream in Java community tend to product large number of classes for simply thing. Also the MVC promotes separation of responsibility and reuse at the first glance. However, in real life, only a small number of classes are actually reused; most of classes are only used once. The large number of classes create problems in both naming and finding things. In ASP.NET, it is far more easier to work with things and find code.
3. JSP lacks a component model to work with non-HTML controls. Here the non-HTML control means a sophiscated control like Tree that is composed of html, images, css. Its behavior is manipulated by Javascript and DHTML and states often saved in a hidden control. JSP and MVC framework like Struts can only handle native HTML controls. The rich components are handled outside of framework. Therefore, I would say that JSP is about half way between asp and asp.net. For an asp.net developer to work on JSP, it is like going back to stone page.
4. I hope JSF will provide a rich component model that rivals that of ASP.NET. Unfortunately, both the development and the adoption have been so slow. It does not help that our company is still standardized on J2EE 1.4.