Allow me to continue on with some of my musings on my recent project. Like I said last time, my last project was as much an experiment as it was a deliverable to the customer— especially when it came down to deciding on a web framework. You see, I didn’t want to use one.

After using and playing with just about every web framework engine under multiple languages, I’ve become pretty disillusioned… in the name of “separation of concerns” (following the MVC design pattern), in order to fix a bug, you now have to edit or look at five Java source files, three web pages, and four configuration files… how did that help me?

So for my last project, I did something incredibly radical… I didn’t use one. I just built things with simple servlets. Don’t get me wrong, I didn’t embed HTML strings in my Java code or anything so atrocious as that, I used a template engine called Freemarker. I chose Freemarker because it didn’t require an extensive framework and was fairly small to be embedded in my project.

Each servlet was organized with a doGet() method that would query a database based on the user’s session and any input parameters. With that result set, it would take a template and merge the two to produce an HTML result. The “form” in this file would re-call the servlet with a post action.

The doPost() method would process and validated any parameter data from the form, and generally perform some database operations with it. If all went well, it would redirect the browser to some other servlet. If an error occurred, it would re-call the doGet() method but with a message string from a resource bundle.

So walk with me through the process of fixing a bug… First, the bug is discovered on a web page, and looming at the top of the browser’s window is a URL. The URL mapped directly to the name of the servlet. Since each servlet only dealt with a single template page, I named the templates the same name as the servlet. The bug was in one of these two files … not a lot of hunting around or having to read a configuration file just to find out what URL mapped to which file.

Things weren’t quite that simple, as the template files would often include other template files, and some of the servlets had to store some state in the user’s session before calling the next servlet, but you get my pattern that I followed.

And I liked it.

Oh sure, there were a couple of servlets that had some fairly long if..then clauses while validating data, and this is certainly the downside from using other technologies where validating a particular data field or form is yet another file. But if the series was too long to be readable, I put it in its own function.

And I suppose if I needed to have one servlet call a different servlet, I could have saved editing the source code by using a Struts controller, but that doesn’t happen very often. Hrm…

The largest downside to this approach is that some frameworks can take some of what I had in my servlet, and isolate it to a configuration file or something, which limits the amount of recompilation (generally a good idea). So clearly my approach wouldn’t make sense for a large complicated application, but with a webapp that is primarily a “database app,” it actually worked pretty well.

No, I haven’t sworn off web framework engines… but I think it was a good idea for me to step back from doing things the same way, and a small project like that was just the acceptable level of risk. Funny thing is that I think I trimmed off a quarter of the time in building it.

Note: I am not recommending that every one else do this, but I think it would be good for some of us to return to our roots so that we can better evaluate the current slew of framework options presented before us.