Developing Java Beans changed, the getPropertyName() method may
Developing Java Beans A VetoableChangeEvent for a constrained property should be fired before the actual value of the property has changed. This gives any VetoableChangeListener a chance to reject the change when its vetoableChange() method is called. The event source must catch the java.beans.PropertyVetoException. If a listener throws the exception, the source object must fire a new Vetoable-ChangeEvent to all the registered VetoableChangeListener objects, using the current value for the property. This is necessary because if there were multiple listeners, some of them may already have been notified of the change that was subsequently rejected. So the second round of events gives those listeners the opportunity to revert to the old value. In this case, any PropertyVetoException that is thrown can be caught and ignored. The convention that the second round of PropertyVetoExceptions can be ignored prevents infinite loops in which no satisfactory value can be found. When a listener is informed of a change to a constrained property, it should not assume that the change has already taken place, because some other object may veto the change. If this happens, the listener will be notified again with the property reverted to its old value. Unfortunately, there is no way for the listener to know if the change will be universally accepted at the time of the first notification. So what should the listening object do? For example, let’s say that we have a dialog box that includes a component that allows the user to enter the font size to use for all of the controls on the dialog. This font sizer may have a constrained property named FontSize. All of the controls on the dialog are registered listeners implementing the java.beans.VetoableChangeListenerinterface, and each control has its own notion of the maximum font size. When each is notified of a request to change the value of the FontSize property, each compares the proposed value to its own maximum and throws the java.beans.PropertyVetoException if the value is too high. The control that rejects the change may do so after other controls have already been notified, in which case the previously notified controls may already have repainted themselves with the new font size. Now that another control has subsequently rejected the change, all of the controls will be notified again with the old font size value. The result is that the controls have to repaint themselves again. This is certainly not visually appealing, and is potentially time-consuming as well. The JavaBeans architecture addresses this issue by stating that properties can be both bound and constrained at the same time. In this case the property owner should fire a VetoableChangeEventbefore the property value is actually changed. If no VetoableChangeListener rejects the change, the property value should be changed and then the PropertyChangeEvent should be fired. The dialog controls I just discussed could be registered with the font sizer as both a PropertyChangeListener and a VetoableChangeListener at the same time. This would allow one of the controls to reject the change when the vetoableChange() method is called, but defer reacting to it until the propertyChange() method gets called. Another way to deal with this kind of problem is to have each control inform the font sizer of its maximum font size at initialization time. This way the font sizer itself will have the opportunity to page 61
Note: If you are looking for inexpensive but high quality provider to host and run your jsp application check Astra jsp hosting services