Java Reference
In-Depth Information
pcs = new PropertyChangeSupport(this);
vcs = new VetoableChangeSupport(this);
}
public void addVetoableChangeListener(VetoableChangeListener p)
{
vcs.addVetoableChangeListener(p);
}
public void removeVetoableChangeListener(VetoableChangeListener p)
{
vcs.removeVetoableChangeListener(p);
}
public VetoableChangeListener [] getVetoableChangeListeners()
{
return vcs.getVetoableChangeListeners();
}
public void setAccountNumber(int newNumber) throws
PropertyVetoException
{
int oldNumber = number;
vcs.fireVetoableChange(“accountNumber”, oldNumber, newNumber);
number = newNumber;
pcs.firePropertyChange(“accountNumber”, oldNumber, number);
}
//Remainder of Customer stays the same as before
}
Let me make a few comments about this Customer class and its constrained
accountNumber property:
The only property that is constrainable is accountNumber.
■■
Within setAccountNumber(), notice carefully the sequence of events.
The vetoable listeners are notified first, then the change is made, then
bound property listeners are notified.
■■
If a constrained listener vetoes the change, this is done by throwing a
PropertyVetoException. Since the setAccountNumber() method does
not catch this exception when fireVetoableChange() is invoked, the
remainder of setAccountNumber() does not execute. More specifically,
the property is not changed and bound property listeners are not noti-
fied of any change.
■■
If a PropertyVetoException occurs, the VetoableChangeSupport object
catches the exception and notifies all listeners that the bean is reverting
to the old account number.
■■
