Best Practice For Location Of Styles In Silverlight

Question

Where is the best place to put Style StaticResources? I have been putting the global and default styles in app.xaml and the page specific styles in page_name.xaml. Should every control have its own style StaticResource? Is it acceptable to put some style attributes right in the control? I have a page with 5 TextBoxes on it, should there be a style for each when the only difference is a Width or MaxLength property? Or should one style be defined with the common properties for each TextBox and the specific style properties be defined in the control element?

Answer 1

The hierarchy exists for a reason, it is probably a good idea to start simple, and local to an element you're working with, then move it out as it becomes necessary.

Your designers may also have special requirements that may trump this. For instance, a team sending many revisions around on some styles may want to contain all the style work to a single XAML file until it's ready for more.

Typical style hierarchy in reverse-order

The first few items are your "most baked" and most-often used styles, typically you'll want to start at the bottom and work your way up. It's nice to not have to work with multiple XAML files, too, and keep it contained.

Application-level (App.xaml)

App-level styles are going to be useful everywhere your app has its interface exposed, for common elements.

If you're using Silverlight 2, this is your best non-hack method to making your styles accessible throughout your app.

Be careful if regularly using App.xaml resources, since a unit test library that lives outside your app is going to be much more difficult to test since it won't pick up your application's app-level styles in some situations.

Merged dictionary

Merged resource dictionaries allow you to split your styles up into additional XAML files, making it easy to factor them by feature area, feature, control type, team name, etc. Learn about this feature.

Consider using this for app-level styles in situations where it makes sense, since you can then use them in separate projects and solutions.

Not available for Silverlight 2, this feature was added in Silverlight 3.

Page-level

Anything specific to a single page (might be a complete app, or a visual page, or part of an app) that doesn't bleed beyond the edges is a good candidate for this.

Feel free to start farther down the visual tree (such as the control level), and move those styles up as it makes sense.

At the Panel

Good to contain a bunch of similar pieces, like when formatting a form.

At the Control

Start here. When you style a control in Blend, it'll usually start here, unless you select the app-wide resource option.

This is the intermediate step between property setting and actually being a true style resource, sine it'll just be a setter for the Style property of the control - but you can easily add an x:Key and move it up in the visual tree when you are ready.

Implicit styles and themes

If your team or company uses a regular set of styles for all controls of a certain type (Buttons, CheckBoxes, you name it), consider using the Implicit Style Manager functionality (a value-add for Silverlight) to do implicit styles. This is similar to the WPF styling story, where you don't need to set the style in all places you use it.

I found a good tutorial online with a quick search for you to learn more about ISM.

When to use properties instead of shared, common styles

W.R.T. your question, if you have a set of text boxes where the differences are MaxLength, Width, etc., you should probably set those explicitly as properties on each control instance - if they are different.

Once you have a few (let's say, 3, elements) using the same values, it might make sense to pull it out and then start using a Style="{StaticResource keyName}" attribute. If you're typing XAML by hand, though, that's a lot more annoying than typing Width="20".