Thursday, January 1, 2004

Using a reusable code approach to HTML select option lists, part VI


By Jeff Chilton

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."
-- Aristotle (ancient Greek philosopher, 384BC-322BC)

Welcome to the last article in this special series. During the course of this series, we created a small, but robust framework through a succession of systematic, incremental steps. We started out with a simple, one-method interface, an abstract class of base code that implemented that interface, and a single implementing class that extended the base code.

From this meager beginning, we grew our framework to a multi-method interface supporting numerous implementing classes, added a component factory to mass-produce our components, and then discovered other uses for our components, solving unrelated problems that we never intended to address. Step by step, we turned concept into practical application, and possibly even created something that might be of value to someone somewhere.

Back to the future

The purpose of this little journey was not, however, to generate code. My intent was to use the code as a tool to demonstrate the concept of software reuse. I selected the HTML select statement support simply because I thought it was small enough to use, yet held enough complexity to demonstrate some important concepts. Plus, I had never seen it done before, although that in no way is any indicator of whether or not it actually has been done. Hopefully, by this point you will have realized that what we have accomplished, although fairly usable right out of the box, in no way represents the limits of where this particular little framework could go.

For example, Struts provides great support for internationalization. It wouldn't take much to add Locale to our list of parameters passed to either the factory or the OptionListSource itself and leverage of off the Struts internationalization support to produce multi-lingual labels for our drop-down lists. Obviously, we have not exhausted the possibilities of potential data sources, either. We could easily add classes for XML data, EJBs, LDAP directories, or even legacy hosts systems using tools like WebSphere Host Publisher. The point is, we started out very, very small and grew into something fairly significant, yet there is still much more that could be done. And this is just one representative sample of a single, specific function.

The concept, though, is universal, and that's really the point that I would like to leave you with. You can use this approach to almost anything. You not only can use this approach to almost anything, it is my opinion that you should use this approach to just about everything. As long as you're going to be faced with the work of producing code to perform a particular task, why not go ahead and do it in a way that not only solves your current problem, but starts you out on a path where you or someone else can use some or all of the code again to solve a future problem.