Wednesday, March 28, 2012

Web Development in Pure JSP

On a recent project, my client needed a small web application to be developed in ‘pure JSP’ for a client of theirs.[1] In essence, their only route to deploy anything in the production environment was to commit it to a subversion repository which would later get deployed on their behalf. This made anything but the simplest deployments tricky. Adding frameworks to the project or deploying precompiled code was only going to cause problems.

If you haven’t done much web development in Java, this might not sound particularly unusual. Deploying a php, rails or python project typically doesn’t require much in the way of compilation, and while framework are common to both, doing without wouldn’t be a particular stumbling block.

For a Java project, this is fairly unusual – a classic Java web project uses the MVC pattern and establishes a fairly strict separation between the model, view and controller where the model is plain Java, the controller is a Java servlet, and the view is JSP:

There are lots of alternatives[2] depending on your preferences and technology choices, but I haven’t seen many Java projects implemented using only JSP.

Writing a Pure JSP project would rule out using Java classes[3] for the model and controller, and limit you to whatever you can accomplish in a JSP. Having said that, I couldn’t see any fundamental obstacles to building a project in pure JSP, I just hadn’t done it or seen it done. I did few quick google searches and didn’t see many people suggesting this approach, so I decided to conduct a quick exploratory spike.
After a little testing, I quickly found that there were at least two choices that would work, which I’ll call “JSP Controller” and “Embedded Controller”.

JSP Controller

In this style, you simply replace the controller servlet with a JSP page that acts like a controller servlet. JSP pages are essentially Java servlets in a different form, and if you write a JSP page that contains no HTML or CSS, but instead parses the request from the browser, does any necessary processing and then renders the response using another JSP page, then you have what amounts to a controller written in JSP:

Of course, if you’re avoiding precompiled Java classes, you still can’t use an external Java-based model, but you can use the standard Java class library, as well as inner classes. This isn’t the cleanest way to model your domain, but it’s enough to get by.

Embedded Controller

If your control logic is pretty simple, you might simply embed the control logic in the view up-front. This mixes the view and controller in a way that some might find unpalatable, and a little retro[4], but it does simplify things a little and makes it a little easier to share model code with inner classes. This is the simplest approach, but also the one most likely to make an unmaintainable mess if your project will be growing:

This client project was a very tightly-scoped piece of functionality, so I used Embedded Controller and was reasonably happy with the end result, all things considered.

When to use Pure JSP

I’m not advocating for Pure JSP projects as a generalized solution to web development in Java. It adds a lot of constraints to your development style for benefits that are of limited value in most projects.

But if you need to build a small project that will run in a Java-based environment and you don’t have a lot of access to the production server or detailed knowledge about how it is configured, these approaches do simplify things.

By writing this up, I hope to save some of you a similar exploration; if you’re in this position, you’ll know this is a path that others have taken and that it all worked out in the end.

  1. The project was developed under a non-disclosure agreement (NDA), so I’m going err on the side of non-disclosure here and keep the details vague.  ↩
  2. The model could be an enterprise Javabean; the controller might be plain/annotated Java front-ended by a “front controller” servlet provided by your framework; the view could be Thyme. All three might be replaced by a somewhat different model under JSF or Tapestry.  ↩
  3. Incidentally, JSP pages typically end up as compiled Java classes, but that happens under the cover without your involvement, so it’s a little more suited to an environment over which you have limited control.  ↩
  4. When the web was born, this kind of mixed presentation-and-logic approach was the simplest, and thus, most common approach to adding very simple functionality to websites. In the early days of Java, this was the "Model 1" approach as compared to the "Model 2" MVC separation that came to dominate as a development style.  ↩

No comments:

Post a Comment