The last section of the JavaBeans API covered in this part of the book deals with JavaBeans' support for application builder tools, which is also known as bean customization. One of the most touted features of JavaBeans is its direct support for the visual editing of beans within the context of a builder tool. Although JavaBeans pulls off implementing this functionality in an elegant fashion, it's important to realize that builder support is not a minor part of JavaBeans. In fact, it is this very part of JavaBeans that encourages widespread reuse of beans. These facilities fulfill a major design goal of the JavaBeans API in that they offer a means for beans to be reused constructively with little or no programming effort.
In this chapter, you learn all about the application builder support provided by JavaBeans. You find out about property editors and property sheets, which make it possible to visually edit beans at design time. You also learn about the default property editors provided by JavaBeans, which enable you to visually edit built-in Java types with no additional overhead. Toward the end of the chapter you move on to customizers, which take a more advanced approach to the visual editing of a bean's properties by enabling bean developers to create elaborate visual editing interfaces. You finish up the chapter by taking a look at the specific support for application builder tools provided by the JavaBeans API.
You learn about the following topics in this chapter:
Customization involves the editing and manipulation of bean properties in a design-time environment. Customization plays a critical role in JavaBeans development because it provides the means by which beans can be integrated and used within a visual design tool. This might not seem like all that big of a deal because visual design tools have become commonplace these days. However, consider the fact that there is no global object model that supports the use of cross-platform objects across a variety of different tools. The customization support in JavaBeans really is groundbreaking in some ways because it establishes a generic standard for the design-time manipulation of beans.
You might be familiar with other object models such as VBX, OCX, and ActiveX objects,
which can be visually edited using application builder tools such as Visual Basic
and Visual C++. Even though component models such as these offer a solution similar
to the customization features in JavaBeans, they fall short in many ways because
of the overhead and complexity involved in supporting such visual interfaces. JavaBeans
offers a much simpler and more automatic solution that enables developers to put
minimal effort into constructing the visual side of bean customization. This not
only helps speed bean
development, but it also helps bring bean development to a wider crowd because of
its simplicity.
The real motive behind bean customization is that of making application development easier and smoother through the use of reusable beans with visual application builder tools. If you don't quite see the significance of customization in this light, contrast how a bean is used as opposed to a traditional Java class. A traditional Java class is always used in a programmatic fashion, meaning that Java code must be written to create and interact with it. Furthermore, programmers must study a traditional class's API to figure out how to use the class. This is assuming the class ships with a well-documented API, which isn't always the case. The point is that Java classes are always used at the code level, which limits their usability to developers with a fair degree of programming knowledge.
Now consider the case of a bean. Beans can be used in all the same ways as Java classes, and they also can be used as visual building blocks in application builder tools. When used in an application builder tool, beans are selected and laid out graphically by the user, with their properties and events exposed for editing entirely through visual interfaces. The ability to build applications visually lessens the technical expertise necessary to partake in application development. In other words, JavaBeans customization helps bring application development to a less technical crowd because of its support for visual bean editing.
If you're feeling left out because I've made it sound like bean customization only benefits beginner developers, let me clarify that there's also a big benefit to gearheads like you and me who are just as comfortable working with straight source code. Customization benefits highly skilled Java programmers by enabling them to focus more on the task at hand rather than worrying about building a visual interface by hand in code. As much as I don't mind hacking out Java code, I'm not going to pass up an opportunity to do something easier and faster, which is exactly what visual bean editing affords. The fact of the matter is that building a visual interface using textual programming code just doesn't make sense; visual applications should be designed using visual design tools. By using beans in a visual design tool, it is possible to graphically design the appearance of an application and write Java source code only where necessary.
One interesting issue the JavaBeans architects had to tackle was the problem of keeping beans as compact as possible in the midst of supporting advanced features like customization. In working through this problem, the JavaBeans architects reasoned that the overhead required for the customization of a bean is only required at design time, when a bean is used in a visual editing environment. At runtime there is no need to carry the dead weight of the customization support. After coming to this realization, the decision was made to separate the customization support for a bean and require it to be physically stored apart from the bean. In other words, the customization support for a bean must not be included directly in a bean; it must somehow be stored in a separate helper class. Figure 8.1 shows the difference between how a bean is shipped for use in runtime and design-time environments.
Figure
8.1. The difference between shipping a bean
for use in runtime and design-time environments.
The nice thing about this arrangement is that it enables beans to be shipped in different
forms, depending on how they are being used. For development environments that enable
the visual customization of beans, a bean can be shipped with its related customization
support. On the other hand, in a runtime environment such as a commercial application,
a bean can be shipped on its own without the extra customization overhead. This approach
not only makes more sense from a design perspective, but it also results in more
compact beans, which is a major goal of JavaBeans.
The application builder tool support in JavaBeans begins with property editors, which are visual interfaces for editing a particular type of property. Property editors form the basis of bean customization because they are implemented at the property level, which facilitates reusing them in more comprehensive scenarios such as property sheets and customizers. Don't worry, you learn about property sheets and customizers a little later in this chapter in the "Property Sheets" and "Customizers" sections.
The aim of property editors is to enable you to add visual editing capabilities to every conceivable bean property type. With each property type having a corresponding editor, it then becomes possible to edit entire beans simply as a group of properties. JavaBeans provides property editors for built-in Java data types such as integers, booleans, and strings. Figure 8.2 shows how a string property editor looks. Incidentally, for custom properties it is expected that developers provide a suitable editor if they want their property to be available for bean development. Developers do this by designing a class that implements the PropertyEditor interface, which is defined in the JavaBeans API.
Figure
8.2. The property editor for a string property.
In this example, the string property is the label for a button. You can see how this
property editor provides a straightforward visual approach to modifying the string
property through a text edit box. Contrast this visual approach with traditional
Java programming, where you would have to call a method on the button class and pass
the name of the property as a String object. Granted, it's not all that
hard to call a method, but it's tough to argue with the increased level of intuitiveness
offered by the visual approach.
If a string property editor doesn't sound all that amazing, consider another type of property editor that makes a little more of an impact in terms of its interface being more effective. Figure 8.3 shows the property editor for a font property, which is a little more involved than the string property editor.
Figure
8.3. The property editor for a font property.
As you can see, the font property editor is actually implemented as a dialog box
rather than as a simple component. It contains three different drop-down lists that
enable you to tweak the specific aspects of a font with ease. Now contrast this approach
with that of programming with straight Java classes. Each selection made in the drop-down
lists corresponds to an initialization parameter for a Java Font object.
The programming approach has the additional inconvenience of providing no type of
guidance. You have to be very careful to enter the correct information for the font
and make sure not to misspell the name of the typeface. The property editor approach
guarantees that you don't make any mistakes because it forces you to pick from a
predefined list of options. This is a very nice usage of property editors in that
you can try out different font settings and see the results immediately.
Because you're having so much fun learning about property editors, I'm going to show you one more that really highlights the visual aspect of property editing. Figure 8.4 contains the property editor for a color property, which enables you to set the red, green, and blue values for a color and see the results before accepting the final color.
Figure
8.4. The property editor for a color property.
As you can see, this property really makes the visual aspect of property editing
come to life. I don't know about you, but I don't have a very good imagination when
it comes to guessing at what colors the different combinations of red, green, and
blue make. The color property editor enables you to see exactly the color you are
getting as you change the values of each color component. Unlike the other two property
editors you've seen, the color property editor is also interesting in that it provides
two options to editing a color. You can either type in the red, green, and blue (RGB)
color components or you can select a standard color from a drop-down list. Being
able to choose a standard color without having to worry about RGB values is a very
nice touch, especially when you consider that most of the time you are probably going
to use a standard color anyway. The ability to select standard colors is also valuable
because it enables you to see what the RGB values for different colors are. With
this knowledge, you can slightly alter the standard colors to get different shades.
In short, this is a very cool property editor!
Although property editors are very useful at the property level, the editing of properties always takes place within the context of a complete bean. In other words, editing a bean usually involves interacting with a group of property editors because beans usually contain multiple properties. To facilitate the editing of complete beans, JavaBeans provides property sheets, which are visual interfaces that consist of all the property editors necessary to edit the public properties of a bean. Property sheets are usually implemented as dialog boxes that contain a variety of different individual property editors, depending on the specific properties within a bean.
Property sheets are the interfaces you will most often think of when it comes to editing a bean because they group all of a bean's properties into one convenient location. Figure 8.5 shows how the property sheet for a simple button bean looks.
Figure
8.5. The property sheet for a button bean.
The property sheet shown in the figure exposes property editors for four different
properties: foreground, label, background, and font.
The foreground and background properties are both color properties,
the label property is a string property, and the font property
is a font property. Editing these properties involves the three property editors
you saw in the last section. However, only one of them, the string property editor,
looks familiar in Figure 8.5. Why?
Well, the color and font editors are both implemented as dialog boxes, which means they can't be placed directly within a property sheet. Instead, some representation of the property is displayed in the property sheet and the associated editor is automatically presented to the user when the property is clicked in the property sheet. For example, the foreground property is displayed in the property sheet as a colored area (in this case black). When the user clicks this colored area, the color property editor shown in Figure 8.4 is displayed. This approach of providing a preview of a property value that links to the property's editor is very powerful and helps make the whole property editing process much more intuitive.
One other issue relating to property sheets is how they are used within a visual design tool. Because users interact with property sheets on an individual bean basis, it makes sense that a property sheet should appear whenever an individual bean is being edited. Most visual design tools enable you to graphically lay out beans in some kind of container such as a window or dialog box. Users are free to drag beans around and resize them however they choose. When it comes to editing a bean, most tools require the user to double-click the bean in question. It is at this point that a property sheet for the bean is displayed, enabling you to edit the bean's properties.
Figure 8.6 shows the layout of a few beans in the BeanBox test container that ships with the Bean Developer's Kit by JavaSoft. You learn much more about the Bean Developer's Kit in Chapter 9, "Bean Construction Basics."
In this example, a few beans are shown in the BeanBox test container, which provides a test environment similar in function to what most visual design tools offer. There are three beans shown in this figure: a button bean, a juggling animation bean, and a molecule bean. The bean of interest to this discussion is the button bean, because you've already seen what the property sheet looks like for this bean (Figure 8.5). In fact, the property sheet shown in Figure 8.5 displays the properties with the exact settings for the bean that is displayed in Figure 8.6. This is evident by the "Press Me" label of the button and the font to which it is set.
Figure
8.6. Some beans laid out in the BeanBox test
container.
I don't want to get into any details here about the BeanBox program because you learn
all about it in the next chapter. I mainly just want you to see the relationship
between a bean in a visual editor and its associated property sheet that is displayed
when the bean is double-clicked.
For those cases in which a property sheet doesn't quite do a bean justice, JavaBeans provides another option: customizers. Bean customizers are more elaborate visual interfaces that enable you to edit beans in a hopefully more intuitive fashion. Customizers are similar to property sheets in that they enable you to edit a complete bean, but they differ in that they take on a totally different approach to presenting the individual property editors. Most customizers act like wizards, which are visual editors that gather property information in a multiple-step process. The purpose of offering this route to bean editing is to give bean developers the freedom to implement more intuitive visual interfaces.
Customizers often attempt to provide editing facilities within the context of a series of questions. By presenting property information in the form of questions, the task of customizing a bean is made much simpler. Of course, for simple beans customizers are probably overkill; they are primarily useful for beans that would be complex to edit using normal property sheets. Keep in mind that customizers are designed and implemented entirely by bean developers. JavaBeans supports the use of customizers, but it doesn't go much further than that. All JavaBeans really provides is an interface, Customizer, that must be implemented by customizers. In other words, building a customizer for a bean can involve a significant amount of work on the developer's part. On the other hand, a powerful customizer interface can make a bean infinitely more useful to the end user, so it's often worth the extra development effort.
None of the customization features you've learned about in this chapter would mean much without the underlying classes and interfaces that make it all happen. You wrap up the chapter with a quick look at the classes and interfaces that make the customization facilities provided by the JavaBeans API a reality. Here are the classes and interfaces that make up the customization portion of the JavaBeans API:
NOTE: All of these classes and interfaces are covered in much greater detail in Appendix B, "JavaBeans API Quick Reference."
The PropertyEditorManager class is used to locate the property editor for a property of a given type. Property editors capable of being located by the PropertyEditorManager class must implement the PropertyEditor interface. The PropertyEditorManager class provides a means of registering property types so that their editors can be easily found. For property types that haven't been registered, the PropertyEditorManager class looks for property editors using the name of the property with Editor appended to the end.
The PropertyEditorSupport class is a helper class implementing the PropertyEditor interface that is used to make the construction of custom property editors a little easier.
The Customizer interface defines the overhead required to provide a complete visual editor for a bean. Classes implementing the Customizer interface are typically derived from the Component class so that they can be used within the context of a dialog box or panel.
The PropertyEditor interface defines a means of visually editing a single bean property of a given type. Because JavaBeans provides standard property editors for built-in data types, you are only required to develop property editors for custom data types. The PropertyEditor interface provides a couple of different options in regard to editing a property. It is up to bean developers which specific type of editing they want to provide via the PropertyEditor interface.
This chapter took you on a tour through the exciting world of bean customization. OK, maybe it wasn't all that exciting, but it was at least informative. You learned in this chapter the reasoning behind JavaBeans providing support for visual bean customization, which is based on the fact that visual application construction is much more straightforward and efficient than brute force programming. From there, you moved on to learn about property editors and property sheets, which provide the core capabilities for beans to be visually customizable. You also learned about a more elaborate approach to visual bean editing that involves customizers. You finished up the chapter by peering into the specific classes and interfaces that make the customization support in JavaBeans tick.
This chapter rounds out this tour of the JavaBeans API. I trust you now have a pretty good understanding of the major features and services offered by the JavaBeans API. With those services in mind, you're ready to press on to more exciting things such as building your own beans!
