Akash Kava

This is Preliminary documentation about UI Delegation Pattern to create Clean and Reusable Data Components and UI Markups in a Business Application.

UI Delegation Pattern

I would call it simply divide and rule, UI Delegation Pattern is narrowing the focus towards piece of UI Element on the screen and have a UI component to fulfill every specific business needs.

User Interface is the direct connection between User and your business application, thought MVC, MVVM models exist, but they are found to be very useful in CRUD business applications, but when your application is more then CRUD and it involves complex UI and media / hardware interfaces for scientific and entertainment related applications, MVC/MVVM are little difficult to maintain over huge applications. This pattern is already in existence at many places.

Initial Rough Draft

This is initial rough draft, I intend to collect problems and solutions and then I want to give a good name to this pattern, for now I am calling this as “UI Delegation Pattern” however I don’t know whether it suits the name correctly or not. But your opinions are most welcome, if such pattern is already named and exists then I am sorry if I am unaware of it, but please suggest if you know so.

UI Markup vs. Editor Files

Earlier Visual Basic or Visual Studio would create .frm and resource files that would contain the contents of UI design created in “Designer/Editor” inside an IDE. These Editors would create code that is required to execute at runtime to create desired user interface. However since Editors would create code with specific style and pattern, these editor files are more or less very structured and they are less buggy. Of course too much of code will certainly make Editor very slow but at the same time, the consistency of UI code is preserved. But you are too much dependent on the Editor and complex UI could be very difficult to work in Editors.

Where else UI Markup based on xml, gives full freedom to user to create highly complex UI, but at the same time there is no consistency left as everyone writes code very differently. Markups gets piled into one file and it becomes way to difficult to maintain and understand how it works.

Identify Markup Noise

My first approach is to identify problems with Markup Noise, so lets identify what is markup noise. When I see any html, aspx, php or such web scripts, the most annoying things I discover that in spite  great CSS and Modular programming support, the scripts becomes a big junk to maintain. Sure WPF / Silverlight are also text markups, hand coded markups becomes way to big junk to manage.

Bigger problem is to visualize markups as they become more complex. As more and more lines of code gets piled into markup, more time is spent understanding and troubleshooting the UI.

How to Reduce Markup Noise?

CSS brought a very useful way to reduce markup noise. Still lot of developers write inline styles and I hate to see that. Ideally nicely written code should have inline styles as small as possible.

Appearance Delegation

CSS comes under category of Appearance Delegation where your delegate the look and feel of your component to CSS file. In WPF and Silverlight the themes are styles are introduced and you must have all your styles and look and feel related code into resources only.

The markup containers (Connection Containers) such as Window / Page / User Control should not have any inbuilt styles at all.

Business Logic Delegation

This was not possible in plain html, but aspx, php etc did brought concept of server side controls where in you could inject business logic specific to components and reuse them. But these components (user controls / custom controls ) are only designed when they need to be reused, but even if it will be used only once, I would still suggest its better to have components as small as possible.

Example, Country Combo drop down , Gender Combo drop down, these boxes are nothing but set of options provided to user to select one of them. Now nobody makes specific custom controls for such items, but lets see a practical example.

Bad Markup Example

    <Window.Resources>
        <XmlDataProvider x:Key="CountryData" XPath="/Countries">
            <Countries xmlns="">
                <Country
                    CountryName="United States"
                    CountryCode="US"/>
                <Country
                    CountryName="United States"
                    CountryCode="US"/>
            </Countries>
        </XmlDataProvider>
    </Window.Resources>
    <StackPanel>

        <ComboBox
            ItemsSource="{Binding Source={StaticResource CountryData},
                XPath=Country}"
            DisplayMemberPath="@CountryName"
            SelectedValuePath="@CountryCode"
            />

        <ComboBox>
            <sys:String>Male</sys:String>
            <sys:String>Female</sys:String>
        </ComboBox>

    </StackPanel>

Now this file defines a resource xml for Country List, and it is bounded by ComboBox to list countries and another ComboBox defines inline items to be displayed.

Let us identify “Controls and Connection Containers”.

The window, that hosts Country List and Gender Combo Boxes is “Connection Container” in which we should only host controls and connect inter dependent properties of every controls.

The Connection Container should not have any code that is not related to either any other items or business logic of the container at all.

List of Countries and Gender items are not at all related to anyone else except for the drop downs. This is pure markup junk where we have so many unnecessary information.

Solution

Define custom controls as shown below and see how small our markup becomes. And move Country List xml to some resource file.

    public class CountryComboBox : ComboBox
    {

        public CountryComboBox()
        {
            this.DisplayMemberPath = "@CountryName";
            this.SelectedValuePath = "@CountryCode";

            Binding b = new Binding();
            b.XPath = "Country";
            b.Source = FindResource("CountryData");
            this.SetBinding(ItemsSourceProperty, b);
        }

    }

    public class GenderComboBox : ComboBox
    {
        public GenderComboBox()
        {
            this.ItemsSource =
                new string[] {
                    "Male",
                    "Female"
                };
        }
    }

The final Markup.

    <StackPanel>

        <local:CountryComboBox
            />

        <local:GenderComboBox
            />

    </StackPanel>

Wow, the markup is very clean now. Also the code is easy to understand.

Conclusion

The connection container (Window / Page / User Control) should only have interdependent declarations and should not have any items that are only specific to one control. It should be as clean as possible and it should execute all necessary business logic for the component.

Configuration items, even resource bindings should be avoided in Connection Containers. They should be narrowed down to custom controls as much as possible.

This increases readability, reusability and helps in troubleshooting while focusing by narrowing the target.