One of my main interests right now is web application development. About 8 or 9 years ago I created my first simple web application (just a few pages) as an ISAPI DLL. I was not paying any attention to HTML standards at this time. It didn’t seem like many people were. I don’t think I even knew what CSS was back then.
More recently I worked on a web application in Java using Struts. This project was done under great time pressure and there was little time to investigate different frameworks. Struts seemed a safe bet just by its reputation. By that time I was aware of web standards and the importance of following them. Still there wasn’t much time to learn all the details but we tried. Working with Struts had its frustrations but looking back Struts was a good choice for this project.
After this I got a chance to learn C# and .NET. I didn’t get much hands on experience but learned a little. This was my first exposure to view state and it struck me as a bad idea then and I haven’t changed my mind about it yet. We had to work with an in-house developed web UI framework on top of .NET. For simple things it was very simple but anytime you wanted to do something more interesting it got extremely difficult.
I decided to do some investigation in web application development. I wanted to get a feel for some of the different frameworks as well as to learn more details about doing HTML and CSS the right way. The idea was to create a very simple web app with a few different sets of technologies. It only needed two pages but it should also have some depth so that I could get a feel for internationalization, error handling and reporting, input validation, and separation of presentation from business logic.
The app is very simple as I said. It prompts for two numbers then on submit displays a page that shows their sum and difference with a link to go back to the first page. To explore input validation a little more I later added a radio button group to constrain the input numbers to both be even, both be odd or allow any numbers.
I had already worked with Struts so there was no need to investigate it any more. I also didn’t feel a strong need to try other Model 2 frameworks similar to Struts. I may go back and look at some of these later. I choose Java Server Faces (JSF) + Facelets, Servlet + StringTemplate, and raw servlet as a baseline. I was very interested in JSF because of the buzz about it. I choose StringTemplate because the paper “Enforcing Strict Model-View Separation in Template Engines” really resonated with me.
I used the latest Tomcat and MySQL mostly because I had used older versions of them in the past and liked them. I was going to be learning many new things and didn’t need to learn a new servlet engine and database. I also wanted to use the new JDK 5.0.
One of the first things I learned was that JSF 1.2 doesn’t work with Tomcat 5 because JSF 1.2 requires the latest JSTL. From what I read it didn’t seem worth it to use an older version of JSF. Also I didn’t want to switch to GlassFish because it would be something additional to learn. I wanted to stick with Tomcat if at all possible. I found that JSF 1.2 could be used with Tomcat 5 if you use Facelets rather than JSP. After reading more it seems to me that Facelets are the way to go anyway – much better than JSP + JSF.
The simple app went together quickly with most of the time spent learning JSF and getting my environment set up (for example installing a bunch of plugins to Eclipse for web development).
The next thing I learned about JSF was that, like .NET, it uses view state. When I looked at the generated HTML for my simple page with two labels, two edit controls, and a button I found a hidden input for the view state that was 1873 bytes. All this for a page that was 3280 bytes in total. The view state accounted for more than half the size. My simple application didn’t need any of this overhead.
JSF has built-in support for i18n of text strings that uses standard Java resource bundles and the Facelets tags h:outputText and h:outputFormat. Simple validation is also very easy, but all validation is done server side which is not the best thing to do. Client side validation can be done but requires more work (I didn’t bother).
I wanted to explore how to do complicated validation such as when the value of one control depends on the value of another (this is when I added the radio control). This caused a problem because the UI has no idea about the dependencies in the backing bean. So how do you do validation in the backing bean when the validation depends on other fields that will not be updated until all validation passes? I solved the problem by using a change listener on the radio button group. When it changed I updated the model constraints field. This did not work correct at first because the listener was being called after the validation. I had to also use the immediate attribute on the selectOneRadio control. I think this is very cumbersome. In general I find the whole request processing lifecycle to be more complicated than needed (as compared to the servlet API for example).