Damian Schenkelman’s Blog

Today with Guido Maliandi, we set to find a way to use the Accordion from the Silverlight toolkit as region in a Prism application. As the Accordion inherits from ItemsControl, Prism already provided some functionality to get that control working as a region. However, we wanted it to have the following behavior:

• Only one view in the accordion region should be active at a time.
• It should be possible to set the header for each AccordionItem.
• It should be easy to extend with other required functionality.

If you are familiar with Prism’s source code, you might probably notice that is quite similar to the way Prism handles Silverlight’s TabControl as a region. Our approach was creating two classes:

• AccordionRegionAdapter: This class would be in charge of creating the region and hooking it up with the control.
• AccordionRegionSyncBehavior: This class would provide the region’s functionality.

Any other functionality that was necessary could be added through other RegionBehaviors. This document from the Prism documentation explains the usual process of creating a custom Region Adapter.

As the code for both those classes is quite long, I decided to simply provide the download at the bottom of this post.

Setting the AccordionItem’s Header Text

As it can be done with the TabControl region, the following syntax can be used to show some text in the header of each AccordionItem (in this case the View’s DataContext is simply a string). The outcome can be seen in the picture placed after the code.

<tk:Accordion Name=“MainRegion” Regions:RegionManager.RegionName=“MainRegion“>
  <shell:AccordionRegionAdapter.ItemContainerStyle>
    <Style TargetType=“tk:AccordionItem“>
      <Setter Property=“HeaderTemplate“>
        <Setter.Value>
          <DataTemplate>
            <TextBlock Text=“{Binding}“/>
          </DataTemplate>
        </Setter.Value>
      </Setter>
    </Style>
  </shell:AccordionRegionAdapter.ItemContainerStyle>
</tk:Accordion>

Sample Application

I created a small sample application which shows this scenario working. You can download it from here. The code is provided “AS IS” with no warranties and confers no rights.

I hope you can make good use of it.

This thread from the Prism forum presents the following question (this is not an actual quote but a summary): Are there any examples with multiple Shell windows, as the Prism documentation mentions?

First I re-read this article from the Prism documentation so I could get in the same page as the user. I’m not going to quote it here, but the “Implementing a Shell” section is the one where it is explained. Once I read that, the popular Popup Region from the Prism-v2 RI was out of the table so with Ezequiel Jadib we decided to create a small spike to see what changes needed to be done.

Creating Multiple Shells

As in a regular Prism application, using the CreateShell method to create the new Shell seemed like a good approach. However, as the RegionManager is set to the DependencyObject returned by this method, this had to be done manually for any other Shell window.

protected override DependencyObject CreateShell()
      {
          Shell1 shell = new Shell1();
          Shell2 shell2 = new Shell2();
          shell.Show();
          shell2.Show();
          shell.Activate();

          RegionManager.SetRegionManager(shell2, this.Container.Resolve<IRegionManager>());
          RegionManager.UpdateRegions();

          return shell;
      }

When to close the application?

Another thing to determine is when to close the application. This is not something “Prism specific” as WPF provides this option for any application. Since there are multiple Shell Windows, choosing the ShutdownMode=”OnLastWindowClose” seemed like the best approach.

<Application x:Class=“HelloWorld.App”
    xmlns=“http://schemas.microsoft.com/winfx/2006/xaml/presentation”
    xmlns:x=“http://schemas.microsoft.com/winfx/2006/xaml” ShutdownMode=“OnLastWindowClose“>

Sample Application

I created a small sample application which publishes an event in one of the Shell views and subscribes to it in the other. You can download it from here. The code is provided “AS IS” with no warranties and confers no rights.

The holidays are over, happy new year everyone and I hope it is a good one for all of you. It’s time for the first post of the year, which continuing last year’s trend will deal with Prism.

A couple of weeks ago this question in the Prism forum got Fer and I thinking how to set the name of views in a region using View Discovery. As Prism does not support this out of the box (which is kind of weird), we had a talk with Ezequiel and Julian and decided to use Prism’s extensibility to get this done (this means not changing the Prism source code at all ).

A couple of changes needed to be performed to achieve this functionality:

1. Create a new RegionViewRegistry. Its API would allow passing the name of the view as the parameter when registering it with a region:

public interface IRegionViewWithNamesRegistry : IRegionViewRegistry
  {
      void RegisterViewWithRegion(string regionName, Type viewType, string viewName);
      void RegisterViewWithRegion(string regionName, Func<object> getContentDelegate, string viewName);
  }

2. Extend the AutoPopulateRegionBehavior to register the view using its name. To get this done we inherited from the RegionBehavior base class.

Finally to check that everything worked correctly we created a small sample using the ViewDiscovery-UIComposition QS for Silverlight (the new registry and behavior must be registered in the bootstrapper).

You can download the code from here (use the ViewDiscoveryComposition.sln). The code is provided “AS IS” with no warranties and confers no rights.

About a week ago in the Prism forum we got a question about an issue in the scenario displayed below.

The Issue

When the MainView was removed from the MainRegion, the RightOne and RightTwo regions were not removed from the RegionManager and the views were still being referenced by the region. We were able to reproduce this issue “successfully” both using scoped regions and without them so we started thinking on a possible fix for this.

The Fix

After trying different things out, we took Julian’s suggestions and created a RegionBehavior that would be in charge of this. You can find the complete code for this class below:

public class ClearChildViewsRegionBehavior : RegionBehavior
   {
       public const string BehaviorKey = “ClearChildViews”;

       protected override void OnAttach()
       {
           this.Region.PropertyChanged +=
               new System.ComponentModel.PropertyChangedEventHandler(Region_PropertyChanged);
       }

       void Region_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
       {
           if (e.PropertyName == “RegionManager”)
           {
               if (this.Region.RegionManager == null)
               {
                   foreach (object view in this.Region.Views)
                   {
                       DependencyObject dependencyObject = view as DependencyObject;
                       if (dependencyObject != null)
                       {
                           dependencyObject.ClearValue(RegionManager.RegionManagerProperty);
                       }
                   }
               }
           }
       }
   }

When the RegionManager property of a Region changes to null, the behavior removes the view’s RegionManager attached property of all views in the region. Adding this behavior by overriding the bootstrapper’s ConfigureDefaultRegionBehaviors will enable this behavior for all regions:

protected override IRegionBehaviorFactory ConfigureDefaultRegionBehaviors()
        {
            var regionBehaviorTypesDictionary = base.ConfigureDefaultRegionBehaviors();
            regionBehaviorTypesDictionary.AddIfMissing
                (ClearChildViewsRegionBehavior.BehaviorKey, typeof(ClearChildViewsRegionBehavior));
            return regionBehaviorTypesDictionary;
        }

The Outcome

I have created a sample application showing how the fix works. You can download it from here. The code is provided “AS IS” with no warranties and confers no rights. I hope you can find this behavior useful if you have a similar kind of situation in your application.

As I probably won’t blog anymore until after the holidays, have a merry Christmas and a happy new year .

As I thought this is a question that could interest many people, instead of answering this question directly in the Prism codeplex forum I decided to create a short blog post and answer it here.

No longer necessary

<Button Content=“Save” Command=“{Binding Path=SaveOrderCommand}“/>

Still necessary

As there is not an actual implementation of the ICommand interface, the DelegateCommand and CompositeCommand are still useful. Also, as controls other than Buttons do not have the possibility to bind their events to commands in the ViewModel, using attached behaviors is a good approach. You can use this code snippet to simplify the work.

Wrapping up

I hope this helps clarify this topic a bit, and if you have any doubts drop by the Codeplex forum and ask away (if you are shy you can always leave me a comment).

In case you want a working sample, I have made a couple of changes to the Commanding Quickstart to use the Command property instead of Prism’s attached behavior. You can find it here. The code is provided “AS IS” with no warranties and confers no rights.

Most of you know that a Silverlight 4 Beta was released last Wednesday, after Scott Gu’s PDC keynote. If you are a Prism user, and if you are reading this there’s a high chance you are, you are probably wondering how this relates to p&p future plans. Well, Blaine has given us a brief idea of Prism’s future in this forum thread, so you might want to check it out.

On a related but different subject Fernando and I migrated the latest Prism release to Silverlight 4 Beta version & Net 4.0. A few minor changes needed to be done in the code (explained here), and some other in the .csproj files due to an issue we came up using the Silverlight migration wizard.

Migration Issues

After going through the migration wizard, you will notice that all Silverlight projects are not loaded. This is because they are still looking for the 3.0 installation directory instead of 4.0 as you can see in the picture below.

To fix this issue you need to edit your .csproj file and redirect it to the Silverlight 4 directory. The line that is related to this issue is the following:

<Import Project=“$(MSBuildExtensionsPath32)\Microsoft\Silverlight\$(SilverlightVersion)
\Microsoft.Silverlight.CSharp.targets” />

Here you have two options:

1. Replace “$(SilverlightVersion)” for “v4.0″.
2. Modify any existing declarations of “SilverlightVersion“ in your file and update them to 4.0. Take into account that some of them might be using the “FrameworkVersion”. The code below shows this situation:

   <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
   <SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>

Prism Migrated Download

If you want to save some time, you can download the CAL, Quickstarts and RI from here. The code is provided “AS IS” with no warranties and confers no rights and is shipped under the “works on our machine” license.

Have fun coding in Silverlight 4!!!

On a previous post in this series I talked about a possible approach to take when starting to learn Prism as a whole (the Tip numbering is resumed from the previous post). In this post I will get more specific and talk about one of the most used (if not the most used) pattern when developing Prism applications (either for WPF & Silverlight): MVVM.

Most people are familiar with this pattern (if you are not great places to read about it are here for WPF and over here for Silverlight), so I will not go deep into what is the main idea of it. Instead I will try to go over some core concepts that usually lead to different levels of confusion.

What’s the difference between MVVM and PresentationModel?

The above question is one asked a lot, as people tend to get confused when they hear all the talk about MVVM and then open some Prism Quickstarts or RI and find most of them “implement the PresentationModel pattern”.

Well, there is not a certain answer (and if there was I probably wouldn’t be the one who came up with it), but as far as Prism development is concerned they are synonyms. There is no difference between them, except for the coined term. As Martin Fowler explains in his PresentationModel article: “The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window, but without any of the controls used to render that UI on the screen. A view then simply projects the state of the presentation model onto the glass.”, so if you think about it, the way to “project the state of the PresentationModel (or ViewModel) onto the glass is WPF/Silverlight DataBinding in our case (or as Julian likes to explain it: “the ViewModel is a bindable Presenter”).

Always remember the main objective, testability and decoupling.

How do I do pure MVVM?

This is another point of confusion as people tend to relate MVVM with DataTemplates and no View code behind, so they get the idea that the only way to implement the pattern is that one.

In my opinion there is no pure MVVM, it is a design pattern, so it can have many different implementations which will depend mainly on who implements it and what his requirements are. In this particular topic I would like to “branch you” to Glenn’s post “The spirit of MVVM (ViewModel), it’s not a code counting exercise.” as I agree with his point of view in this topic, so there is no point in duplicating the information.

Now that you have finished reading Glenn’s post, I hope you understand what I am trying to explain (not necessarily agree). I for once like the “View First” (you “talk” to the view) implementation to relate the View to its ViewModel in Prism could be the following (using DI):

public class MyView
{
public MyView(IMyViewModel viewModel)
{
this.DataContext = viewModel;
InitializeComponent();
}
}

In the code above, Unity’s DI provides the decoupling between the View and the ViewModel, so the ViewModel “does not have to know anything about the view” and allows you to test the VM in isolation (of course this is just one of the ways to do it).

How should I manage my View/ViewModel?

This question addresses both creation/destruction of View and ViewModels as well as its interaction with other components in the application. Often it is not “clear” which component should handle a specific action.

Say that when a button is clicked an event should be published. Where should this be done? Well, without information about the application and its patterns it is hard to say. It could be done in the ViewModel or it could be done in a module level controller that manages interaction with other modules, but this depends on how your application is structured.

Instead of expanding on this topic, I would like to branch you (yet again), to these posts from Ward Bell which talk about these common questions and provide some really interesting and thought answers:

• Birth and Death of M-V-VM Triads
• Screen Factory

Should I always use commands to communicate with the ViewModel?

Before using a command, I usually stop and think: “Can this be done in another way?, Can I achieve this same functionality with binding?”. Well, sometimes the answer is yes, and that is when I think commands are not necessary. The most common example is binding a command to execute every time and item in a Listbox is selected. This same behavior can be achieved by binding the SelectedItem property of the Listbox to your ViewModel (most of the times), and executing the required action on the setter.

Having thought of the above, what if I do need a command? Well, my first recommendation would be understanding how do Commands with attached Behaviors work, a topic explained by Julian in this great post. After that you can use the code snippet I created some time ago to help you with the tedious task of creating the classes required for this to work.

Things to add to your reading list

To help you comply with Tip 4, you can find below a couple of articles about MVVM and MVVM with Prism that I think might be of use to better understand this topic (the ones mentioned above would be in this list, but there is not need in duplicating them):

• Erwin’s MVVM series (with some more posts to go)
• David’s Visual Studio templates

Hopefully, this post has helped you understand a little more about MVVM and how to use it with Prism. As always, your feedback is appreciated, so if you believe any link should be added or anything of the sort, just drop a comment.

As most of you might know, Visual Studio 2010 Beta 2 was released some days ago. Ever since, many people have asked at the Prism codeplex forums if Prism works with this latest version. That’s why with Fer we decided to migrate Prism latest release for Silverlight 3 to VS 2010 Beta 2. Our conclusion after our smoke tests is that it does work .

Migration Steps

1. Migrated every solution.
2. Ran the tests and smoke tested each application.
3. Fixed any issues that appeared (mostly related to missing assembly references).
4. As a little extra, we added the White assembly references required to run the acceptance tests.

Changes Required

Below you can find a small explanation of the changes required for the migration:

1. The Reference Implementation Tests fail (4 tests) when you run them. The fix is explained in this thread.
2. Many projects will throw a missing assembly reference exception related to “System.Xaml.dll”. You need to add this assembly as a reference in most test projects.
3. The Multitargeting Quickstart throws an error when running it. To fix it, change the Resources constructor modifier from internal to public.
4. Some build errors might be thrown because of code analysis issues in Silverlight projects (CA:0055 Analysis of Silverlight assemblies is not supported):
   • Uncheck the “Enable Code Analysis on build” check box in the Code Analysis tab.
   • Make sure code analysis is not one of the compilation symbols in the Build tab.

Download

The code provides all the fixes performed, and is provided “AS IS” with no warranties and confers no rights. It is shipped under the “works on my machine” license. You can download it from here.

I hope this saves you the trouble of migrating Prism to VS 2010.

The patterns & practices team has just released Prism-v2.1, an updated version of the Composite Application Guidance for WPF & Silverlight, which has some breaking changes, mostly related to Silverlight 3 (from the “New in this release” article):

• All Visual Studio projects (Composite Application Library, reference implementation, and Quickstarts) were migrated to use Silverlight 3.
• TabRegionControlAdapter was modified to support binding in the TabItem’s control header in Silverlight 3.
• CreateXap.bat file was modified to search for Silverlight 3 assemblies if the Silverlight 2 reference assemblies cannot be found.
• Implemented the WeakEvent Pattern for the DelegateCommand’s and CompositeComand’s (more on this below).

If you were using Prism 2.0, either for WPF or Silverlight development, I would recommend you to start using this new version, as there is also an implementation “of the WeakEvent Pattern for the DelegateCommand’s and CompositeComand’s CanExecuteChanged event to fix a possible memory leak in the applications using the Composite Application Library commands”.

You can download the latest version of the guidance from here.

Kudos to the Prism team!!!