Advertisements
This is a basic tool that Sun provides for testing Java Beans. To run the BeanBox, your computer needs to have access to a bdk installation. To run the BeanBox, go to the beans/beanbox subdirectory and then type run. This will bring up three windows:
- The ToolBox window gives you a palette of sample Java Beans to choose from.
- The BeanBox window is a container within which you can visually wire beans together.
- The Properties window allows you to edit the properties of the currently selected Java Bean.
Try a simple example: choose Juggler bean from the ToolBox and drop an instance in the BeanBox window. Also create two instances of OurButton. Edit the labels of the buttons to read start and stop using the Properties window. Now wire the start button to the juggler as follows. Select the start button, then go to Edit | Events | action | actionPerformed. Connect the rubber band to the juggler. You will now see an EventTargetDialog box with a list of Juggler methods that could be invoked when the start button is pressed (these are the methods that either take an ActionEvent as an argument or have no arguments at all.) Choose startJuggling as the target method and press OK. The BeanBox now generates an adaptor class to wire the start button to the juggler. Wire the stop button to the juggler's stopJuggling method in a similar manner. Now that the program has been designed, you can run it within the BeanBox. Simply press the start button to start juggling and press the stop button to stop juggling. If you wish, you can turn your program into an applet by choosing File | MakeApplet in the BeanBox. This will automatically generate a complete set of files for the applet, which can be run in the appletviewer. (Do not expect current versions of Netscape and Internet Explorer to work with this applet.)
Let's take a closer look at how the BeanBox works. On start up, it scans the directory beans/jars for files with the .jar extension that contain Java Beans. These beans are displayed in the ToolBox window, from where they can be selected and dropped into the BeanBox window. Next, we edited the labels of the two instances of OurButton. The BeanBox determined that OurButton has a member named label by looking for setter and getter methods that follow standard naming conventions called design patterns. If you look at the source code in beansdemosunwdemouttonsOurButton.java, you will see that OurButton has two methods named
public void setLabel(String newLabel) {
...
}
public String getLabel() {
...
}
Design patterns are an implicit technique by which builder tools can introspect a Java Bean. There is also an explicit technique for exposing properties, methods and events. This involves writing a bean information class, which implements the BeanInfo interface.
When we wired the start button to the juggler, the BeanBox set up the juggler to respond to action events generated by the start button. The BeanBox again used design patterns to determine the type of events that can be generated by an OurButton object. The following design patterns indicate that OurButton is capable of firing ActionEvents.
public synchronized void addActionListener(ActionListener l) {
...
}
public synchronized void removeActionListener(ActionListener l) {
...
}
By choosing Edit | Events | action | actionPerformed to connect the start button to the juggler, we were really registering an ActionListener with the start button. The Juggler bean itself is does not implement the ActionListener interface. Instead the BeanBox generated an event hookup adaptor, which implements ActionListener and simply calls the juggler's startJuggling method in its actionPerformed method:
// Automatically generated event hookup file.
package tmp.sunw.beanbox;
import sunw.demo.juggler.Juggler;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;
public class ___Hookup_1474c0159e implements
java.awt.event.ActionListener, java.io.Serializable {
public void setTarget(sunw.demo.juggler.Juggler t) {
target = t;
}
public void actionPerformed(java.awt.event.ActionEvent arg0) {
target.startJuggling(arg0);
}
private sunw.demo.juggler.Juggler target;
}
A similar event hookup adaptor was generated when we wired the stop button to the juggler's stopJuggling method.
Why not make Juggler implement the ActionListener interface directly? This is mainly a matter of convenience. Suppose that Juggler implemented ActionListener and that it was registered to receive ActionEvents from both the start button and the stop button. Then the Juggler's actionPerformed method would need to examine incoming events to determine the event source, before it could know whether to call startJuggling or stopJuggling.
