Part of vmc.contrib.gtkmvc.controller View In Hierarchy
We put all of our gtk signal handlers into a class. This lets us bind all of them at once, because their names are in the class dict. This class automatically register its instances as observers into the corresponding model. Also, when a view is created, the view calls method register_view, which can be oveloaded in order to connect signals and perform other specific operation. A controller possibly handles and contains also a set of adapters that makes easier to connect widgets and observable properties into the model.
parameter spurious controls the way spurious value change notifications are handled. If True, assignments to observable properties that do not actually change the value are notified anyway.Method | __init__ | When parameter spurious is set to False |
Method | register_view | This method is called by the framework when registering a |
Method | register_adapters | This method is called by register_view during view |
Method | adapt | Adapts a set of (observable) properties and a set of |
Method | __create_adapters__ | Private service that looks at property and widgets types, |
Inherited from Observer:
Method | register_model | Undocumented |
Method | accepts_spurious_change | Returns True if this observer is interested in receiving |
Method | unregister_model | Undocumented |
Method | __del__ | Undocumented |
Method | get_model | Undocumented |
When parameter spurious is set to False (default value) the observer declares that it is not interested in receiving value-change notifications when property's value does not really change. This happens when a property got assigned to a value that is the same it had before being assigned.
A notification was used to be sent to the observer even in this particular condition, because spurious (non-changing) assignments were used as signals when signals were not supported by early version of the framework. The observer was in charge of deciding what to do with spurious assignments, by checking if the old and new values were different at the beginning of the notification code. With latest version providing new notification types like signals, this requirement seems to be no longer needed, and delivering a notification is no longer a sensible behaviour.
This is the reason for providing parameter spurious that changes the previous behaviour but keeps availability of a possible backward compatible feature.Adapts a set of (observable) properties and a set of widgets, by connecting them. This method can be used to simplify the creation of one or more adapters, by letting the framework do most of the work needed to connect ('adapt') properties from one hand, and widgets on the other. This method is provided in three flavours: 1. An instance of an Adapter class can be created by the caller and passed as a unique argument. The adapter must be already fully configured. 2. The name of a model's property is passed as a unique argument. A correponding widget name is searched and if found, an adapter is created. Name matching is performed by searching into view's widget names for words that end with the given property name. Matching is case insensitive and words can be separated by spaces, underscore (_) and CapitalizedWords. For example property 'prop' will match widget 'cb_prop'. If no matches or multiple matches are found, a ValueError will be raised. The way names are matched can be customized by deriving method match_prop_name. 3. Two strings can be passed, respectively containing the name of an observable property in the model, and the name of a widget in the view. Flavour 1 allows for a full control, but flavour 2 and 3 make easier to create adpaters with basic (default) behaviour. This method can be called into the method register_adapters which derived classes can specialise.