MvvmBindingPack Auto Wiring and Binding

1.1 Name “parts” split and matching rules

For comparing to names is used case sensitive parts matching algorithm. It allows to add more flexibility in forming and using View Model naming conventions.

 

General rules to form name “parts”:

 

  1.       The name is split into parts by capital letter or '_'. The character '_' is not included into parts.
  2.       The matching parts are considered as a case sensitive.
  3.       The names are considered as matched if they have the same ordered set of parts.
  4.       The name is considered as sub-match if it has at least one or more the same consented parts.

Examples of splitting:

 

The View name "_Example_Name_" will split into parts {"Example","Name"}.

The View name "ExampleName" will split into parts {"Example","Name"}.

The View name "exampleName_Ver1" split into parts {"example","Name","Ver1"}.

 

Examples of matching:

 

"Example_Name_" and "ExampleName" and "Example___Name_" are match because they have the same set of parts.

Examples of matching:

 

"Example_Name_" and "ExampleName_Ver" has a sub-match with rank 2 of the same set of parts.

 

1.2      AutoWireVmDataContext XAML WPF and Win Store Application - MVVM Behavior Extension Enhancer.

 

     AutoWireVmDataContext setups the Dependency property referenced to a View Model class instance. By default it is "DataContext". The name of the target Dependency property can be changed via property "TargetPropertyName".     The AutoWireVmDataContext logic of wiring to a View Model is based on using the x:Name and x:Class XAML directives:

  •          x:Name directive uniquely identifies XAML-defined elements in a XAML namescope.
  •          x:Class directive configures XAML markup compilation to join partial classes between markup and code-behind and it has the Type namespace. The Type namespace will be used to construct candidate type.

1.2.1      View to View Model type/instance mapping/matching rules.

    

     The View (XAML) element logical tree parent objects will be scanned in order to detect non-“System.”, non-“Microsoft.” ,other non - WPF class types. All these classes are derived from “DependencyObject” class. From each “DependencyObject” class will be obtained the “Name” property. As the result it will be formed the list of detected candidate Types (x:Class) plus Names (x:Name if it was set). From this list will be formed the list of View Model candidate name variants. For each element in the list will be applied the following rules to locate a View Model Type.

 

General rules for candidate names that will be used to locate the View Model Type:

 

  1.       If the Type namespace suffix section contains a "Views"(default see prop. ViewsNameSpaceSuffixSection), this section will be replaced on "ViewModels"(default see prop.ViewModelsNameSpaceSuffixSection). It forms a “desired namespace candidate”.
  2.       If the Type namespace suffix section doesn’t contains a "Views" suffix section or a namespace has only one section, in this case the suffix section "ViewModels"(default see prop.ViewModelsNameSpaceSuffixSection) will be added. It forms a “desired namespace candidate”.
  3.       If a Type name (i.e. class name) or x:Name contains "View" substring (default see prop."OldNamePart"), it will be replace on "ViewModel" substring (default see prop. "NewNamePart"). It forms a “desired name candidate”.
  4.       “Desired the fully qualified name” of the System.Type will be formed from the parts desired namespace candidate” and “desired name candidate”, where x:Name will have priority.
  5.       The list of possible types will be obtained from all loaded assemblies by filtering with "desired name space". Each type will be examined on best matching to “desired the fully qualified name”.
  6.       Each candidate name will be split into a cased parts and matched against desired name “parts”.
  7.       The first candidate with the full match name will be selected.
  8.       If you set “UseMaxNameSubMatch” flag true than the first sub-match name will selected.

 

 

1.2.2 Obtain instance of the located View Model Type.

 

Type will be resolved in sequence: IoC container, Resources and Activator.CreateInstance(). For controlling see properties “ResolveIocContainer”,” ResolveResources” and “ResolveCreateInstance”. In success the resolved type will set as value to "DataContext" dependency property (set by default "TargetPropertyName").

 

When is resolving via the IoC, the requests wil be formed:

  •          string “type name” and System.Type object; or
  •          System.Type object.

When is resolving via the Resource, the resource key will be formed as string “type name” or string “full type name” or System.Type object.

 

1.2.3 Examples of XAML and View Model code fragments.

 

Example:

XAML:

<Window x:Class="WpfDemoAutoWire.Views.WindowAutoBind"

       xmlns:mark="MvvmBindingPack"

…...

       x:Name="WindowView"

       Title="AutoWireVmDataContext AutoWireViewConrols" Height="350" Width="300">

 

   <mark:BindXAML.ProcessMvvmExtensions>

       <mark:AutoWireVmDataContext/>

       <mark:AutoWireViewConrols/>

   </mark:BindXAML.ProcessMvvmExtensions>

 

View Model:

namespace WpfDemoAutoWire.ViewModels

{

 

   public class WindowAutoBind : NotifyChangesBase

   {

   }

}

 

Example:

XAML:

<Window x:Class="WpfDemoAutoWire.Views.WindowBind"

       xmlns:mark="MvvmBindingPack"

…...

       x:Name="WindowAutoBindView"

       Title="AutoWireVmDataContext AutoWireViewConrols" Height="350" Width="300">

 

   <mark:BindXAML.ProcessMvvmExtensions>

       <mark:AutoWireVmDataContext/>

       <mark:AutoWireViewConrols/>

   </mark:BindXAML.ProcessMvvmExtensions>

 

View Model:

namespace WpfDemoAutoWire.ViewModels

{

 

   public class WindowAutoBindViewModel: NotifyChangesBase

   {

   }

}

 

Example:

XAML:

<Window x:Class="WpfDemoAutoWire.Views.WindowBind"

       xmlns:mark="MvvmBindingPack"

…...

       x:Name="WindowA"

       Title="AutoWireVmDataContext AutoWireViewConrols" Height="350" Width="300">

 

   <mark:BindXAML.ProcessMvvmExtensions>

       <mark:AutoWireVmDataContext/>

       <mark:AutoWireViewConrols/>

   </mark:BindXAML.ProcessMvvmExtensions>

 

View Model:

namespace WpfDemoAutoWire.ViewModels

{

 

   [ViewModelClassAlias("WindowA")]

   public class WindowAbracadabra: NotifyChangesBase

   {

   }

}

 

Example:

XAML:

<Window x:Class="WpfDemoAutoWire.WindowBind"

       xmlns:mark="MvvmBindingPack"

…...

       x:Name="WindowA"

       Title="AutoWireVmDataContext AutoWireViewConrols" Height="350" Width="300">

 

   <mark:BindXAML.ProcessMvvmExtensions>

       <mark:AutoWireVmDataContext/>

       <mark:AutoWireViewConrols/>

   </mark:BindXAML.ProcessMvvmExtensions>

 

View Model:

namespace WpfDemoAutoWire.ViewModels

{

 

   [ViewModelClassAlias("WindowBind ")]

   public class WindowAbracadabra: NotifyChangesBase

   {

   }

}

1.3 AutoWireViewConrols XAML WPF and Win Store Application - MVVM Behavior Extension Enhancer.

 

The AutoWireViewConrols logic is based on using of the x:Name directive. x:Name directive uniquely identifies XAML elements in a XAML namescope. AutoWireViewConrols wires and binds x:Named XAML elements or View XAML UI elements to View Model properties, methods and fields. The View (XAML) element targets are dependency properties or routing events. They are subject of binding to properties, fields and methods in a View Model class.

    

1.3.1      View Control General Wiring and Binding rules

 

General rules:

 

  1.       The x:Named View (XAML) element can be bind one to many distinguish properties, fields or methods, in a View Model.
  2.       The View Model properties has a priority to bind over the methods with the same name.
  3.       The first found match will be bind fist. The order of the declaration may be applicable in ambiguous cases.
  4.       It is used always the full name match of “parts”, a part-sub match can be used as an option, see the 'UseMaxNameSubMatch' property.
  5.       One to One: The View Model property or event can be bind only once for one x:Named View XAML element.
  6.       View element targets will be bind to View Model element targets.
  7.       The desired target names should be defined in the View Model.
  8.       The View Model name without targets will be ignored.
  9.       The x:Name is ignored if it starts with "_".
  10.   The attached property or event name should be set in format "TypeOwner.Name" example "Grid.Row", "Mouse.MouseMove".

    

1.3.2 Examples of wiring the View Model method to the View event.

 

Wiring goal is to wire the View element event like

<Button x:Name="Example_Name_" …>

and event "Click" to a method handler in the View Model.

 

The View Model wiring C# definition variants:

  1.       Without any attributes:

void Example_Name_Click(object sender, RoutedEventArgs e){} or;

      

void ExampleName_Click(object sender, RoutedEventArgs e){}  

          

  1.       With attribute [ViewTarget (...)]

[ViewTarget("Click")]

void ExampleNameClk(object sender, RoutedEventArgs e){} or;

      

[ViewTarget("Click")]

void ExampleNameOther(object sender, RoutedEventArgs e){}        

    

  1.       With attribute [ViewXNameAlias (...)]

[ViewXNameAlias("ExampleName","Click")]

void AbracadbraName(object sender, RoutedEventArgs e){} or;

    

[ViewXNameAlias("Example_Name","Click")]

void _AbracadbraName(object sender, RoutedEventArgs e){}

/* the name starting with "_" will be ignored, but the attribute don't */ or;

    

[ViewXNameAlias("Example_Name_","Click")]

void Abracadbra_Name(object sender, RoutedEventArgs e){}  

    

1.3.3 Examples of binding the View Model property to the View property

     Binding goal is to bind the View element like

<Label x:Name="Example_Name" ..>

and property "Content" to a property in the View Model.

     The View Model wiring definition variants:

  1.       Without any attributes:

string Example_Name_Content {get;set;} or;

 

string ExampleName_Content {get;set;}

 

  1.       With attribute [ViewTarget (...)]

[ViewTarget("Content")]

string Example_Name {get;set;} or;  

        

[ViewTarget("Content")]

string ExampleName_BadTag {get;set;}  

 

 

  1.       With attribute [ViewXNameAlias (...)]

       [ViewXNameAlias("ExampleName","Content")]

       string AbracadbraName{get;set;}   or;

    

       [ViewXNameAlias("Example_Name","Content")]

       string _AbracadbraName{get;set;}

       /* the name starting with "_" will be ignored, but the attribute don't */ or;

    

       [ViewXNameAlias("Example_Name_","Content")]

       string Abracadbra_Name{get;set;}  

 

1.3.4      Examples of wiring the View Model method to the View "Command" property

 

Wiring goal is to wire the View element event like

<Button x:Name="Example_Name_" …>

and property "Conmmad" to methods in the View Model.

  1.   Without any attributes.

     ICommand Example_Name_Command {get;set;} or;

    

     string ExampleName_Command {get;set;}

    

  1.   With attribute [ViewTarget(...)].

     [ViewTarget("Command")]

     ICommand Example_Name {get;set;} or;  

    

     [ViewTarget("Command")]

     ICommand ExampleName_BadTag {get;set;}  

    

  1.   With attribute [ViewXNameAlias(...)].

     [ViewXNameAlias("ExampleName","Command")]

     ICommand AbracadbraName{get;set;}   or;

    

     [ViewXNameAlias("Example_Name","Command")]

     ICommand _AbracadbraName{get;set;}

    /* the name starting with "_" will be ignored, but the attribute don't */ or;

    

     [ViewXNameAlias("Example_Name_","Command")]

     ICommand Abracadbra_Name{get;set;}  

    

  1.   Separate "Execute" and "CanExecute" wiring.

     [ViewXNameAlias("Example_Name", "Command.Execute")]

     void NameVM2MExecute(object obj){...}

    

     [ViewXNameAlias("Example_Name", "Command.CanExecute")]

     bool Method_NameVM2MCanExecute(object obj){....} or;

    

     [ViewXNameAlias("Example_Name", "Command.CanExecute")]

     bool Prop_NameVM2MCanExecute{get;set;}

          

    

1.3.5      Examples of wiring(just copy) the View Model fields to the View property

Wiring goal is to wire the View element event like

<Grid x:Name="Example_Name_" …>

and property "Width" to fields (just copy from) in the View Model.

  1.   With attribute [ViewXNameAlias (...)]

       [ViewXNameAlias("ExampleName","Width")]

       string _textAndMsgLabelTxtC = "Content was copied from the field";

       /*the field name will always be ignored.*/

    

1.3.6      Examples of wiring/referencing the View fields into the View Model

     Sometimes, very often there is a vital case to have a link from View Model to a View element or property or event.

 

  1.   Get a reference/link to the element type like

<Label x:Name="LabelXNameVM2M" ..>

[ViewXNameSourceObjectMapping("LabelXNameVM2M")]

private object _LabelXNameVM2M; // can be used the 'Label' type instead of the 'Object' type.

 

  1.   Get a reference/link to the property "Content" of the element type like

<Label x:Name="LabelXNameVM2M" ..>

[ViewXNameSourceTargetMapping("LabelXNameVM2M", "Content")]

private ViewXNameSourceTarget _LabelXNameVM2MContent;

 

1.4 ViewXNameAliasAttribute extra binding parameters

 

      // Summary:

       //     Gets or sets a value that indicates the direction of the data flow in the

       //     binding.

       public BindingMode Binding Mode { get; set; }

 

       // Summary:

       //     If it is true to register the handler such that it is invoked even when the

      //     routed event is marked handled in its event data.

       public bool HandledEventsToo { get; set; }

 

       // Summary:

       //     The DataErrorValidationRule is a built-in validation rule that checks for

       //     errors that are raised by the IDataErrorInfo implementation of the source

       //     object.

       public bool ValidatesOnDataErrors { get; set; }

      

       // Summary:

       //     The ExceptionValidationRule is a built-in validation rule that checks for

       //     exceptions that are thrown during the update of the source property.

       public bool ValidatesOnExceptions { get; set; }

      

       // Summary:

       //     When ValidatesOnNotifyDataErrors is true, the binding checks for and reports

       //     errors that are raised by a data source that implements INotifyDataErrorInfo.

       public bool ValidatesOnNotifyDataErrors { get; set; }

 

Project Info:

http://mvvmbindingpack.codeplex.com/

 

Last edited Apr 5, 2015 at 6:09 PM by AlexPaskhin, version 1