JavaServer Pages, Second Edition

3.2 Defining Beans

For the moment, forget about Java and consider a real bean. A bean has certain characteristics, or properties, such as color, size, shape, species, and so on. Not all beans have the same properties. Coffee beans have a "grams of caffeine" property, which lima beans do not have. ^[1]

^[1] Pedants may point out that lima beans do have a "grams of caffeine" property; it's just that the value is always zero! Such people are welcome to try brewing a cup of decaf from lima beans.

It is always possible to determine the value of these properties, although this sometimes requires a careful chemical analysis. However, imagine if a person could discover the value of one of these properties by asking the bean. Further, imagine if beans could change their properties at will; someone could order a bean to set its size to 3 feet or its color to blue, and the bean would suddenly change. People could then instantly decaffeinate their coffee beans or double the amount of caffeine for those lengthy early morning meetings.

Finally, consider a "bean microscope" that could automatically list all a bean's properties. Note that none of these activities梖inding the current state of a property, changing a property, or discovering which properties are available梬ould require cutting the bean open or studying its metabolism or anything similarly complex.

This is now a reasonably good metaphor for a JavaBean. A JavaBean has a set of properties that can be read or changed. It is also possible to find out the names of the properties that a bean has available.

Many objects, processes, and other things in the real world can be modeled as a set of properties. A CD could be described by giving the values of properties representing the year it was released, the record company that produced it, the list of tracks, and so on. Likewise, each track has properties, such as the lyrics, the key it is in, and the length in seconds. Similarly, a stock portfolio can be specified by giving a list of stocks it contains, along with how many shares of each is held and the initial purchase price. The stocks themselves have properties, such as current value, volatility, price-to-earnings ratio, and dozens more. In both of these cases, once the properties of interest have been identified, a JavaBean can be designed to create a model.

Two things make beans especially useful. The first is that neither Java programmers nor JSP programmers need to know anything about a bean in advance in order to use it. A CD bean could be purchased from a bean company, and it would only need to be installed on the local system for JSP authors to start using it immediately.

The second useful thing about beans is that it does not matter how they go about manipulating their properties. It is possible for the request for a value to cause the bean to look up some information in a database. When a bean's property is changed, it could send e-mail to a system administrator with a notification of the new value. In fact, both accessing and changing properties can trigger arbitrarily complex actions, but the JSP author does not need to worry about this. In this sense, beans act as mysterious black boxes with switches and readouts. Page authors can turn the knobs to change properties and view the properties off the readouts without ever knowing what is going on inside the box. This model of a bean is illustrated in Figure 3.1.

It is even possible for properties to depend internally on one another. A bean might have the two properties value1 and value2 and a third, sum, that is always constrained to be value1 plus value2. This would provide all the functionality necessary to build a simple JSP-based calculator, and in fact we will shortly see a bean that does this.

As mentioned previously, for the model/view/controller paradigm to work, the three pieces must fit together easily and naturally. JSPs can interact with beans through three new tags, discussed in the next section.