This class minimizes the effort required to bind, edit, buffer, and observe the bound properties of an exchangeable bean. Therefore it provides five groups of features that are described below:
Typically this class will be extended to add custom models, Actions, presentation logic, model operations and other higher-level behavior. However, in simple cases you can use this class as-is. Several methods are intended to be used as-is and a typical subclass should not modify them. For example #isChanged, #isBuffering, #getBean, #setBean, #getBeanChannel, #getModel, #getBufferedModel, #getTriggerChannel, #setTriggerChannel, #triggerCommit and #triggerFlush.
Adapting Bean Properties
The method {@link #getModel(String)} vends ValueModels that adapt a bound bean property of an exchangable bean. These ValueModels will be requested from an underlying BeanAdapter. To get such a model you specify the name of the bean property. All properties adapted must be read-write and must comply with the Java Bean coding conventions. In case you need to adapt a read-only or write-only property, or if the bean uses custom names for the reader and writer, use {@link #getModel(String,String,String)}. Also note that you must not mix calls to these methods for the same property name. For details see the JavaDoc class comment in {@link com.jgoodies.binding.beans.BeanAdapter}.
Changing the Adapted Bean
The adapted bean is not stored in this PresentationModel. Instead it is held by a ValueModel, the bean channel - just as in the PropertyAdapter and BeanAdapter. This indirection enables you to manage the adapted bean outside of this PresentationModel, and it enables you to share bean channels between multiple PresentationModels, PropertyAdapters, and BeanAdapters. The bean channel is used by all adapting models created by the factory methods #getModel. You can get and set the current bean by means of #getBean and #setBean. Or you can set a new value to the bean channel.
PresentationModel fires three PropertyChangeEvents if the bean changes: beforeBean, bean and afterBean. This is useful when sharing a bean channel and you must perform an operation before or after other listeners handle a bean change. Since you cannot rely on the order listeners will be notified, only the beforeBean and afterBean events are guaranteed to be fired before and after the bean change is fired. Note that #getBean() returns the new bean before any of these three PropertyChangeEvents is fired. Therefore listeners that handle these events must use the event's old and new value to determine the old and new bean. The order of events fired during a bean change is:
#triggerCommit and #triggerFlush respectively. The trigger channel is provided as a bound Java bean property triggerChannel that must be a non-null ValueModel with values of type Boolean. Attempts to read or write other value types may be rejected with runtime exceptions. By default the trigger channel is initialized as an instance of Trigger. As an alternative it can be set in the constructor.
Observing the Buffering State
This class also provides support for observing the buffering state of the BufferedValueModels created with this model. The buffering state is useful for UI actions and operations that are enabled or disabled if there are pending changes, for example on OK or APPLY button. API users can request the buffering state via #isBuffering and can observe the bound property buffering.
Tracking Changes in the Adapted Bean
PresentationModel provides support for observing bean property changes and it tracks all changes to report the overall changed state. The latter is useful to detect whether the bean has changed at all, for example to mark the bean as dirty, so it will be updated in a database. API users can request the changed state via #isChanged and can observe the bound property changed. If you want to track changes of other ValueModels, bean properties, or of submodels, register them using #observeChanged. To reset the changed state invoke #resetChanged. In case you track the changed state of submodels you should override #resetChanged to reset the changed state in these submodels.
The changed state changes once only (from false to true). If you need instant notifications about changes in the properties of the target bean, you can register PropertyChangeListeners with this model. This is useful if you change the bean and don't want to move your listeners from one bean to the other. And it's useful if you want to observe multiple bean properties at the same time. These listeners are managed by the method set #addBeanPropertyChangeListener and #removeBeanPropertyChangeListener. Listeners registered via these methods will be removed from the old bean before the bean changes and will be re-added after the new bean has been set. Therefore these listeners will be notified about changes only if the current bean changes a property. They won't be notified if the bean changes - and in turn the property value. If you want to observes property changes caused by bean changes too, register with the adapting ValueModel as returned by #getModel(String).
Instance Creation
PresentationModel can be instantiated using four different constructors: you can specify the target bean directly, or you can provide a bean channel to access the bean indirectly. In the latter case you specify a ValueModel that holds the bean that in turn holds the adapted property. In both cases the target bean is accessed indirectly through the bean channel. In both cases you can specify a custom trigger channel, or you can use a default trigger channel.
Note: This PresentationModel provides bound bean properties and you can register and deregister PropertyChangeListers as usual using #addPropertyChangeListener and #removePropertyChangeListener. Do not mix up the model listeners with the listeners registered with the bean.
Warning: The PresentationModel registers a PropertyChangeListener with the target bean. It is recommended to remove this listener by setting the target bean to null if the bean lives much longer than the PresentationModel. As an alternative you can use event listener lists that implement references with WeakReference.
Consider adding a feature to ensure that update notifications are performed in the event dispatch thread. In case the adapted bean is changed in a thread other than the event dispatch thread, such a feature would help complying with Swing's single thread rule. The feature could be implemented by an extended PropertyChangeSupport.
I plan to improve the support for adapting beans that do not fire PropertyChangeEvents. This affects the classes PropertyAdapter, BeanAdapter, and PresentationModel. Basically the PropertyAdapter and the BeanAdapter's internal SimplePropertyAdapter's shall be able to optionally self-fire a PropertyChangeEvent in case the bean does not. There are several downsides with self-firing events compared to bound bean properties. See Issue 49 for more information about the downsides.
The observeChanges constructor parameter shall be replaced by a more fine-grained choice to not observe (former observeChanges=false), to observe bound properties (former observeChanges=true), and a new setting for self-firing PropertyChangeEvents if a value is set. The latter case may be further splitted up to specify how the self-fired PropertyChangeEvent is created:
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |