When does using styles that are based on other styles become excessive? - wpf

Question

As a parallel to DRY for code I don't like having the same property assignments in XAML. I've seen code examples where quite a bit of code can be consolidated as a style. Once that's done and cleaned up more code can be represented by another style that's based on the initial style that has some more specific edits, and so on. There comes a point where this leads to styles that are way to "clever". A change in one of the styles leads to a cascading affect to all those that depend on it. Is there a rule of thumb or general guideline to remember when using Style ... BasedOn={...}?
An example from Head First C# and using the WPF version. On page 754 they have the example shown below. As this is an introduction there are several property assignments that can be consolidated using styles.
<StackPanel Margin="20">
<TextBlock Foreground="White" FontFamily="Segoe" FontSize="20px"
FontWeight="Bold" Text="{Binding TeamName}" />
<TextBlock Foreground="White" FontFamily="Segoe" FontSize="16px"
Text="Starting Players" Margin="0,5,0,0"/>
<ListView Background="Black" Foreground="White" Margin="0,5,0,0"
ItemTemplate="{StaticResource PlayerItemTemplate}"
ItemsSource="{Binding Starters}" />
<TextBlock Foreground="White" FontFamily="Segoe" FontSize="16px"
Text="Bench Players" Margin="0,5,0,0"/>
<ListView Background="Black" Foreground="White" ItemsSource="{Binding Bench}"
ItemTemplate="{StaticResource PlayerItemTemplate}" Margin="0,5,0,0"/>
</StackPanel>
Refactoring using styles to remove duplicated property assignments. This shows an intermediary step where the Margin property could further be consolidated.
<StackPanel Margin="20">
<StackPanel.Resources>
<Style x:Key="whiteForground" TargetType="TextBlock">
<Setter Property="Foreground" Value="White" />
<Setter Property="FontFamily" Value="Segoe" />
</Style>
<Style TargetType="ListView">
<Setter Property="Margin" Value="0,5,0,0" />
<Setter Property="Background" Value="Black" />
<Setter Property="Foreground" Value="White" />
</Style>
<Style x:Key="appliedMargin" TargetType="TextBlock" BasedOn="{StaticResource whiteForground}">
<Setter Property="Margin" Value="0,5,0,0" />
</Style>
</StackPanel.Resources>
<TextBlock Style="{StaticResource whiteForground}" FontSize="20px"
FontWeight="Bold" Text="{Binding TeamName}" />
<TextBlock Style="{StaticResource appliedMargin}" FontSize="16px"
Text="Starting Players" />
<ListView ItemTemplate="{StaticResource PlayerItemTemplate}"
ItemsSource="{Binding Starters}" />
<TextBlock Style="{StaticResource appliedMargin}" FontSize="16px"
Text="Bench Players" />
<ListView ItemsSource="{Binding Bench}"
ItemTemplate="{StaticResource PlayerItemTemplate}" />
</StackPanel>

Answer 1

I try to stick with only one level of basedon.
So base style, one inheritance (leaf) style only.
But, obviously, with set values overriding any in the control the leaf is used on.
At most another layer.
There are several reasons for this.
1)
It's a nightmare tracking complex inheritance - as you have probably realised.
2)
There used to be ( and probably still is ) a potential problem with resource dictionary chaining (rd).
What you'll want to do is have your styles in rd.
These often get big pretty quick.
So you split them up into a number of rd.
You want to base one on another so that needs to know about the base style.
You therefore merge the base one in within the leaf rd.
One layer of merge dictionaries like:
<ResourceDictionary
...
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="pack://application:,,,/Blaa.Validation.UILib;component/Resources/UIlibResources.xaml"/>
</ResourceDictionary.MergedDictionaries>
<Style TargetType="{x:Type ComboBox}" BasedOn="{StaticResource ErrorStyle}"/>
<Style TargetType="{x:Type DatePicker}" BasedOn="{StaticResource ErrorStyle}"/>
Here the combobxox style is basedon the errorstyle in UILibResources.
That works OK.
If a rd merges another rd that in turn merges another rd... and so on.
You can have mysterious problems which seem to come from a delay in merging.
I've seen intermittent errors and styling problems.
I think there is therefore best to keep that chaining shallow and the base resource dictionaries small.
This could have been fixed in recent versions of the framework but I've seen nothing mention it and there's very little changed in WPF for quite some time now.
3)
It's all too easy to find you need this level before that but it depends on something else if you try and get too "clever".
It'd be great if styles cascaded or there were mixins but they don't and we haven't.
So this basedon stuff is all we have and it's kind of clunky compared to the web.

Answer 2

Take a look at Dependency Property Value Precedence