18 June 2008

Plain ol' Servlets and JSP

I reached a realization after many years of working with web frameworks and creating a few back when there weren't any to be had: web frameworks don't always save you time and has everybody forgotten how to code with servlets JSPs and tag libraries?

What pushed me over the edge was trying to code in an agile way using JSF. JSF is a nice idea, at least it doesn't tie you to the framework too much (extending action classes etc), but it is so loosely coupled that a typo (and I make loads) can cause a half day loss of work tracking down the error and I haven't been through that kind of debugging since C/C++, um, and mobile device programming.

I also got tired of writing configuration data in multiple xml and property files: set up the framework in the web.xml file, then off to the frameworks action config file, then the mapping file etc.. yuck.

About 6 years ago I wrote a framework using XML and XSLT when it looked like XSLT was the best thing for view abstraction (hahaha). I had a nicely abstracted design, with a factory for choosing the action class, another for choosing the XSLT file and another for the SQL. This was all rather neat and worked well, though took a lot explaining to my colleagues, but as they weren't familiar with OOP architecture (architecture in general) I arrogantly thought once they saw the whole picture all would be forgiven...

A few years later there was call to use the same application and I took a look through the system again and realized that all the configuration could be done within the web.xml file: as all the logic was based around the request (it was a report based application), I could write a base servlet that handled the transforms and the configuration could be written into the servlet parameters and the mappings. It simplified the whole framework into a very manageable piece of code, I wouldn't say the same about the XSLT though..

The point of the diatribe is that we tend to go off and create a 'gatekeeper' servlet for handling all the requests and then a factory for mapping requests to actions, forgetting that a servlet is an action in itself. The other problem is the actions normally created are normally created, I suppose, to protect ourselves from all that HTTP request and response stuff, and then we end up passing it all through to the action ANYWAY, as its, um, pretty essential.

Since working on distributed applications servicing different types of clients I have used a clear business (or service) layer which means that the servlet becomes a translation layer only (getting parameters from the request etc..). Together with apache's beanutils there is really not much to do.

On the view side I again realized a flaw while using JSF: AJAX hit the scene but JSF or struts for that matter, had no support for it. So if you use these frameworks you are tied to whatever components they come up with including the javascript libraries and look and feel etc.

The other point is that HTML is already one language to learn, why bother with learning another (none-standard) way of doing it? Looking at the RFCs, HTML itself is going to become more complicated, why reinvent the wheel? I'd prefer to write my forms by hand and insert the values where needed, which brings me to my last point:

Why are more people not using tag libraries? They are easy to use and they do exactly what you need them to do. Together with EL and JSTL you can create some very clean and understandable views. There are some drawbacks and work arounds, but if more people were using them they would improve. Tool support is also a bit iffy: Netbeans has great support, but could be improved.

I've just brushed on the basics here and am not bashing frameworks completely, they have there place, but they don't have to be used everywhere in every situation.

I'd like to start not a framework, but rather a meme for using basic servlet/JSP for web development. If I get much interest from this blog, my next blog will be on the basics of using this meme.