Pre/Post notification

Motivation

The Model wants to inform its listeners not only when data have been changed,
but also just before changing them. A common reason behind this need is to support
vetoing, but other motivations may exist.

Design

To implement Pre/Post notification, the Model simply issues two different
notifications, one before changing the Model state, and one after.

These notifications must be qualified, otherwise the interested listeners
would not be able to differentiate the pre-vs-post nature of the received
notification. For example, a Model could issue about_to_change, apply the
change, and finally issue changed. Both the old and new value are also
generally passed as part of the notification.

Practical Example

Although other approaches could be used to handle this specific use case,
pre-notifications can be useful to keep a Selection Model synchronized when
the View in not collaborative in handling a selection referring to a
non-existent entry.

Our example has a Model containing a list of items, and a Selection Model
holding information about which items in the Model are selected.
If the View cannot handle selection of items not present in the Model,
the following scenario would break the View:

1. An item of the Model is currently selected. This implies that an entry
   for this item is present in the Selection Model.
2. A Controller issues a request to the Model to remove the item. Note that the
   controller may not be aware of the existence of a Selection Model, so it is
   unable to deselect the item to prevent this scenario.
3. The Model removes the item, and notifies the View of its change.
4. The View renders the Model, followed by rendering the Selection, but
   the selected item is no longer in the Model. The View cannot handle
   this situation and issues an exception.

Using a pre-notification can work around the View implementation detail:

1. A Controller issues a request to the Model to remove the item.
2. The Model issues an “about to remove item” pre-notification.
3. The Selection Model listens and receives the Model pre-notification.
4. The Selection Model reacts by removing the item from its internal state.
5. The Selection Model change triggers a notification to the View which is handled
   by visually deselecting the item. The Model hasn’t changed yet, so the
   View is retrieving valid data.
6. Finally, the Model removes the item, and post-notifies the View to
   re-render itself with one less item.

Through pre-notification, the View retrives consistent data throughout the
operation. Without the existence of the pre-notification, we would have to
rely on the order of notification of the post-notification to notify the
Selection Model first, then the View. In general, it is not good practice to
rely on ordering of different listeners on the same notification channel,
because the order may not be guaranteed by the notification framework.