By Don Burnett
You need to fully understand these concepts..
- Composite application
- Regions
- User controls
- Creating custom user controls
- Data templates
- Presentation model
- Resources
Creating XAML
Definitions for creating user controls that you will need to remember:
View: A view encapsulates a portion of your user interface that you would like to keep as decoupled as possible from other parts of the application. You can define a view as a user control, data template, or even a custom control.
Region: A Region manages the display and layout of views. Regions can be accessed in a decoupled way by their name and support dynamically adding or removing views. A region is typically a hosting control. Think of regions as containers where views (or controls) will be dynamically loaded.
Layout
The shell is your main layout (in Blend formerly MainWindow.xaml now Shell.xaml). Each area is a region and should be kept empty (think container). Also, remember that control containers that act as regions are decoupled from the views (custom controls) they contain.
Rules
- Do not place content inside regions. If you do this, they will be loaded at runtime and cannot be dynamically loaded.
- You should think of the shell as being like an ASP.NET Master Page. It should only contain the background, titles, and the footer.
- You should be able to change the size of views without modifying the controls or change the size of the controls without modifying the views.
- If a view will be used in several regions or you don’t know where it’s going yet, design it with dynamic width and height.
- If views have fixed sizes, shell regions should use dynamic sizes.
- If shell regions have fixed sizes, the views (User Controls /Custom Controls) should use dynamic sizes.
- Sometimes the views (controls) may require you to set them to have a fixed height and dynamic width.
- Other types views (controls) may require a dynamic height and width. For example in number, a messages view (UserControl) maybe set up such that the height itself depends on the title's length, and the width should always adapt to the region's size (sidebar width). The same may apply to some other defined views, where the grid's width should adapt to the screen size and the height should adapt to the number of rows in the grid.
Animation
- Separate your controls animation from that of the shell, they must be animated (transitionally separately).
- Animate each view separately
Views
Each UI element must be designed separately. This makes it hard to visualize the composite page or window.
To visualize the composite view, you should do the following:
- Create a test project with a simple page or window that contains all the UI elements for the view you want to test.
- Work with the developer to define mock data to be displayed for each UI element in this simplified page or window.
Optimization
- Any common resource along all views should be placed in the App.xaml file (or merged dictionaries in WPF)
- To avoid duplicating styles, you should do this after the module's view is completely designed.
- Having the application resources in the main App.xaml file breaks the design view in Microsoft Expression Blend.
- A View may not be displayed properly if the module is tested by itself.
- It is better to leave this task for the end of the design phase.
When creating a Silverlight composite application, avoid using non-system fonts for static text that needs to be styled differently from the rest of the application. It is always better to convert the text to curves or embed the fonts.
Creating Mock Data (Warning for Designers: Visual Studio Code AHEAD!)
One of the things you have to be careful about when creating mock data to illustrate how a control will work and databind for the developer is creating it. Blend 3 gives you new mock data creation options. Below is a way (taken from the Composite Application Guidance Package) on how to do this in Blend 2 and below. It requires you to work in Visual Studio however..
The reason you still need to be mindful is that most views will be loaded to their corresponding containers at run time. Expression Blend renders elements defined in XAML through their default constructor, and in composite applications, the separated presentation patterns are used broadly to define views. Therefore, a good recommendation is to create a default constructor of the presentation model (or any view model used). This default constructor should be used to populate mocked data into the view. The following sample shows a default Presentation Model constructor that is populated with mock data.
public WatchListPresentationModel()
{
this.HeaderInfo = Resources.WatchListTitle;
this.WatchListItems = new ObservableCollection<WatchItem>();
this.WatchListItems.Add(new WatchItem("Policy30", 25.6m));
}
It is recommended that you use conditional compiling, so this default presentation model constructor is only used when you are, for example, in "Design mode."
The following code shows the default WatchList presentation model inside a conditional compiling clause; therefore, this constructor will only be used when the DESIGN constant is defined.
#if DESIGN
public WatchListPresentationModel()
{
this.HeaderInfo = Resources.WatchListTitle;
this.WatchListItems = new ObservableCollection<WatchItem>();
this.WatchListItems.Add(new WatchItem("Policy30", 25.6m));
}
#endif
To define the DESIGN constant load your project into Visual Studio, then right-click the project name click Properties, and then click the Build tab. In the Conditional compilation symbols box, type DESIGN to define the constant.
While in Visual Studio, this will affect your Debug configuration. Whencompiled in Release mode, this symbol will not be defined, so the default constructors with mocked data will not be part of the compilation results.
When the design phase is over, you should remove the conditional compilation symbol from the Debug configuration also, to avoid this extra code being compiled if the deployment is ever mistakenly done in Debug mode. The reference implementation uses the presenter-first approach to create the view and the PresentationModel. After the view is created, the PresentationModel is assigned to the Model property (which is just a typed wrapper of DataContext). Because this latter step is not executed in design-time inside Expression Blend, remember to set the presentation model as the view's data context in XAML to populate the view with the mocked data. If you defined a Model property in your user control, you can set the presentation model to this property.
The following XAML markup shows how to set the presentation model as the data context.
<UserControl x:Class="SomeClass.View"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:Converters="clr-namespace:SomeProject.Infrastructure.Converters;assembly=SomeAssembly.
Infrastructure"
Height="Auto" Width="Auto">
<UserControl.DataContext>
<WatchListPresentationModel/>
</UserControl.DataContext>
...
</UserControl>
Now you can reload the view in Expression Blend, and it will be populated with mock data.
Remember: When the styling for the view is complete, remove this declaration from the XAML. If it is not removed, mocked data will appear at run time, and will cause errors if compiled in Release mode, because there will be no default constructor for the presentation model..