|
|
Property Listener Support
The JFC visual components are compliant with the JavaBeans specification. The JComponent class contains the methods for manipulating property change listeners and convenience methods for sending notifications to the listeners. Recall that a property change listener can register with an object and be notified when a bound property in that object changes. There are two types of property change listeners: PropertyChangeListener and VetoableChangeListener. A PropertyChangeListener simply receives notifications when properties change in the object that the listener registered with. A VetoableChangeListener can take a more active role in the changing of the property. When a vetoable listener receives a change notification, it may throw a PropertyVetoException to abort the property change in the object to which it was listening. A complete description of the property change protocol is beyond the scope of this book but can be obtained from the JavaBeans specification.
Since the JComponent class is the root of the visual component hierarchy in the JFC toolkit, it makes sense for this class to contain the methods to add and remove property change listeners. The JComponent class contains the required add and remove methods that are compliant with the JavaBeans specification. The signatures for these methods are as follows:
public void addPropertyChangeListener(
java.beans.PropertyChangeListener listener)
public void removePropertyChangeListener(
java.beans.PropertyChangeListener listener)
public void addVetoableChangeListener(
java.beans.VetoableChangeListener listener)
public void removeVetoableChangeListener(
java.beans.VetoableChangeListener listener)
The bound properties in JComponent are presented in Table 3.1. You will immediately see that all of the property names are not defined as constants in this class or any other class or interface. This forces you to embed the String property name somewhere in your code, either where you use the property or in a constant that you define. This is incredibly poor programming practice whose example should not be followed in your code. As developers, I think we should expect more from a core toolkit such as the JFC. The JComponent properties are not vetoable. The concrete subclass of the JComponent class that your code is listening for property change events from may define additional properties as well as those defined in the JComponent class. You are guaranteed that all the J visual components contain these bound properties.
The add and remove families of methods are public methods that are used by clients of the component. The JComponent class also defines a family of protected methods that fire the property change events. These methods simplify property management for subclasses of the JComponent class. The convenience methods are listed next. Notice how there are firePropertyChange methods that take intrinsic types as parameters. These fire methods create the objects of the corresponding type for the caller before firing the actual event. It is interesting to notice that the corresponding methods are not provided for firing vetoable events.
firePropertyChange(String propertyName, Object oldValue, Object newValue)
firePropertyChange(String propertyName, byte oldValue, byte newValue)
firePropertyChange(String propertyName, char oldValue, char newValue)
firePropertyChange(String propertyName, short oldValue, short newValue)
firePropertyChange(String propertyName, int oldValue, int newValue)
firePropertyChange(String propertyName, long oldValue, long newValue)
firePropertyChange(String propertyName, float oldValue, float newValue)
firePropertyChange(String propertyName, double oldValue, double newValue)
firePropertyChange(String propertyName, boolean oldValue, boolean newValue)
fireVetoableChange(String propertyName, Object oldValue, Object newValue)
You will see these methods again in Part V of this book when you are creating your own JComponent subclasses.
|