Building Physical View Mapping

  • Article

You can create physical view mappings by either:

  • Using the Physical Binding Mapper

  • or

  • Building the Physical View Binding File Manually

Using the Physical Binding Mapper

The physical Binder tool is a standalone tool that simplifies the editing of the Physical view mapping XML files.

Following are the display areas in the tool:

  1. A configuration area, where the Logical View assembly, the Physical view Assembly (both Windows and Web are supported) and the target mapping file location are specified.
  2. A Logical views description area, where the Logical view in the referenced assembly are enumerated and all their PropertyMappings, Events and Commands can be explored via a tree arrangement
  3. A Physical View description area, there the Physical views in the referenced physical views library are enumerated and can be browsed. For each Physical view the properties, controls, methods and events can be browsed recursively
  4. A DirectMapping area, where all the existing DirectMapping of a selected field can be browsed and configured
  5. An AdapterMapping area, where the existing adapter mappings can be browsed and configured.
  6. A mapping viewer pane, where the mapping XML is displayed

To map a logical view to a Physical control you can simply drag and drop the logical view in the Logical view pane (2) into the desired Physical View in the Physical view description area (3).

After a logical view is associated to a physical view it is possible to proceed and map its propertyMappings, its events and its commands by dragging and dropping them. A wizard will show how the binding will have to be performed and allows selection adapter binding, whether the binding is bidirectional, etc.

Once the binding is configured it will appear either in the DirectBindings pane and in the AdapterBinding Pane and it will be further configurable.

Building the Physical View Binding File Manually

The Physical View Binding file is an XML file as is a work unit file and can be built manually. Shown below is an example.

<?xml version="1.0" encoding="utf-8" ?>
<PhysicalViewMappings>
   <PhysicalView 
    WorkUnitName="wu1" 
    ContainerName="mchContainer1" 
    Name="ShoppingCartPhysicalViews.ShopingView, ShoppingPhysicalViews, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" 
    LogicalView="ShopingView, ShoppingLibrary" 
    Provider="WindowsPhysicalProvider">
  <Fields>
    <Field Name="ProductTable" TypeConverterAssembly=”MyTypeConverter”>
      <DirectMapping BiDirectional="false">Products</DirectMapping>
    </Field>
    <Field Name="ProductSelect">
<AdapterMapping BiDirectional="true" Init=”Normal” Type="NoCheckFieldAdapter">CompatibleLoanProductsListBox.SelectedIndex</AdapterMapping>
    </Field>
    <Field Name="Price">
      <DirectMapping BiDirectional="true">Price.Text</DirectMapping>
    </Field>
  </Fields>
  <Events>
    <Event Name="AddToCart">
      <DirectHandler>button2.Click</DirectHandler>
    </Event>
  </Events>
  <CommandHandlers>
    <CommandHandler CommandName="FillDefaultValues">
      <DirectHandler>FillValue</DirectHandler>
    </CommandHandler>
  </CommandHandlers>
   </PhysicalView>
   <Adapters>
        <AdapterReference field="true" fieldComposite="false" Name="NoCheckFieldAdapter" Type="Microsoft.Ccf.Samples.Helpers.NoCheckFieldAdapter, Microsoft.Ccf.Samples.Loan.UI.Web"/>
   </Adapters>
<PhysicalViewMappings>

PhysicalViewMappings/PhysicalView: Each one of these nodes represents a binding between a physical view and a logical view. The attributes of the elements determine how this mapping will be applied:

  • WorkUnitName: [Optional] Determines the workunit to which this mapping applies. If unspecified all the workunits will be able to use this mapping for that logical view.
  • ContainerName: [Optional] Determines the container to which this mapping needs to be applied. If unspecified this mapping holds for all the containers, if specified it allows to define particular physical views that only apply to particular containers when a logical view can be presented in more than one container. This allow form factor or context adaptation of physical views.
  • Name: the name of the physical view, identifying it. This can be a fully qualified name of a Winform Control or a Web Control embedded in an assembly or can point directly to the virtual path of the web control to display.
  • For example: "ShoppingCartPhysicalViews.ShopingView, ShoppingPhysicalViews, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" or “/PhysicalViews/ShoppingCart.ascx”.
  • LogicalView: The fully qualified name of the logical view definition this mapping needs to be applied to.
  • Provider: The Physical provider to be used. This can be a fully qualified name of a Physical provider class or a reference to a tag that will be then mapped in the PhysicalProvider configuration section (see **Error! Reference source not found.**1

The body of the PhysicalViewMappings/PhysicalView contains the details of the mapping to be performed and is composed by three sections related to Fields, Events and Commands:

PhysicalViewMappings/PhysicalView/Fields/Field: Each one of these represents a mapping of one of the PropertyMapping of the logical view with one or more controls in the Physical view. Each Field is identified with the Name attribute that must coincide with the LogicalView PropertyMapping name. To each filed one can associate a collection of mapping, of 2 kinds: DirectMapping and AdapterMapping. Each Field can also specify a custom TypeConverterClass, that will handle the type conversions in a custom way. The default MCE TypeConverter implements conversion from all the .NET core types. See **Error! Reference source not found.**1

In the DirectMapping one specifies directly the path to the property that will have to be bound, with the possibility to browse in the Physical view hyerarchy using the standard C# notation. An optional attribute (the default value being false) specifies whether the binding is bidirectional or not. If the binding is not bidirectional the data will only flow from the workflow to the physical view and not vice versa. This is particularly useful for read only fields that are meant to be set but not modified by the physical view.

In the AdapterMapping the mapping is mediated through an Adapter. Basically the adapter receives the data and the binding information, and it will be up to it to actually move the data in and out. This allows costomization of the actual binding mechanism and the introduction of resusable binding logic when necessary.

An adapter binding needs to specify the adapter name (as referenced in the adapter section, see below), an initialization string (allowing parametrization of the adapter itself) and again whether the binding is bidrectional or not. In the body of the node one specifies the binding target. This target will be interpreted by each adapter and mey be adapter specific.

PhysicalViewMappings/PhysicalView/Events/Event: Each one of these nodes represents an event binding between a physical view and a logical view. The name provided as an attribute must coincide with one of the events handled by the logical view. Also for this kind of binding there are two modalities: DirectMapping, specifying a C# path to an event source and AdapterMapping specifying an adapter reference, an init string and a binding path to be interpreted by the adapter itself.

PhysicalViewMappings/PhysicalView/Commands/Command: Each one of these nodes represents a command binding between a physical view and a logical view. The name provided as an attribute must coincide with one of the command handled by the logical view. Also for this kind of binding there are two modalities: DirectMapping, specifying a C# path to apublic method in the physical view and AdapterMapping specifying an adapter reference, an init string and a binding path to be interpreted by the adapter itself (that in this case could be also null in case the adapter executes the command independently on the physical view itself, a technique useful to attach commands to physical views without using code behind.

Note that the mapping will be applied from more specific to less specific: if a Physical view is found for a given workunit and a given container, it will prevail on another physical view defined for the same logical view but without a specification of workunit and container. If the workunit field is omitted the container one needs also to be omitted.

A Physical mapping file can be placed as an embedded resource in a Physical View library (Winform or Web). The engine will find it and will automatically source in its information. Also note that the binding information can always be overridden at the host level in the index configuration file (see **Error! Reference source not found.**1