WPF Property system and ValueModels
I was looking at WPF's property system (here) and notice that one item that is going on is that the property system is really designed to allow a multitude of objects to expose properties for XAML usage. That's a good thing. The other component (with attached properties) was to allow the ability of other objects to share values between different, unrelated objects. These objects may exist in a hierarchy or not. In this way, the property could be thought of as a shared value and that is what a ValueModel (from jgoodies and smalltalk) do. An attached property also allows unrelated objects in a hierarchy to declare properties that the higher-up object wants the lower object to define. Then the higher-up object can access the lower-object's specific values. This is sort of like extending an unrelated class with a property that is defined in another class but doing this quite manually.
This last use case could be implemented by ValueModel's. The parent object could have a list of "properties" that it would like other sub-objects to potentially implement. The subobject could request a valuemodel based on a key, such as the property's name, from the super-object. Then get and set that value as needed using instance-based property setter logic (or static or a well-known properties hashtable). This also allows you to set a property defined by another object on a sub-object and have that property value stored in the sub-object.
Could this be done differently than WPF based on the previous paragraph's comments? It seems like it could. Could the association between the sub-object and the property value just be kept in the super-object in a hashtable? Seems like an easier answer. I think the kicker is that by using WPF's attached property concept, you can still have the property change notification and other coercion and validation logic consistently applied versus a simple hashtable but the idea is the same. This approach, of formalizing the hashtable property concept allows you to add properties in XAML that are defined by you or others. The reason this works is because if the object you want to set this programmer defined property on is a DependencyObject, then the machinery exists already and the DependencyObject subclass can receive the property value using GetValue and SetValue. This allows the virtual machine to be use reflection safer than just using a plain old hashtable. So if storing a value is the only key issue, a hashtable implementation could be used: Store the value model in the sub-object and the parent-object retains a hook to it for change notification OR store the value itself in the sub-object keyed by the property in some way and write some general machinery around the get/set methods to detect changes. Programatically, it is easy to see how this can work, but when using XAML (or any declarative approach) you need to define some more property information to allow even basic reflection to work on any object versus only those that define those public set/getters directly on the actual object (which means changing code that you may not have control over). I believe that this follows the delegate design pattern. This pattern is automatically taken care of, BTW, in dynamic languages such as python and ruby where you can define properties for an object on the fly. Of course, you get a little less type-safety on that approach.
If the sub-object that you want define that new property on does not implement DependencyObject you could use an interface to define some methods and provide some containment support.
This last use case could be implemented by ValueModel's. The parent object could have a list of "properties" that it would like other sub-objects to potentially implement. The subobject could request a valuemodel based on a key, such as the property's name, from the super-object. Then get and set that value as needed using instance-based property setter logic (or static or a well-known properties hashtable). This also allows you to set a property defined by another object on a sub-object and have that property value stored in the sub-object.
Could this be done differently than WPF based on the previous paragraph's comments? It seems like it could. Could the association between the sub-object and the property value just be kept in the super-object in a hashtable? Seems like an easier answer. I think the kicker is that by using WPF's attached property concept, you can still have the property change notification and other coercion and validation logic consistently applied versus a simple hashtable but the idea is the same. This approach, of formalizing the hashtable property concept allows you to add properties in XAML that are defined by you or others. The reason this works is because if the object you want to set this programmer defined property on is a DependencyObject, then the machinery exists already and the DependencyObject subclass can receive the property value using GetValue and SetValue. This allows the virtual machine to be use reflection safer than just using a plain old hashtable. So if storing a value is the only key issue, a hashtable implementation could be used: Store the value model in the sub-object and the parent-object retains a hook to it for change notification OR store the value itself in the sub-object keyed by the property in some way and write some general machinery around the get/set methods to detect changes. Programatically, it is easy to see how this can work, but when using XAML (or any declarative approach) you need to define some more property information to allow even basic reflection to work on any object versus only those that define those public set/getters directly on the actual object (which means changing code that you may not have control over). I believe that this follows the delegate design pattern. This pattern is automatically taken care of, BTW, in dynamic languages such as python and ruby where you can define properties for an object on the fly. Of course, you get a little less type-safety on that approach.
If the sub-object that you want define that new property on does not implement DependencyObject you could use an interface to define some methods and provide some containment support.
Comments
Post a Comment