|Lesson 5||Using the BeanBox at design time |
|Objective||Use BeanBox test container to customize example Beans |
Customize Design Time Bean
Let us insert a Bean into the BeanBox to get familiar with how the BeanBox works in design time mode. Click the link below to insert and customize a Bean in design time mode.
Customize Design Time Bean
The JavaBeans API makes it possible to write component software in the Java programming language.
Components are self-contained, reusable software units that can be visually composed into composite components, applets, applications, and servlets using visual application builder tools. JavaBean components are known as Beans.
Components expose their features (for example, public methods and events) to builder tools for visual manipulation.
A Bean's features are exposed because feature names adhere to specific design patterns.
A "JavaBeans-enabled" builder tool can then examine the Bean's patterns, discern its features, and expose those features for visual manipulation.
A builder tool maintains Beans in a palette or toolbox.
You can select a Bean from the toolbox, drop it into a form, modify it's appearance and behavior, define its interaction with other Beans,
and compose it and other Beans into an applet, application, or new Bean.
All this can be done without writing a line of code.
In the next lesson, the BlueButton Bean will be tested in runtime mode.
Generally, all components have state. The thermostat component has state that represents the comfort temperature.
If the thermostat were a software component of a computer-based heating control system, we would want the value of the comfort temperature to be stored on a non-volatile storage medium (such as the hard disk).
This way if we shut down the application and brought it back up again, the thermostat control would still be set to 73 degrees.
The visual representation and position of the thermostat relative to other components in the application would be restored as well.
Components must be able to participate in their container's persistence mechanism so that all components in the application can provide application-wide persistence in a uniform way.
If every component were to implement its own method of persistence, it would be impossible for an application container to use components in a general way.
This would not be an issue if reuse were not the goal. If we were building a monolithic temperature control system [HAL 9000] we might create an application-specific mechanism for storing state.
But we want to build the thermostat component so that it can be used again in another application, so we have to use a standard mechanism for persistence.