Josh Smith: Thinking in WPF
I admire Josh Smith and his WPF knowledge. I’ve learned a lot about WPF from reading his articles, posts, and samples. Recently, Josh wrote 10 tips which he refers to as rules of thumb when thinking in WPF. Read his post to get the details on each of the tips below.
- Do not hesitate to write code.
- Keep your XAML dumb.
- Keep visual resources out of value converters.
- Create modular value converters.
- Expose functionality as services, not subclasses.
- Think thrice before creating a custom control.
- Do not micromanage, let panels do the work.
- Carefully consider where to put resources.
- Strive for elegance, not eye candy.
- Avoid being a Blender.
As a creative developer, I have to disagree with tips 1, 2, and 10. With the power of triggers, transforms, control templates, and databinding, I like to make my XAML smart and write code only when it’s necessary. While it’s helpful to know how to perform functionality in code, it can be more beneficial to do it in XAML. A designer would have a hard time modifying the design if everything was done programmatic. Also functionality from procedural code cannot be changed in Expression Blend. Chris Idzerda has more details in his post Prefer descriptive code (e.g. XAML) to procedural code (e.g. C#). Funny enough, Chris’ WPF mantra is “don’t write code”.
Paul Stovell’s XAML and WPF Coding Guidelines
Paul Stovell has written an excellent post about XAML and WPF coding guidelines:
http://www.paulstovell.net/blog/index.php/xaml-and-wpf-coding-guidelines/
I think his section on structuring resources is specifically interesting. Family.Show’s AppStyles.xaml Resource Dictionary could’ve benefited from Paul’s advice. As we customized the look and feel of the application more and more, the AppStyles got bigger and disorganized.
Blend has Resources panel that shows all the resource dictionaries found in the current open project. By organizing the shared resources by types as Paul described, it would’ve made it easier to find the resources and maintain them.
However, I disagree with breaking out page specific resources into their own resource XAML file. Original I went down this path as well and it added more bloat to the project and the application more difficult to work with in Blend. I would keep the page/window specific resources in the .Resources section of the page/window.
