Concrete Observable Properties

Concrete OPs have values stored inside the model. They are different from Logical OP whose values are calculated, or come from outside (e.g. from a database).

Values of OP are declared as class attributes in models, and OP names are declared in a special class member __observables__.

from gtkmvc import Model
# ----------------------------
class MyModel (Model):
   name = "Roberto"
   secondname = 'Mario'
   surname = "Cavada"
   energy = 0.2 # needs holidays!
   status = "sleepy"

   __observables__ = "name surname energy".split()
   pass # end of class

In the example, name, surname and energy are all observable, whereas status is not observable.

Special member __observables__ is a tuple (or a list) of names of class attributes that has to be observable. Names can contain wildcards like * to match any sequence of characters, ? to match one single character, etc. See module fnmatch in Python library for other information about possible use of wildcards in names. Important to say that if wildcards are used, attribute names starting with a double underscore __ will be not matched.

Note

It is also possible (but deprecated!) for the user to add a class variable called __properties__. This variable must be a map, whose elements’ keys are names of properties, and the associated values are the initial values. Using __properties__ is complementary to the use of __observables__, but it is provided for backward compatibility and should be not used in new code. This is an example of usage of deprecated __properties__, but you will not find another in this manual:

from gtkmvc import Model
class MyModelDeprecated (Model):
      __properties__ = {
      'name' : 'Rob',
      }
      pass # end of class

This is another example showing the usage of wildcards in names:

from gtkmvc import Model
# ----------------------------
class MyModel (Model):
   name = "Roberto"
   secondname = 'Mario'
   surname = "Cavada"
   energy = 0.2 # needs holidays!
   entropy = 1.0
   enology = "good science"
   status = "sleepy"

   __observables__ = ("*name", "en????y")
   pass # end of class

In the example, all attributes but energy and status are declared to be observable.

Concrete OP and inheritance

Things so far are easy enough, but they get a bit complicated when you derive custom models from other custom models. For example, what happens to OP if you derive a new model class from the class MyModel?

In this case the behavior of the OP trusty follows the typical Object Oriented rules:

• Any concrete OP in base class are inherited by derived classes.
• Derived class can override any concrete OP in base classes.
• If multiple base classes defines the same OP, only the first OP will be accessible from the derived class.

For example:

from gtkmvc import Model

class Base (Model):
   prop1 = 1
   __observables__ = ("prop1", )

   def __init__(self):
       Model.__init__(self)

        # this class is an observer of its own properties:
       self.register_observer(self)
       return

   @Model.observe("prop1", assign=True)
   def prop1_changed(self, model, name, info):
       print model, "prop1 changed from '%s' to '%s'" % (info.old, info.new)
       return
   pass # end of class
# --------------------------------------------------------

class Der (Base):
   prop2 = 2
   __observables__ = ("prop2",)

   @Model.observe("prop2", assign=True)
   def prop2_changed(self, model, name, info):
       print self, "prop2 changed from '%s' to '%s'" % (info.old, info.new)
       return
   pass # end of class
# --------------------------------------------------------

# test code:
b = Base()
d = Der()

d.prop2 *= 10
d.prop1 *= 10
b.prop1 *= 10

When executed, this script generates this output:

<__main__.Der object  ...> prop2 changed from '2' to '20'
<__main__.Der object  ...> prop1 changed from '1' to '10'
<__main__.Base object ...> prop1 changed from '1' to '10'

Let’s analyse the example.

First, in the Base.__init__ constructor you can see that the instance registers itself as an observer... of itself! As we will see in section Observers, class Model derives from Observer, so all models are also observer.

In the example this is exploited only to write a compact example (it is not needed to define an additional class for the observer). However, in complex designs it is quite common to see models observing them self, or sub-models contained inside them.

Second, method Base.prop1_changed is explicitly marked to observe property prop1.

Third, in class Der only the OP prop2 is declared, as prop1 is inherited from class Base. This is clearly visible in the output:

<__main__.Der object  ...> prop1 changed from '1' to '10'

It is possible to change type and default values of OPs in derived class, by re-declaring the OSs. For example:

class Der (Base):
   prop1 = 3
   prop2 = 2
   __observables__ = ("prop?",)

   @Observer.observe("prop2", assign=True)
   def prop2_changed(self, model, name, info):
       print self, "prop2 changed from '%s' to '%s'" % (info.old, info.new)
       return
   pass # end of class
# --------------------------------------------------------

This would produce the output:

<__main__.Der object  ...> prop2 changed from '2' to '20'
<__main__.Der object  ...> prop1 changed from '3' to '30'
<__main__.Base object ...> prop1 changed from '1' to '10'

As you can see, d.prop1 overrides the OP prop1 defined in Base (they have different initial values now).