WPF Binding Beyond the Limitation of Name Scopes

There are many situations that a property should be bind to something outside of its NameScope. There are many situations that a property should be bind to a DynamicResource. Many UI patterns like Composite UI Applications need a mechanism to support binding across modules. In this paper, I propose a mechanism to address those issues.

One of the great UI patterns that partitions a complicated application to a collection of loose-coupled, simple, independent modules is Composite UI Application pattern. Although, it had been provided before the WPF framework, but it really suits the WPF. It involves many smaller patterns like dependency injection, Model-View-Controllers, Enterprise Logging pattern, Composite Events and Composite Commands and etc. The main idea behind it is dividing a shell window into regions and allows modules to penetrate their Views into the regions. Communication among modules has been done using the pattern infrastructure and the modules do not dependent on each other. Currently, I face a situation in a Composite UI Application that I need a loosely binding across modules. Although, it was possible to pass message across modules using Composite Commands and Composite events, but having loosely binding makes the code very simple. After some investigation, I realized that there are similar binding problems in other areas. For example, binding the content of a tooltip to its parent; since the tooltip belongs neither to the logical tree nor to the visual tree, it can’t be bind to parent data context. On the other hand it has a different NameScope too. A similar problem occurs when you want to bind an item to a resource that dynamically has been added to the project. The solution behind all of these cases is the ability to do binding beyond the NameScope limitation. A NameScope is a class that implements the INameScope interface. WPF uses the NameScopes to enforce the uniqueness of names. All of the controls inside a NameScope must have unique names. The following classes in the WPF have implemented the INameScope: Window, Page, UserControl, Style, Template, NameScope and ResourceDictionary. In the WPF, one can’t do binding among objects in different nameScopes. In this paper, Using attached properties and custom MarkupExtensions, I provide a mechanism that objects can be bind to each other with or without being declared in the same NameScope

read more


No Comments

Post Reply