Proposed Architecture Draft Only
Please provide feedback in forum post: Proposed Control Architecture

Overview

The aim is to produce a control that is both useful and reusable for GIS Silverlight projects.
The specific goals are:
  • Seperate the actual map implimentation from the control so it can used with any map control
  • Maximium design flexibility
  • Easy to maintain, version, test, deploy
  • Full featured with no restrictions

Solution

Abstract Control and implimentation per base map

DEControlArch.png
  1. Every control will have a project for the abstract control that defines what events, method and properties the map must expose in order to support this control as well as the generic implimentation (Purple).
  2. Then for every map control (Green) a project is created that impliments this class (Orange).
  3. A common Interface IMapControl<T> will expect the specific Map object as "MapInstance" and have a helper property "MapName" to allow this to be set in XAML. The control will have to impliment IDisposeable
  4. A common project (Blue) will contain generic classes for constants, entities and enums. For example a "Location" class for Latitiude/Longitude. We will leverage a OGC compliant framework to produce many of the common elements.
  5. A common helper project for each base control (Green) will contain common functionality like type convertors or common methods.

Parts and states model

This model is well documented by Microsoft and allows design tools like Blend to render the controls and provide the designer with tools to completely redesign the control. Essentially a "generic.xaml" template is created but only the essentials parts and VSM states are essential, everything else can be redesigned as the designer see's fit.
Information links here:
http://www.silverlightshow.net/items/Creating-a-Silverlight-Custom-Control-The-Basics.aspx

Other

  • All strings for parts and states are defined as constants
  • We use a consistant nameing pattern for parts
  • We use a consistant nameing patter for states
  • We use a "GoToState" method for all state changes.

Example

Coordinate Panel Control

DeepEarth.Client.Controls.CoordinatePanel
References:
  • DeepEarth.Client.Common
2 files:
  • CoordinatePanel.cs - Logic for the control and Abstract methods, events and properties to be implimented.
  • generic.xaml - Generic template for the control
"CoordinatePanel.cs" is setup as per the Parts and States model, using OnApplyTemplate() to get its parts. All map related method, properties and events are handled by creating them abstract.

DeepEarth.Client.Controls.CoordinatePanel.BingMaps
References:
  • DeepEarth.Client.Common
  • DeepEarth.Client.Controls.CoordinatePanel
  • Microsoft.VirtualEarth.MapControl
  • DeepEarth.Client.BingMaps
1 file:
  • CoordinatePanel.cs - Implimentation of the Abstract Class.
The Bing Maps instance will be set as property "MapInstance". Here we wire up the required events, properties and methods and convert the map specific entities into the generic ones. The BingMaps helper project removes any duplicate code needed for every control and every conversion

Your application - page.xaml.cs
  1. Simple put the Specific map control on the page eg BingMaps CoordinatePanel
  2. set the MapName property of the control in XAML to the name of the Map control
    <Grid x:Name="LayoutRoot" Background="White">
        <m:Map x:Name="map" />
        <c:CoordinatePanel x:Name="coord" MapName="map" />
    </Grid>


Last edited Jul 1, 2009 at 4:41 AM by soulsolutions, version 7

Comments

soulsolutions Jun 30, 2009 at 10:58 PM 
Ok I've up dated the page changing to a Abstract class. This dropped the interface and made the whole thing a bit neater, essentially go from 3 files down to 2.
@crpietschmann I've added a property "MapName" that will now let us set the MapInstance by name in XAML.
Last thing for me to look at is whether I can enforce the naming conventions using an interface or something that has some benifit. Also going to make a common project for each base map with static helper methods to remove any need for duplicate code.

soulsolutions Jun 18, 2009 at 12:09 AM 
Both great points.
@earthware For development it will be nice to keep everything seperate but no reason why we couldn't make a release that bundles all the stable controls into one dll.
@crpietschmann lets do it, its just some extra markup, i have actually never passed another control this way though. Will look into it but ping me if you already know how it is done.

crpietschmann Jun 17, 2009 at 8:58 PM 
Looks good, but it would be nice to be able to specify the "MapInstance" and specific Implementation declaratively, like this perhaps:

<Grid x:Name="LayoutRoot" Background="White">
<m:Map x:Name="map"></m:Map>
<CoordinatePanel:CoordinatePanel x:Name="coord" HorizontalAlignment="Right" VerticalAlignment="Bottom" Margin="0,0,5,35" RenderTransformOrigin="1,1">
<CoordinatePanel.MapInstance>
<CoordinatePanelMap MapInstance="map" />
</CoordinatePanel.MapInstance>
</CoordinatePanel:CoordinatePanel>
</Grid>

earthware Jun 17, 2009 at 6:51 AM 
Looks a good platform to start creating a great library. I especially like each control having its own project so we dont have to include a massive dll for just one control. I wonder if we can find a simple way for users to pick and choose controls but compile their choices into one dll?