Changes

In xaml, every element in the UI is informed by a '''context'''. This is the data that is delivered by UBIK immediately when binding. Knowing the context that will be used by a content control is vital when using templates, as this directly affects what bindings you can prepare in your template. Furthermore, all content views that use the same template must have the same contextsimilar contexts, to a degree.

Two of the more frequently customized elements are Objects and their Metaproperties. A template used for an a UBIK object will have bindings such as Title, Values[PROPERTY], etc, whereas one designed for a Metaproperty will have Description, DisplayValue, Description, Unit, and so on. Using a template design designed for an a UBIK object will have no benefit if the context applied to it is that of a property, and vice versa.

Context is inherited. When you begin customizing a xaml template, it generally has a known use, such as a child area, document viewer, or item in a property list, to name just a few of many. In these cases, the context is quite clear. However, when you begin creating general templates that can be used anywhere on a pagein the client, then there will likely be the need to define specify what context should be applied to each specific instance of time the template in useis used. Returning to   [[Image:XBP_ContentTemplates.png]] In the above example shown in the previous section, we see 3 headers each with 3 uses a variety of the same property editing fields. To cut down on repetitive XAMLing, a templateis created for inputting a single property, consisting in this case of Description, DisplayValue, a [[Property_Based_Content_Filters|placeholder label, and some indicators such as whether the property-based content filter]]is required or filled. In each case, the context needs to be set to a specific metaproperty, defined on the 'controls:ContentControl' that will then be used to inform all hosts each instance of the displays and interactivities added template, through the TemplateContext attribute.  <source lang = "xml"><controls:ContentControl ContentTemplate="{DynamicResource PropertyField_Required}" TemplateContext="{Binding Properties.VisibleItems[MP_DETECTION]}" > <controls:ContentControl.GestureRecognizers> <TapGestureRecognizer Command="{Binding Properties.VisibleItems[MP_DETECTION].PropertyClickedCommand}"/> </controls:ContentControl.GestureRecognizers></controls:ContentControl></source> {{Hint|Adding the behavior to the ContentControl, rather than defining it in the templateitself, allows flexibility in the customizing as different property-editing commands can be paired with the same UI based on the required functionality.}} 

To reiteraterepeat, context is almost always inherited. If you forget to assign a specific context to a content control(as in the above example), the context of the xaml XAML element that hosts that content control will be used. Context-switching is simply the name given to the act When you think about it, any number of assigning a different nested Grids still inherit the contextof the area or item template they are hosted in.

Context-switching is simply the name given to the act of assigning a different context to a particular control, when needed. It is also usually very simple to do:

==== ⚠️ Important Note ====By using this code snippet, we expect to see the Title or the current object. However, because we have a context switch applied, we would instead see the Title of the parent object. For Xamarin use '''Label''' instead of TextBlock and '''BindingContext''' instead of DataContext.  {{Attention|Using this technique to switch the context of a control does it for '''all bindings on that control'''. Since the entire control is now 'focused' directly on the parent object related to the current a different context, all other existing bindings on that control, for example Visibility, will need to be adapted. An easy example is the Visibility of the TextBlock, which we might still want to bind to certain conditions on the child object, while displaying the data of the parent.  One exception is the controls:ContentControl, which through its TemplateContext attribute accepts the possibility to have a different context for its content, therefore decoupling the context of the template from the actual control, [[XAML_Best_practices#Context_Switching_And_Templates|as described below]].}} Furthermore, since context is continues to be inherited , any controls contained within the context-switched one (imagine it's a grid with children controlsGrid containing more elements, rather than a simple TextBlock) will all also have the context of ParentLevel.

==== ⚠️ Context Switching And Templates ====