I usually ramble on about application development philosophies without ever getting down to any real, concrete applications of the theories, so I decided that it was time to actually do something meaningful to demonstrate in a practical way what it is that I'm always talking about. I also decided to tackle something simple, just to keep the focus on the concepts rather than the specific application.

If you've ever done any work with Struts custom tag libraries, you've invariably come across the html:select tag, and the accompanying html:options tag. Used together, these tags render a nice HTML select statement, which gives you the familiar drop-down list of choices from which to choose your input value. It's this list of choices that will be the focus of our explorations here. There are a number of ways to feed the values of these choices to the Struts tags, but for the purpose of this discussion, we're going to focus on the method that uses a collection, which is simply a Java ArrayList of labels and values. Struts even provide a nice bean object for such an array, called interestingly enough, a LabelValueBean. The Struts LabelValueBean has two fields, a label and a value, and the accompanying getters and setters for both fields.

All you need to do in order to take advantage of these components is to load your ArrayList with the appropriate LabelValueBeans and point your html:options tag to this collection. There is more than enough material in existence on just exactly how to do this, so I won't bother to repeat any of that here. What we're going to focus on is a way to consistently produce these collections of LabelValueBeans from a variety of sources.

Create an Interface
Whenever I want to create a plug-compatible framework for anything, I start with the Java Interface. The Interface defines the rules for the behavior of the modules that you want to plug and unplug into your system, and generally speaking, I always identify replaceable components by the Interface name as opposed to the actual name of the object. This is just a good practice to get into, so that you're referencing the contract and not a specific implementation of the contract. We will begin with a simple one-method interface, and then later we can expand it to add additional features. Our interface is presented in Listing 1: