Vita Rara: A Life Uncommon

Web Frameworks

Categories: | | | | | |

Some history. I've worked on two major projects in the past few years. One of them was written using the Enhydra presentation framework with XMLC. The other one, which I had a large part in specifying, but not writing, uses Struts for the web framework.

So, now that I'm starting with a clean sheet I'm taking a serious look at what is out there. My original inclination was to use Struts 1.2 and then back my way into another frame work down the road. I figured that in the long run we'd likely port to JSF.

Well, I've spent a lot of time with "Professional Java Development with the Spring Framework" by Rod Johnson, et. al., over the past week and I really like what I'm reading. It has me seriously rethinking my decision to use Struts 1.2.

My Issues with Struts

I think my issues with Struts are like many other peoples. But I'm going to enumerate them just so they are clear.

  • Actions must derive from a framework class.
  • Forms must derive from a framework class, and therefore can't be tied to your domain model. This results in lots of plumbing code, or obfuscated forms that encapsulate or proxy domain model objects.
  • I don't like where validation is placed in the processing, and if it fails it doesn't give you a chance to have your controller load things like lists for drop downs, or check lists. This forces the use of a session bean and an obfuscated validation process.
  • If you use a session bean you have to do special handling of the incoming "form" to be sure the user doesn't have two views of the page open in tabs.
  • The deployment descriptor is arcane to be nice. There is no consistency in naming.

I'm sure I have other issues, but those are sufficient for now.

What I Need in a Web Framework

First it needs to be light and stay out of my way. It should promote source re-use.

It also needs to be able to be dynamically extended through the addition of plug-ins. The idea is a plug-in to the application should be able to be packaged as a jar file and placed in the WEB-INF/lib directory and be able to be auto-detected and added to the application.

A plug-in must be capable of adding behavior and functions to existing components in the application. Let's take the following example.

Use Case: Dynamic Loading of Validators

Different clients have different rules for creating product numbers. The system should be able to have a product validator injected at run time configuration. The validator must auto discoverable, and the configuration file of the application should not need to know about it, other than providing an extension point that the plug-in uses.

The plug-in validator should be able to carry a descriptor describing itself and be able to wire itself to the extension point, or be able to sufficiently describe itself so that an IoC container could wire it to the extension point it wants to utilize.

This ability to extend the application without needing to revisit the core is very important to me.

Some other things the framework needs to do:

  • Must marshal submissions from the HTTPRequest to my domain model beans.
  • It would be nice if the equivalent of Struts actions did not have to extend a framework class. I'd prefer to implement an interface. This is not a complete show stopper though.
  • It must be view layer neutral. I need to be able to send my model result to a web page as easily as I do to a report generated out of Jasper Reports.
  • It must not suffer from the inability to fill in drop down type data if the validation fails.

That's it for now. I'll elaborate more on this in the next few days.