Blog

XAML Control Unification Changes in 2010.2

[Infragistics] Devin Rader / Tuesday, June 15, 2010

Starting with our 2010 Volume 2 release of both our Silverlight products and our WPF products, we are unifying the development of the controls included in these products and creating a single XAML control code-base.  As part of the process of unifying the code, we needed to make some breaking changes in the controls including changing the Silverlight controls names, improving the namespace structure of the control libraries and simplifying the control assembly name pattern. While making breaking API changes in our controls is not something we take lightly, this post describes why we made the changes we did and talks about how you can update your application to move to the new product versions.  Note, the changes described here do not affect the existing WPF controls like XamDataGrid, but WPF controls introduced in 2010.2 and later will follow the patterns outlined here.

Control Names

A primary goal in unifying our XAML controls is to make sharing code between WPF and Silverlight as painless as possible. That of course means that including the word ”Web” in the control names no longer makes sense because the same controls can be used in both desktop (WPF) and web (Silverlight) applications, therefore this portion of the control class name prefix has been removed for all of our Silverlight and Silverlight Data Visualization controls.

To upgrade an existing Silverlight application that uses these controls you simply need to remove the “Web” portion of the control names. You can do this manually as demonstrated shown below or if you use the newly revamped Version Utility application which ships with 10.2, it will make the appropriate changes to your XAML:

<ig:XamWebGrid x:Name=”xamWebGrid” />

becomes

<ig:XamGrid x:Name=”xamWebGrid” />

If you are creating instances of controls in code, you will need to manually update and class names:

XamWebGrid xamWebGrid1 = new XamWebGrid();

becomes

XamGrid xamWebGrid1 = new XamGrid();

Control Namespaces

We have a lot of controls. Between all XAML products we currently have over 60 unique controls. With the first few releases of our NetAdvantage for Silverlight controls we followed Microsoft’s namespace pattern, putting all of the controls into a single Controls namespace. At the same time, in our Data Visualization for Silverlight product we had a different namespace patterns. We wanted to unify the experience between the controls in these different products.

Additionally, as we looked forward, we realized that as the product grows the number of classes in that single namespace would explode making navigation the API unwieldy.

Lastly, we knew that we were moving to a single XAML codebase for developing WPF and Silverlight controls, with the goal of allowing you to easily share code between the two platforms and we want to create a single unified namespace schema that would work in both platforms.

To solve these different problems we mocked up several different namespace alternatives which we tested both internally and externally. Based on the data from this research, we are introducing a new namespace pattern that subdivides the controls into a series of categories which will make navigating the API easier as the products grow. We have also removed the platform specific monikers from the namespaces to make sharing code between WPF and Silverlight easier.

The result is a set of simplified namespaces that are consistent across product and XAML platforms. The pattern has two main namespaces for UI controls:

Infragistics.Controls.[Category] – Contains the primary control classes. This includes the main controls as well as any other classes that you would use in XAML to configure the control.

Infragistics.Controls.[Category].Primitives – Contains the secondary control classes. This includes secondary controls that the main controls use and are not used directly in XAML to configure the control but may be restyled.

To help provide a consistent experience across all the Infragistics touch points, the use of these categories will be extended to our website, forums, the product documentation and samples and anywhere else we provide information on the XAML controls.

Frameworks/Non-control libraries

While we ship a lot of controls we also have a variety of other non-UI control libraries and frameworks that we ship, including the Excel library, Compression library, Persistence framework and Drag & Drop framework. In the new namespace pattern, these libraries generally end up in their own namespaces:

  • Infragistics.Persistence
  • Infragistics.Excel
  • Infragistics.Compression
  • Infragistics.DragDrop
  • Infragistics.Collections

Upgrading

Upgrading to the new namespaces is relatively painless. As with the control names, using the Version Utility to upgrade your projects will help automate the change of namespaces in XAML and in code. The Version Utility will change any xmlns definitions in XAML, and Using or Imports statements in code which reference the old namespaces.

public class Foo
{
    public Infragistics.Silverlight.Controls.XamWebGrid grid = 
        new Infragistics.Silverlight.Controls.XamWebGrid();
}

becomes:

public class Foo
{
    public Infragistics.Controls.Grids.XamGrid grid = 
        new Infragistics.Controls.Grids.XamGrid();
}

If you to use the Version Utility to upgrade an existing Silverlight project you will also get the benefit of having the XAML namespace definitions changed to use the new Namespace URI syntax:

xmlns:ig=”http://schemas.infragistics.com/xaml”

xmlns:igPrim=”http://schemas.infragistics.com/xaml/primitives”

The benefit of this new syntax is that it removes the need to place explicit namespaces and assembly names (which contain version numbers in their names) in your XAML files, and instead allows you to use a generic URI. This means that the next time you need to upgrade to a new version of Infragistics controls, you won’t need to alter the namespaces, and it also reduces the number of Infragistics specific namespaces you need to add to your XAML.

Assembly Names

Finally, in this release we are changing the assembly names to match the categorization pattern described above as well as shortening the platform moniker included in the assembly name pattern.

For example, the 2010.1 XamWebGrid assembly changes from:

Infragistics.Silverlight.XamWebGrid.v10.1.dll

to:

InfragisticsSL4.Grids.XamGrid.v10.2.dll

As new WPF assemblies are added they will also follow this assembly name pattern. For example the new WPF XamContextMenu controls assembly name is:

InfragisticsWPF4.Menus.XamContextMenu.v10.2.dll

Upgrade

Upgrading the assemblies is really no different than upgrading previous releases of NetAdvantage. You can us the Version Utility to automate the process of replacing the appropriate assembly references in your project files.

Conclusion

While making breaking API changes is never something we do without a great deal of thought, the changes we are making in the 2010.2 of our XAML controls has a lot of short and long term benefits. In summary, these changes mean for you:

  • The ability to share more code across Silverlight and WPF platforms
  • A simple and organized namespace pattern that can grow as the product expands
  • Less hard coded namespace and assembly information in your XAML files making future upgrades easier

We’ve tried to make the upgrade process as painless as possible by completely rewriting our Version Utility and we would encourage you to take advantage of it.

We’ve also added additional documentation that talks about the namespace changes in detail.  You can find out more information about that on Tom Puglisi’s blog.

As always if you have any questions or comments about the changes and how that will affect you, please feel free to reach out to us via email (devinr@infragistics.com) or via Twitter (@infragistics) and let us know what you think.