Farr far away....

• Lap Around WPF
• WPF Tools ( Blend, Visual Studio 2008)
• Graphics Subsystem
• Layout
• WPF Fundamentals and new concepts
  • Application Model
  • Dependency Properties
  • Trees (logical & visual)
  • Events
  • Threading
  • Resources
• Controls
• Styling
• Templating
• Q&A with instructors at end of day

• WPF integration with Win32 and Windows Forms
• Data binding
• Introduction to Model-View-ViewModel
• Commanding in M-V-VM
• Views, Navigation and Transitions
• Data Validation
• Error handling, Model dialogs, Logging
• Unit Testing
• MVVM & LOB tips and tricks
• Q&A with the instructors

Karl Shifflett was the first presenter, and if you read my previous posts on XAML, I have been reading his blogs for a long time and can say they have helped changed my perception of development in WPF.   I am going to summarize what he talked about as I am extremely tired after a long day of listening….  Karl talked about Databinding and how powerful it is.  Databinding is basically WPF 101.  He then talked about specific XAML features such as DataTemplates, ControlTemplates, ItemTemplates, ItemsPresenter, ValueConverters, and DataTempleteSelectors.  I love ValueConverters but you do have to be careful not to overuse them.  Basically, you need to decide whether to create a ValueConverter or convert parameters within the View Model itself.  My rule is if a converter is needed in multiple Views then it warrants a ValueConverter, however if it is a date conversion for a specific view, it should be placed in the View Model.  He briefly talked about data triggers, which Jaime would later say shouldn’t be used.  Sorry Jaime I would disagree with that statement.  I believe there is a separation between Business Logic and Design Logic and Data Triggers are completely valid for Design Logic. 

Here are some things I learned from Karl:

DataTemplateSelectors -  I don’t think they are necessary.  You are basically creating a resource outside your View-ViewModel relation and I feel that this can be contained within this relation view DataTemplates, binding, and DataTriggers.

CollectionViewSource – Represents a layer on top of the binding source collection.  It allows sorting, filtering, and grouping of data before being displayed in a view.  Very, very cool….

Debug of Data Binding – Karl talked about an interesting way to debug data binding a little further.  By adding System.Diagnostics and Trace levels to a binding source the output can display more detailed information if a binding error occurred.  Below is an example of how this can be implemented.

   1: <Window

   2:   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   3:   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

   4:   xmlns:diag="clr-namespace:System.Diagnostics;assembly=WindowsBase"

   5:  

   6: <TextBox.Text>

   7:        <Binding Source="{StaticResource myDataSource}" Path="PersonName"

   8:                 diag:PresentationTraceSources.TraceLevel="High"/>

   9:  </TextBox.Text>

Jaime Rodriguez was the next presenter and started his presentation giving an architectural perspective of the MVVM pattern.  I was happy he gave props to Martin Fowler, one of the founding architects of this pattern.  Jaime explained the concept of MVVM and the idea behind the separation between Views and Models.  He also talked about the benefits of MVVM such as modularity, loosely coupled code, and testability. 

Jaime next talked extensively about Commands.  He discussed RelayCommands, DelegateCommands, and the DelegateCommand in the MVVM Tool kit.  Commands are very important to binding in that they enable you to route events from Views to ViewModels.  The benefit of this is that you do not have to write any code behind in the view and your business logic from a command is separate from your design.   I have used RelayCommands and DelegateCommands in the past.  Relay Commands use CommandManager which provides command related utility methods that register command bindings.  DelegateCommands are part of PRISM, so to use DelegateCommands you need to add the Microsoft.Practices.Composite.dll.  DelegateCommands in the MVVM Tool kit are quite interesting as you do not need a Command Manager nor the Microsoft.Practices.Composite.dll.  I definitely have to play with this a little more.