Andrej Tozon's blog

In the Attic


Dynamic Data Forms for Silverlight with a Data Template Selector Control

The basic idea behind this post is to show a simple way for items/list controls to display each item data with a different template. The ideal candidate for such exercise are data forms, where user can enter different kinds of information - text, numbers, check marks, etc. Imagine a scenario, where each data form field would be presented as a separate ListBox item… no matter of what data type that field is.

The data model for this solution is going to be very simple and generic. We’ll need a generic class, which will represent a single field in a form. Each field will have an id, a caption, a value (entered by the user) and a value type (what’s the type of the value – text, integer, date, etc.):

public class AutoFormField
    public Guid Id { get; private set; }
    public string Caption { get; set; }
    public string Value { get; set; }
    public string Type { get; set; }

    public AutoFormField()
        Id = Guid.NewGuid();

When the user requests a form, the associated web service will return a collection of AutoFormFields, representing all fields in the form that user should fill out. I’m not using any database for this example, so I’ve hardcoded the fields, returning to the client, in the service itself:

public class AutoFormService : IAutoFormService
    public Collection<AutoFormField> GetForm()
        Collection<AutoFormField> form = new Collection<AutoFormField>();
        form.Add(new AutoFormField()
            Caption = "Name: ",
            Type = typeof(string).FullName
        form.Add(new AutoFormField()
            Caption = "Last name: ",
            Type = typeof(string).FullName
        form.Add(new AutoFormField()
            Caption = "Birth date: ",
            Type = typeof(DateTime).FullName
        form.Add(new AutoFormField()
            Caption = "Is employed: ",
            Type = typeof(bool).FullName,
            Value = false.ToString()
        return form;
The above code shows that the form consists of two text fields, a date and a yes/no field. We would naturally want to display TextBoxes for text entry, DatePicker for a date, and a CheckBox for a yes/no field entry. The Type property contains an identifier, which will tell the client what kind of entry field to display; field data type names are used here for convenience.
Let’s move to the client and implement this.
I’ll use the ItemsControl to display the items, because I don’t need the notion of a selected item (yet). Let’s first get the basics out of the way; this is how the ItemsControl looks like, displaying all the form’s captions:
<ItemsControl ItemsSource="{Binding Fields, Source={StaticResource viewModel}}">
            <TextBlock Text="{Binding Caption}" />
Its ItemsSource property is bound to a ViewModel’s Fields property, which gets populated when a call to the GetForm() web service method returns. The ItemTemplate is set up so that TextBlock displays the fields’ captions.

What we need to do next is display the actual entry fields the user will fill in. I already mentioned the Type property; this will be the key in deciding what kind of control to display.

If we would be coding this in WPF, we would use a DataTemplateSelector to help us out with selecting the right template to load for a specific type. Unfortunately, this feature is not implemented in Silverlight, so we’re on our own here. As it turns out, there isn’t much code required to come up with a solution. This is something that I call…

… a data template selector control…

For our example, we need templates for: a TextBox, a DatePicker and a CheckBox. The following user control will accept all these templates as properties and contain logic to choose between them based on a certain property, which will be bound to AutoFormField’s Type property:

public class FormFieldTemplateSelector : UserControl { public DataTemplate StringTemplate { get; set; } public DataTemplate DateTimeTemplate { get; set; } public DataTemplate BooleanTemplate { get; set; } public DataTemplate SignatureTemplate { get; set; } public static readonly DependencyProperty FieldTypeProperty = DependencyProperty.Register("FieldType", typeof(string), typeof(FormFieldTemplateSelector), new PropertyMetadata(string.Empty));


public string FieldType { get { return (string)GetValue(FieldTypeProperty); } set { SetValue(FieldTypeProperty, value); } } public FormFieldTemplateSelector() { Loaded += new RoutedEventHandler(OnLoaded); } private void OnLoaded(object sender, RoutedEventArgs e) { string fieldType = FieldType; if (fieldType == typeof(string).FullName) { Content = StringTemplate.LoadContent() as UIElement; } else if (fieldType == typeof(DateTime).FullName) { Content = DateTimeTemplate.LoadContent() as UIElement; } else if (fieldType == typeof(bool).FullName) { Content = BooleanTemplate.LoadContent() as UIElement; } else { Content = null; } } }

The way to set it up in the item template is simple too. Here’s the complete ItemTemplate:

        <ColumnDefinition MinWidth="100" />
        <ColumnDefinition Width="*" />
    <TextBlock Text="{Binding Caption}" VerticalAlignment="Center" />
    <local:FormFieldTemplateSelector Grid.Column="1" FieldType="{Binding Type}" Margin="0,2,0,2">
                <TextBox Text="{Binding Value, Mode=TwoWay}" Width="100"/>
                <basics:DatePicker SelectedDate="{Binding Value, Mode=TwoWay}" Width="100" />
                <CheckBox IsChecked="{Binding Value, Mode=TwoWay}" />

Of course, this is just one way to put it together. You're free to style each field completely to your liking. This is what we have so far:

To wrap this up, you just have to add a button to submit the form back to the server. I’m not discussing this here since it’s pretty straightforward.

I will, however, continue to build up on this example in the next couple of posts. Some topics I’ll dig into is styling, positioning and more (interesting) templates. I’ll also post the full code in the final post of this series.

Disabling items in a Silverlight ListBox

This is a quick tip on making the ListBox items behave as disabled.

You know the semaphore, right? STOP on red, GO on green? OK. I’m drilling this with my two-year old when driving her to kindergarten every morning so lately it’s probably stuck in my mind a bit more than it should be.

OK. This is a ListBox:


Yes, it is:

<ListBox ItemsSource="{Binding Lights}" BorderThickness="0">
            <StackPanel Orientation="Horizontal" />
            <Ellipse Fill="{Binding Brush}" Width="50" Height="50" Stroke="Black" Cursor="Hand" />
        <Style TargetType="ListBoxItem" >
            <Setter Property="Template">
                    <ControlTemplate TargetType="ListBoxItem">
                        <ContentPresenter x:Name="contentPresenter" Margin="4" />

The data context of this ListBox is a ViewModel with the Lights property. Lights is a collection of five Light objects.

One property that the Light object exposes is the Brush property; it will simply point to a solid color brush of a red, yellow or green color, respectively. The Ellipse’s Fill property is bound to the Brush property as can observed in the above code.

Semaphores usually change colors in an order. The ones in this sample will blink randomly, changing their colors in 2 second intervals:

public Light()
    DispatcherTimer timer = new DispatcherTimer()
        Interval = TimeSpan.FromSeconds(2.0)
    timer.Tick += (s, e) => { this.SetColor(); };

private void SetColor()
    Color[] colorArray = new Color[] { Colors.Red, Colors.Yellow, Colors.Green };
    Color color = colorArray[randomizer.Next(0, 3)];
    this.Brush = new SolidColorBrush(color);
    this.IsEnabled = color == Colors.Green;

Now, we want to allow the user click only on green light, OK? The last line in the above SetColor method sets the IsEnabled property on the Light object only when the current color is set to Green.

With the IsEnabled property up and about, it gets really easy. To prevent the user from clicking on the ListBox item, simply set bind its IsHitTestVisible property to IsEnabled property on the Light class (bold underlined part added):

<ControlTemplate TargetType="ListBoxItem">
    <ContentPresenter x:Name="contentPresenter" Margin="4" 
        IsHitTestVisible="{Binding IsEnabled}" Cursor="Hand" /> </ControlTemplate>

[Cursor property is there for instant visual feedback on when the item is enabled]

That’s it, really. You can test it by adding i.e. a Click event handler to the contentPresenter and display a message box or something (included in the sample below). You would also want to build a better templates for the enabled/disabled items. If built around the bound IsEnabled property, it should work fine.

Declarative Role-based “security” for Silverlight Xaml elements

Tim Heuer published a great example on how to implement user authentication and role validation with ASP.NET Application Services in his Application Corner a while ago. It really works as expected, even with custom membership / role providers. And you get to do declarative role based security checks on your server side classes too.

When building MVVM pattern applications, you tend to have as less code as possible in your views’ code-behind classes. Call me a MVVM purist [ :), see Tim’s video interview for pixel8 ], but (close to) zero lines of custom code is what I like to have in my code-behinds. Not at all costs, but usually it doesn’t take much to code additional helper class, an attached property or a controller of some sort.

What I wanted to do, was replace the following piece of code with something more declarative, which could be used in Xaml:

private void EnableAppFeatures(ObservableCollection<string> roles)
    EmployeeButton.IsEnabled = (roles.Contains("Admin") || roles.Contains("HR"));
    OrderButton.IsEnabled = (roles.Contains("Admin") || roles.Contains("Sales"));
    CustomersButton.IsEnabled = (roles.Contains("Admin") || roles.Contains("Sales"));
    ReportsButton.IsEnabled = (roles.Contains("Admin") || roles.Contains("Sales"));

[the roles string collection comes in as a result of the Roles service call]

Solution #1 - Good

If you’re using MVVM, adding some additional properties to your ViewModels (like IsInHRRole, IsInSalesRole, etc) should be easy, right? You would just need to bind al the buttons’ IsEnabled properties to their ViewModel counterparts and you’re done.

<Button ... x:Name="ReportsButton" ... IsEnabled="{Binding IsInSalesRole}">

True, but you’ll probably end up “polluting” all your ViewModels with such properties since usually the majority of the Views have some elements, depending on a role the user is in. Additionally, you’d have to create additional properties for combined roles, e.g. IsInSalesOrAdminRole,

Solution #2 - Better

I was thinking somewhere in the lines of attaching a new attached property to each button, which would enable the button when the user would be in one of the specified roles:

<Button ... x:Name="ReportsButton" ... sec:SecurityAction.DemandRole="Sales,Admin">

SecurityAction.DemandRole in this case is an attached property, specifying all the roles, which would make the button enabled. The logic is simple – if the user is in one of the specified roles, the button (or any other control with this attribute appended) would have its IsEnabled property set to true. 

To make this possible, I first had to come up with a class to hold all the current roles, something like a Principal… This is a short class, supporting roles only that will do a job for this demonstration:
public class SilverlightPrincipal
    public static ObservableCollection<string> Roles { get; private set; }

    static SilverlightPrincipal()
        Roles = new ObservableCollection<string>();

    public static void SetRoles(IList<string> roles)
        for (int i = 0; i < roles.Count; i++)
    public static bool IsInRole(string role)
        return Roles.Contains(role);

    public static bool IsInOneOfRoles(string[] roles)
        for (int i = 0; i < roles.Length; i++)
            if (Roles.Contains(roles[i]))
                return true;
        return false;

The roles collection will contain all roles the user is currently in. IsInRole() and IsInOneOfRoles() will return true, if user is in one of the passed in roles. The SetRoles() method is here for simplicity – it servers just as a roles setter, called from wherever the Roles service calls returns.

Perhaps the class above probably doesn’t even deserve to be called a Principal, but it will serve well for the purpose of this post. For more ideas to implement a more complete Silverlight Principal, check this blog post.

To plug it in Tim’s code, I used the aforementioned EnableAppFeatures method, which now looks like:

private void EnableAppFeatures(ObservableCollection<string> roles)

The next thing to do was create the SecurityAction.DemandRole attached property that could be used to set the required roles to a specific control. You’ll find this attached property in the sample code attached to this post. I’m not including the code here because it will make this post much longer and I’m not really fond of using it anyway, because of the reasons for solution #3 below. However, feel free to try the property and please leave comment if you like (or dislike) it.

Solution #3 - Best

After creating #2, I thought – if user can never access the functionality behind the buttons, there is no need to show the buttons to her in the first place, right? Why not showing her the dashboard, created specifically for her role? Sounds familiar? ASP.NET? LoginView?

Here’s my simple LoginView control for Silverlight. You can define as many LoginView templates for as many roles you have:

        <controls:LoginViewDataTemplate Roles="HR>
            <!-- Layout for HR role -->
        <controls:LoginViewDataTemplate Roles="Sales>
        <!-- Layout for Sales role -->
        <controls:LoginViewDataTemplate Roles="Admin>
            <!-- Layout for Admin role -->
First, here’s the LoginViewTemplate class:
public class LoginViewDataTemplate : DataTemplate
    public string Roles { get; set; }
Yeah, that’s pretty much it. The Roles property will hold the list of roles, which are allowed to see the template.
The LoginView control itself is simple too:
public class LoginView : UserControl
    public Collection<LoginViewDataTemplate> Templates { get; set; }

    public LoginView()
        Templates = new Collection<LoginViewDataTemplate>();

        SilverlightPrincipal.RegisterForRoleChangeNotification(this, LoadTemplate);
        Loaded += (s,e) => { LoadTemplate(); };

    private void LoadTemplate()
        for (int i = 0; i < Templates.Count; i++)
            string[] roleNames = Templates[i].Roles.Split(new char[] { ',', ' ' }, 
                StringSplitOptions.RemoveEmptyEntries); bool isInRole = SilverlightPrincipal.IsInOneOfRoles(roleNames); if (isInRole) { Content = Templates[i].LoadContent() as UIElement; return; } } Content = null; } }

[Update 06-13: updated the above code; should work now]

There’s not much to comment here… The Templates collection holds the collection of, errr., LoginViewDataTemplates, and the LoadTemplate method is there to Load the first template, having one of the specified roles match the current role that user is in. This could be easily extended to support the default template, if needed. The default template would be loaded when no other template would match the current user’s role.

RoleChanged notification /execution

The right template is loaded with the control and whenever the Roles might change, the control would reload the template. I’ve implemented this behavior by adding a registration method for role change notification. Any visual element (or whatever object for that matter) can register itself by passing in the delegate to whatever method should be called whenever role(s) would change. The registration method was conveniently added to existing SilverlightPrincipal class:

public static void RegisterForRoleChangeNotification(object o, Action action)
    bool existsInCollection = references.Keys.FirstOrDefault(reference => reference.Target == o) != null;
    if (!existsInCollection)
        references.Add(new WeakReference(o), action);

Whenever the roles would change, register objects’ delegate would be called:

private static void OnRolesChanged()
    foreach (var reference in references)

The CleanUp method takes care for dead/disposed objects:

private static void CleanUp()
    List<WeakReference> list = references.Keys.ToList<WeakReference>();
    for (int i = list.Count - 1; i >= 0; i--)
        WeakReference r = list[i];
        if (!r.IsAlive)

Classes, included in the package: SilverlightPrincipal, SecurityAction, LoginView:

The magic happened… again

I wrote this short program some two years ago and yesterday came time for an upgrade.

Yesterday evening, a gift of life was given to another beautiful princess, Evita, 3730g, 51cm.

Her big sister is very proud and already looking after her, and mom’s doing great.