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 Silverlight project I'm working on used the RIA Business Application template from MS. It had all their styles in an 'assets' folder and the file was called Styles.xaml. I've been sticking to their organization and like it, though I've also added separate folders for "dialogs" and custom "controls."

You can download their sample here, which may answer your questions: http://blogs.msdn.com/brada/archive/2009/07/10/amazing-business-apps-example-updated-for-silverlight-3-rtm-and-net-ria-services-july-update.aspx

Answer 2

Sorry for plugging my own stuff (or if it's not allowed/frowned upon in SO), but I had a quick go at blogging about my experiences of reorganising the resources in a large-ish Silverlight 2 (i.e. no MergedDictionaries) project a while back. Post is here.

Answer 3

I would agree to your last suggestion: Place the common part of all the textboxes into a style-dictionary, which can then be loaded by the application/page/control, depending on what level shares this common part. The non-common part should IMHO be set in the textbox-instances directly, there is no use for another style unless you reuse this special setting in several textboxes.

I personally collect all "common" styles (for textbox, combobox etc.) in a single resource.xaml. I separate styles in additional xaml-resource-dictionaries only if I may wish to exclude them for some purpose. For example, I put the styles for components from 3rd-party-vendors into seperate resource-files, s.th. I can load my common resource-file "standalone" in applications, that don't reference this 3rd-party-lib. Similarly, I seperate project-specific styles (colors suited to customers' corporate identity) from global styles (customer independent product styles), quite similar to the guidelines that should hold for class inheritance. My application then loads all the resources, s.t. user controls don't need to know about them.

Answer 4

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".