Erwin van der Valk's blog: Practicing patterns : patterns & practices

Announcing the guide for claims based identity and access control

erwinvandervalk — Sat, 03 Oct 2009 01:37:18 GMT

Today, we’ve put the first beta drop of the book ‘Guide for Claims based identity and access control’ online. You can find the beta of the guide at Codeplex. Over the next couple of weeks, we’ll keep placing new releases online, so keep looking.

So what are these ‘Claims’ and why create a whole guide about them? Simple, it will help you overcome the current password hell

Password Hell

It’s true.. almost website you go to wants to know who visits their site.

This is not just a problem for regular internet users, but it’s a massive problem for organizations. A typical organization will have a lot of applications, both internal for it’s own employees and external for customers. Now of course, there are authentication solutions for each scenario: Windows integrated authentication, Forms based authentication, smart cards, and many more solutions. Each with it’s particular advantages and disadvantages.

With each solution, you get an island of identities. An active directory here, a database with users there. Then a couple more when the organization merges or starts to cooperate with other organizations. And each user store has to be managed when new users are introduced, roles change or when people leave the organization. With typically many identity stores in an organization, this can easily become a management nightmare.

Claims based identity and access control

The goal of claims based identity and access control is, to abstract the authentication logic from applications and and let somebody we trust handle that. We do it all the time.

A passport is a typical ‘real world’ example of a claim.

Passports without claims

For some countries, you need a visa to enter. That means going to the embassy and request a visa to enter that country. If you can provide sufficient reason to want to enter that country, you’ll receive your visa within several weeks. If you loose your visa, you can replace it. It will just take you several weeks again.

Sound familiar? That’s how a typical website works nowadays. You can sign up and get a password. Sometimes you can get a password automatically, but sometimes it has to be created manually. And if you loose it, you’ll have to request a new one.

Passport as a claim

Fortunately, to most countries, you can travel without a visa. That’s because those countries trust each other to a certain degree. If you come with a certified valid document (your passport), and the country you are trying to enter trusts your country, then they will typically let you in. And since the passports are protected with all kinds of forgery protection tricks, it’s very hard to create a fake passport.

This looks like claims bases authentication. A trusted party can issue claims (a passport) and your application can decide if you trust claims from that trusted party or not. Because the claims are digitally signed, it’s nearly impossible to tamper with them. One example of this is single sign-on, such as with OpenID or a Live-ID.

Claims based authentication

Claims based authentication is not new. It’s been around for many years. But with the introduction of open standards and Microsoft technologies like Geneva it becomes a lot easier to implement.

Goal of the guide

Authentication touches a lot of people within your organization. Architects, developers, IT-pros, security experts. Each contribute a piece to the whole authentication story. The goal of the guide is, to make claims based authentication and access control understandable for everybody.

So how are we doing that? A clear, scenario based approach with lot’s of samples.

Yes, now YOU can also take advantage of claims based authentication

As always, we’re open to feedback. Let us know what you think and make a difference!

writing applications that target both wpf and silverlight with a single codebase

erwinvandervalk — Thu, 03 Sep 2009 23:09:50 GMT

A while back, I wrote an MSDN article on writing multi-targeted programs with Prism.

http://msdn.microsoft.com/en-us/magazine/ee321573.aspx

Hope you like it!

Sharepoint guidance v2 – drop 9

erwinvandervalk — Wed, 13 May 2009 19:16:53 GMT

This week, we published the results of interation 9 to our codeplex site.

You can get it here:

http://spg.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27299

In this drop, we have addressed a number of tasks:

Implemented trusted facade pattern and removed the fake SSO provider
Refactored the repositories to make better use of WCF Proxies
Support for UpdatePanel in SafeScriptManager
Updated PartnerLandingPage
Removed most usages of .net 3.5
Provided instructions on how to use a host name to access extranet site

Trusted facade pattern

We are demonstrating in our RI how to call back-end services from SharePoint. It’s quite common to have different credentials to log on to back end services.

Replacing the fake SSO provider

Before, we were using a fake SSO provider (Single Sign On) for that. We built a fake SSO provider because it’s actually quite hard and complex to build a real SSO provider. Since the SSO provider should store passwords in a secure way, there are a whole range of attacks you need to watch for. We felt we didn’t want to take on that extra complexity in our project, so we built a fake SSO provider that stored the passwords in clear text. We hoped that calling it ‘fake’ would make it clear enough that this is not something you would want to do in production.

We a lot of feedback that giving an example that shows how to store passwords in clear text is bad. No matter how clearly you explain that it’s not something you want to do in production, somebody is going to do it anyway. But since didn’t want to show you how to build a real SSO provider (that would be a project in itself), we decided to change our implementation to a trusted facade.

Trusted facade explained

The following diagram shows the trusted facade pattern:

A user authenticates with the trusted facade. It validates the credentials provided by the user. Then, if the trusted facade calls the back end service on behalf of the user, it only specifies the username. The back end service trusts the Trusted Facade to provide the correct username, so it doesn’t need to perform any authentication.

We implemented our trusted facade based on this MSDN article. Our implementation looks like this:

A user connects to SharePoint either through windows authentication or through Forms Based Authentication (FBA). Then, when the user wants to make a request to a backend system, for example to retrieve the price for a product, the pricing repository will find out what partner the user belongs to. It will then call the back end service with the name of the partner. The pricing service trusts our SharePoint application to provide the correct partner name, so it doesn’t require any passwords.

Of course, you have to make sure that only the account that SharePoint runs under is allowed to access the pricing service.

Repository refactoring

We took a critical look at our current implementation of the repositories.

The goal of the repositories is to hide data access logic from consumers. For example, we have a ProductCatalogRepository, which has methods like: GetProduct(string sku) to retrieve product information. This repository uses the BDC for some of it’s methods, but for other, it calls into our productcatalog webservices directly. However, the consumers of these repositories don’t know where the data comes from. They also don’t know (and don’t care) that the data is cached.

Webservice proxies

Adding a reference to a webservice is very simple in Visual Studio. What happens under the covers is quite a bit more complex. Visual studio will generate proxy classes based on the metadata that’s returned from the service.

We implemented the following best practices for calling web services:

If your service references are used by multiple projects, create a single project that holds the service references and reference that project.
There are to reasons for this. If you are making changes to your webservice, you only have to update one service reference. Forgetting to update one can cause annoying bugs. But from a design perspective, if you generate two proxies for the same web service, then you’ll have duplicate (incompatible) types in your system. For example, the price object generated for proxy 1 will be different from the price object generated for proxy 2. Even though they have exactly the same signature, you can’t reuse the types for them or reuse methods that work on them. We implemented this in the Contoso.Pss.Services.Client solution.
Don’t call the service proxies directly, but wrap the calls to the service proxies into repositories or service agents.
This best practice is used to shield your application from (minor) changes to the service. It does take some extra coding, because you have to transform the objects you get back from the service into objects that can be used by your application. So this practice does adds a level of indirection and extra complexity to your application, so you have to make the tradeoff if the extra complexity is worth the isolation. In general, if the services are created for and only used by your application, you typically don’t need such a level of indirection. However, if you don’t have control over your services or other clients are also using the services, it’s often worth it.

There were a couple of area’s we explicitly didn’t look at.

Getting the repositories from the service locator

Before, we were creating the repositories directly in our code, for example in our presenters. This is often undesirable, because it makes the presenters harder to unit test. Now, we have registered the repositories in our service locator. Therefore, we can use the service locator to get instances of our repositories and we are able to mock out these in our unit tests. Sweet :)

UpdatePanel in sharepoint

SharePoint has a slightly different method for implementing post backs than the normal ASP.Net framework. It uses a custom javascript method that is called on postback. Unfortunately, this means that the Ajax UpdatePanel doesn’t work out of the box, because it also requires a different postback method. The solution is to emit some JavaScript code that intercepts the postback event and calls the normal UpdatePanel posback code.

In order to get the UpdatePanel to work, you need a scriptmanager, because that will add the required javascript code for the async postback to the page. We had already built a SafeScriptManager, that you can add several times to a page without causing issues. So it was natural to add some functionality to it to enable support for the UpdatePanel.

Removed most .net 3.5 usages

We were making judicious use of the wonderful new features of .Net 3.5 such as Linq queries, lambda expressions and type initializers. However, we got the feedback from our advisors that .net 3.5 is not widely used by the sharepoint developer community. After many discussions, we agreed that removing most of the .net 3.5 usages would make our guidance a bit more consumable by the sharepoint developer community.

Added instructions on how to use a host name to access extranet site

Lastly, we added some instructions on how to use a host name to access extranet sites. Now, our extranet site is accessable on localhost:9001. If you would prefer to host the extranet site on a hostname, for example extranet.mydomain.com, we have included instructions on how to do that.

sharepoint guidance drop 8 video online

erwinvandervalk — Thu, 30 Apr 2009 20:08:29 GMT

Hi guys,

Our drop 8 video is online on Channel 9. Check it out:

Happy watching and keep practicing!

_Erwin

what do you think of prism?

erwinvandervalk — Wed, 01 Apr 2009 20:40:01 GMT

Prism has been out for quite a while now. I hope you had some time to play with it, read the docs, look at the code and build apps with it. So, what do YOU think of prism? Did you like it? Did it help solve your composite application problems? Was it easy to use or very hard? Please let us know by filling out this survey:

http://www.zoomerang.com/Survey/survey-intro.zgi?p=WEB228YSYYRK4A

Of course, you don’t have to.. but this is your chance. If you really liked prism, then tell us. That way, we know we have to invest more in future versions of Prism ;)

p&p Sharepoint guidance v2

erwinvandervalk — Fri, 20 Mar 2009 06:30:20 GMT

Since the Prism project is done, I’ll be working on a different project for the next couple of months.

Sharepoint guidance on Codeplex

The goal of this project is to provide guidance on how to build Sharepoint applications in a professional way.

Version 1 of Sharepoint Guidance

V1 of the Sharepoint guidance project focused mainly around the following aspects:

How to work with development, testing and production environments.
How to build sharepoint solutions in a Test Driven fashion.
How to set up a Continious Integration environment, that does our Builds, and runs our Unit and Acceptance Tests
How to build Sharepoint applications that can be versioned.

To do this, we’ve built a reference implementation that demonstrates all of these concepts.

Version 2 of Sharepoint Guidance

We are now well on our way with the Sharepoint Guidance and are already in iteration 6 (we have two week interations).

In V2, we have the following goals:

How to design and build content driven applications
- How to develop an application that allows a mixture of development activities and authoring.
- How to create composite
How to extend existing LOB systems:
- How to integrate LOB systems in a secure way using Single Sign-On (SSO)
- How to manage connectivity with LOB systems and databases by using the Business Data Catalog (BDC) and call Windows Communication Foundation (WCF) from Sharepoint.

Sharepoint Guidance V2 – Drop 5

Last Friday, we’ve released drop 5 to codeplex. You can download it from here:

http://spg.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24674

The most important things we have addressed in this drop are:

How to implement global navigation, across different site collections.
How to implement custom navigation.
How to add Silverlight controls to your site.

Francis cheung and I have created a webcast that guides you trough some of the things we did in drop 5:

Global navigation

In our reference implementation, we’re demonstrating how to create consistent navigation across different sites and site collections. It’s very simple to create a sitemap for a single site, by creating a sitemap.xml and using the asp.net sitemap control to create the sitemap and add it to your site. However, creating a sitemap that’s shared between all sites is a bit harder.

The structure of our reference implementation is as follows:

We have a sitecollection for our intranet site, a sitecollection for our extranet site and a sitecollection for partner specific sites. Partners who log on to their homepage, will likely navigate between pages on their site and pages on the extranet home, for example to view products or promotions.

We want the global navigation structure to look somewhat like this:

The partner should be able to seamlessly navigate between each part of our Sharepoint site. Of course, we only want to have the structure of our site stored and versioned in one place. So to create a consistent story across multiple pages, we have taken the following steps:

Created a Sharepoint deployment project to create a feature that will apply a masterpage (with the website’s branding). This masterpage also contains a sitemap control that points to the SPXmlContentMapProvider:
```
<asp:SiteMapDataSource ShowStartingNode="false" 
    StartingNodeUrl="/pssportalroot" SiteMapProvider="SPXmlContentMapProvider" 
    ID="contosoPssSiteMap" runat="server" />
```

Create a Sitemap xml file that will be placed 12 hyve. To do that, you have to put it in the folder Templates\Layouts folder.

The sitemap xml looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap>
  <siteMapNode title="" url="/pssportalroot">
    <siteMapNode title="Partner Home" url="/_layouts/contoso/partnerredirect.aspx?page=Home">
      <siteMapNode title="Manage Incidents" url="/_layouts/contoso/partnerredirect.aspx?page=incidents" />
    </siteMapNode>
    <siteMapNode title="Product Catalog" url="/sites/pssportal/productcatalog/category.aspx?categoryid=0"/>
    <siteMapNode title="Promotions" url="/sites/pssportal/promotions" />
    <siteMapNode title="Search" url="/sites/pssportal/search" />
  </siteMapNode>
</siteMap>

Create a featurereceiver to merge the sitemap xml fragment into sharepoints global sitemap. To do that, call the following method in the FeatureActivated method of the FeatureReceiver:
```
web.Site.WebApplication.Farm.Services.GetValue<SPWebService>()
    .ApplyApplicationContentToLocalServer();
```

Custom sitemapprovider

We are also demonstrating how fill a sitemappath control with custom data and we are using the business data catalog for that.

In our scenario, the business data catalog provides a list of categories and products (which it gets from WCF webservices in a different system). It then uses this data to create category and product pages to display the individual catalogs and products.

We’ve created a custom sitemap provider that will retrieve the categories and url’s to the category pages from the BDC. We then tie a normal asp.net sitemappath control to that sitemap provider to display a ‘crumb’ path that displays sitemap information.

Silverlight Controls

In our reference implementation, we are also demonstrating how to add silverlight controls to your site. To a ‘normal’ asp.net webapplication, adding silverlight controls is really easy, because the IDE takes a lot of things out of your hands. In Sharepoint, unfortunately that’s not as easy. So if you want to use the Serverside Silverlight controls (in System.Web.Silverlight, from the Silverlight SDK), you will also need to have Asp.net Ajax support in your site. This means: Adding the required entries to the web.config and adding a scriptmanager control to your page.

Web.config changes

There are basically two ways to make changes to the web.config of a sharepoint server. Programmatically, through the API or declaratively, in a XML file. Since there are quite a few changes you have to make to your web.config, we figured the declarative approach works best. Again, you have to call ApplyApplicationContentToLocalServer() to merge the declarative changes into the web.config. I’ll write a later blogpost or do a webcast on how to do this in more detail. But if you are interested, you can always look at our drop.

SafeScriptManager

The scriptmanager proved to be an issue. You can only have 1 scriptmanager on your page and it must appear before any controls that need it. Normally, you would add a scriptmanager to your masterpage and be done with it. However, sharepoint is quite dynamic with it’s masterpages. You can easily create a new masterpage and use it as the default masterpage for some group of pages. So this means that if you use ajax in some of your webparts, you can no longer use those webparts on pages that don’t have a scriptmanager.

So we’ve created a control called the SafeScriptManager. You can safely add it to any controls or webpart that needs a scriptmanager. It will check if a scriptmanager is already present.

Conclusion

I hope this clarifies a bit what we have done in this drop. I plan on doing a blog post and a webcast for each drop from now on. As always, any feedback (on the post, on the drop or on the weather) are welcome :)

Happy coding!

Test if classes are registered in unity

erwinvandervalk — Sat, 14 Feb 2009 01:45:37 GMT

While writing some sample applications for the upcoming release of Prism (Composite Application Guidance for WPF and Silverlight) I ran into a small challenge.

“How do you verify (with unit tests) that the right classes are registered in your DI-container?”

In my case, the container is Unity, but Unity does not have any ‘IsTypeRegistered’ methods (Apparently there are good reasons for it not to have these methods). So that posses an interesting challenge. At first I thought of 2 solutions:

Manually create a mock of your container.
Certainly possible but a lot of work for my small demo app. A mocking framework can help with this, but i don’t want to rely on a mocking framework for a small demo app.
See if the components are registered by resolving the type.
This will work initially, but it will actually instantiate the object. So if the object can’t be created for some reason, your test will fail. Now if the type you have just registered has a lot of dependencies, you will need to satisfy all those dependencies in the container before you can even begin to create the object.

But neither of these options were really satisfying. Then I asked Chris Tavarez, and he mentioned: Why don’t you build a Unity Extension. So I did and that solved the problem quite nicely:

So this is the Extension I’ve created:

        1: public class QueryableContainerExtension : UnityContainerExtension

       2: {

       3:     public List<RegisterEventArgs> Registrations = new List<RegisterEventArgs>();

       4:  

       5:     protected override void Initialize()

       6:     {

       7:         this.Context.Registering += new EventHandler<RegisterEventArgs>(Context_Registering);

       8:     }

       9:  

      10:     void Context_Registering(object sender, RegisterEventArgs e)

      11:     {

      12:         this.Registrations.Add(e);

      13:     }

      14:  

      15:     public bool IsTypeRegistered<TFrom, TTo>()

      16:     {

      17:         return this.Registrations.FirstOrDefault((e) => e.TypeFrom == typeof(TFrom) && e.TypeTo == typeof(TTo)) != null;

      18:     }

      19:  

      20:     public bool IsTypeRegisteredAsSingleton<TFrom, TTo>()

      21:     {

      22:         return this.Registrations.FirstOrDefault(

      23:             (e) => e.TypeFrom == typeof(TFrom)

      24:                 && e.TypeTo == typeof(TTo)

      25:                 && typeof(ContainerControlledLifetimeManager).IsInstanceOfType(e.LifetimeManager)) != null;

      26:     }

      27: }

And this is how you’d use it:

       1: [TestMethod]

       2: public void TestRegistration()

       3: {

       4:     // Create the container and add the extension method

       5:     var container = new UnityContainer();

       6:     var registeredTypes = new QueryableContainerExtension();

       7:     container.AddExtension(registeredTypes);

       8:  

       9:     // Register the classes to the container

      10:     container.Register<IMyInterface, MyClass>();

      11:  

      12:     // See if the type is registered

      13:     Assert.IsTrue(registeredTypes.IsTypeRegistered<IMyInterface, MyClass>());

      14: }

Hope you find this as useful as I did :)

prism v2 – drop 10 (composite application guidance)

erwinvandervalk — Sat, 31 Jan 2009 02:41:41 GMT

Today, we have released what’s likely going to be the last drop of Prism before the final release. You can get the release from:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=22566

During this iteration, we have mostly worked on documentation, implementing a new UI for the Stock Trader Reference Implementation and fixing some last important bugs.

The most important changes are:

Removed .Silverlight and .Desktop extensions from the Assembly names, both in the Library and in all the Quickstarts.

Renamed RegionExtensions class to RegionContext and RegionExtensions.GetRegionContext() method to RegionContext.GetObservableContext()

Moved RegionExtensions.GetObservableRegion() method from RegionExtensions class to RegionManager class.

Integrated new UI design for Stock Trader Reference Implementation.

Many updates to Documentation

Included API CHM file

Added shortcut .Bat files to make it easier to open the solutions.

Bug fixes

Added missing XML comments to the code of the Composite Application Library.

New UI for Stock Trader Reference Implementation

We felt that the original UI of the Stocktrader RI didn’t give a good impression of the capabilities of WPF and Silverlight. Most of the things we were showing before were also possible with Windows Forms. So for this release, we’ve decided to hire a graphical design company to give our RI a complete makeover, complete with some cool animations.

Before:

After:

Looks a lot better huh?

prism v2 – drop 9 (composite application guidance for wpf and silverlight)

erwinvandervalk — Mon, 19 Jan 2009 22:32:29 GMT

It’s been a while since my last post. Not that the Prism team has been sitting idle though.

Last Friday, we’ve released drop 9 of Prism. As we are approaching the end of the Prism v2 project, there are a lot less API changes, as we are mostly focussing on finishing the docs and resolving bugs. We have also spent some time trying to build different application styles (for example, an outlook style app, or a master-detail style app) on top of our library. The results of this exercise was very useful. Unfortunately, they were nothing more than spikes, so we can’t deliver them as part Prism, but we are thinking of doing a bunch of blog posts or webcasts, that describe how to build different application styles on top of Prism.

You can get drop 9 of Prism here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=21912

What’s in Prism drop 9

New skin for the Stocktrader reference implementation.
We wanted to show a bit more of the power of the WPF and Silverlight platform in our RI, so we have hired an external design bureau to create a new design. It has taken a bit longer to implement than we had hoped. In this drop, we have some of the basic styling in place. Hopefully, we can get the next styling
Desktop only solutions
Not everybody is interested in developing on both WPF and Silverlight. So that’s why we’ve added ‘WPF’ only solutions. We can’t really add Silverlight only solutions as easily, because the Silverlight projects are linking all the files from the WPF projects.
New SingleActiveWindowRegionAdapter in the RI
We are demonstrating how to create an adapter in the RI, in this case how to create a popup window and use that as a region.
Several bugs fixed
Lots of testing, prioritizing, bugfixing, retesting, etc..
Exception stack compression in combination with Unity
Unity is an awesome DI container, but it doesn’t give really clear exception messages if something goes wrong.

The last weeks of a project are always interesting. There are _so_ many ‘little’ things we would have wanted do do, or add to the library. but what seems like a small dev effort, can quickly add up if you also count the test and doc effort. So, we are constantly keeping a critical eye on our prioritized backlog of tasks. Unfortunately, this means there are a bunch of really interesting stuff we would have loved to tackle, but we can’t.

Exception stack compression

While building different application styles on top of Prism, we found an interesting problem.

Suppose the following example: You are creating a simple view. In the Module.Initialize(), you are registering the type of the view against a region that’s displayed in the shell. In the constructor of the view, you have made a small programming error, which causes an exception.

So what’s the result?

A module initialize error. Ok, that makes sense. But what was the exception message inside that? “Exception occurred at target of invocation.”. And inside that? A bunch of ServiceLocator, Unity and Objectbuilder errors. Only somewhere at the bottom of the inner exception list you find the exception that caused the problem.

All these exceptions are perfectly valid from a technical point of view, but not very useful in understanding what’s going wrong. Ideally, Unity should return a very clear exception message: “Tried to create object X, but could not because of this error message: ‘xyz’”. Unfortunately, Unity does not do this. (After a discussion with the enterprise library team, it turns out that it’s really hard to build this in Unity). I think that developers who are building applications on top of Prism are rarely interested how exactly the DI container builds up it’s objects. So all the technical inner exceptions are just clutter to them, that’s obscuring what’s really going wrong.

So we have built some logic to try and find the error in the stack trace that actually points developers in the right direction. The goal was to be able to get the following exception message: “An exception occurred while initializing module X, in the constructor of View X, with exception message “XYZ”.

So now in Prism, you can use the extension method exception.GetRootException() to try and find the exception that’s actually causing the problem. It won’t be 100% accurate, but it looks like it really helps in getting to the root of the problem more quickly.

Hopefully you will find this useful to!

PRISM v2 – dROP 6 (Composite Application Guidance for WPF and Silverlight

erwinvandervalk — Sat, 22 Nov 2008 04:48:53 GMT

Today, we have released the 6th drop of Prism V2 (affectionately known as Compostite Application Guidance for WPF and Silverlight)

You can download it from:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=19731

What’s new?

We’ve had a busy iteration, where we mainly focused on improving some of the design around regions, bugfixes and some code cleanup. This is the list of new items:

    • RegionContext usable in XAML.
    • Introduced a façade on IRegionManager for adding views to regions (push based) and registering view types (pull based)
    • Expanded the usage of pull based composition in Top Down Composition quickstart
    • Silverlight RI is now using the Silverlight Toolkit Controls for line and pie charts
    • Regions and RegionContext using an expanded behavior mechanisms
    • Have established package load key for project linker
        • known issue: this still requires the SDK to be installed, however.
    • Changed to Add Project Link... dialog
    • Resolved a number of code-analysis rules
    • Stock Trader RI is now using pull-view (or top-down) composition for trend line graph
    • ProjectLinker installer does not have to be started with elevated permissions on Vista

So like always, please check it out and tell us what you think.

There are a couple of topics I’d like to go into a bit deeper:

Façade on IRegionManager

We’ve introduced a façade on the IRegionManager to make it a bit easier to work with Regions, either from a push or pull based perspective. You can use the following calls:

        1: public class MyModule : IModule

       2:  

       3:     public void Initialize()

       4:     {

       5:     

       6:         // Push based composition

       7:         // This code will find "Region1" (it must already be created) and add a new 

       8:         // instance of MyView to it. 

       9:         this.regionManager.AddViewToRegion("Region1", new MyView());

    

        // Pull based composition

        // This code will register a viewtype with a region. Whenever Region2 is 

        // displayed, it will automatically be populated by a new instance of MyView()

        // created by the ServiceLocator. 

        this.regionManager.RegisterTypeWithRegion("Region2", typeof(MyView());

    

        // Variation on pull based composition:

        // This code uses a delegate that creates the view to be pulled. This is great

        // if your presenters are responsible for creating the views. 

        this.regionManager.RegisterTypeWithRegion("Region2", 

               () => new MyViewPresenter().View());

        

    }   

  

    private IRegionManager regionManager;

    

    public MyModule(IRegionManager regionManager)

    {

        this.regionManager = regionManager;

    }

  

}

In the previous drop, we have introduced the IRegionViewRegistry, where you could register views to be pulled (Previously called RegionContentRegistry). This allows you to plug in your own registration module. However, we figured that for simple scenario’s, you don’t need to know about this implementation detail.

RegionContext

An other thing we’ve improved is the RegionContext. Like I mentioned in my previous blogpost, the RegionContext is a way that a view that hosts a region can share some of it’s information with any childviews that are loaded into it’s region. The RegionContext now supports 2 way databinding and is very configurable using RegionBehaviors.

The following codesnippet shows how to use the RegionContext in XAML:

<ContentControl x:Name="SelectionPanel"
                cal:RegionManager.RegionName="{x:Static local:RegionNames.SelectionRegion}"
                cal:RegionManager.RegionContext="{Binding Path=SelectedEmployee, Mode=TwoWay}"
                />

And in the views, you can get access to the regioncontext like this:

// To get the value from the regioncontext, from inside the view in a region:
var regionContextValue = RegionExtensions.GetRegionContext(this).Value

// To change the RegionContext:
RegionExtensions.GetRegionContext(this).Value = newValue

// And to subscribe to change events:
RegionExtensions.GetRegionContext(this).PropertyChanged += RegionContext_PropertyChanged

RegionBehaviors

We’ve received a number of questions from people who liked the functionality where a region would automatically pull in instances of all registered viewtypes. However, they really wanted the ability to influence which views were pulled in. This was one of the reasons why we moved to implement a list of behaviors on a region.

We had the following requirements:

You have to be able to define regions in XAML and Code
You should be able to bind the RegionContext in XAML or set it through code.
The RegionContext should be available for views inside a region. But a view can either be an UserControl (thus a dependencyobject) or a ViewModel (poco)
A region should be able to pull in registered views (but in a way you can influence it)

This lead us to the conclusion a region has a couple of behaviors. We will provide a number of behaviors by default, which you can change globally, or for a specific Region instance.

Default behaviors

We have built a number of behaviors:

For synchronizing the RegionContext, we’ve built two behaviors: SyncRegionContextBehavior, which will synchronize the regioncontext dependency property, defined in XAML with the Context property on the region. To synchronize the Regions Context property with childviews (we only support usercontrols now) we have the BindRegionContextToDependencyObjectBehavior.
For the TopDown (pull based) composition, we’ve created the AutoPopulateBehavior. This will query the RegionViewRegistry for all viewtypes defined on the view and autopopulate it.
To register the region with the regionmanager, we’ve created the RegionManagerRegistrationBehavior.
Some views are aware of the fact that they are ‘active’ or not, by implementing the IActiveAware. The active property is set on them by the RegionActiveAwareBehavior.

This diagram shows the behaviors we have built now:

Customizing the behaviors for all regions

The default behaviortypes are registered in the UnityBootstrapper. By overriding the ConfigureDefaultRegionBehaviors method you can add new behaviortypes, replace existing types or remove behaviors. You can also choose to register a different IRegionBehaviorFactory, if you require custom initialization for your behaviors.

The default behaviors are added by the RegionAdapterBase. In the RegionAdapter you can decide to add behaviors for specific control types. For example, we had to build a behavior to get the TabControl in silverlight to work properly. (It doesn’t derive from selector like in WPF).

Customizing the behaviors for a single region instance

Sometimes, you want to add a behavior to a specific instance of a region. For example, when you want to change the way views are pulled into a region. To do this, you have to detect that the region has been created, but before the default region behaviors are attached. You can do that by hooking up an eventhandler in the constructor of the view that’s hosting a region.

       1: // From the TopDownUIComposition Quickstart

       2: public EmployeesView()

       3: {

       4:     InitializeComponent();

       5:  

       6:     RegionExtensions.GetObservableRegion(this.SelectionPanel).PropertyChanged += delegate(object sender, PropertyChangedEventArgs args)

       7:     {

       8:         if (args.PropertyName == "Value")

       9:         {

      10:             // The region has just been created, but (Very Important), the default behaviors have not been added yet. 

      11:             // This gives you a chance to add your own custom behaviors. If you use the same key as a default behavior

      12:             // it will replace a default behavior. 

      13:             IRegion region = RegionExtensions.GetObservableRegion(this.SelectionPanel).Value;

      14:             region.Behaviors.Add(AutoPopulateRegionBehavior.BehaviorKey, new CustomAutoPopulateBehavior());

      15:         }

      16:     };

The ‘GetObservableRegion’ method will return an object that you can monitor to when the region is created. The .Value property will hold the new region.

Prism V2 – Drop 4

erwinvandervalk — Sat, 25 Oct 2008 01:54:53 GMT

Today, We have put an other drop of Prism V2 (Composite application guidance for WPF and Silverlight) online. You can download it from here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=18750

New in Prism V2 - Drop 4

This sprint was mainly focused around UI Composition. We have ported the Region functionality from Prism V1 over so it also works in Silverlight. Then we also addressed a different style of visual composition, we’re calling Top Down composition. I’m going to drill into those composition styles later in this post.

Top down vs. Bottom up composition

In the last couple of weeks, we’ve had a lot of discussions around Visual Composition patterns.

Bottom up composition

Prism V1 used a regions to support Bottom Up composition. As a developer, you can define and name regions on your screen. When developing modules, you can use the names of these regions to push views into the regions. At first, we called this “push” based composition, because modules push their views into named regions. The diagram below shows an example of push based composition. We’re also calling this bottom up composition, because lower level modules push their views into the regions of higher level views.

Although this composition model allows for a highly decoupled and modular approach to UI development, we received some feedback that in some scenario’s it can be a bit to complex.

Top down composition

With top down composition we took a different approach. Usually, developers are very comfortable with the usage of UserControls. It’s quite common for developers to split up a view into several UserControls to reduce complexity (divide and conquer) and to improve reuse of visual elements. Now it’s quite easy to create controls and place them in different assemblies. However, in order to use those assemblies, the shell has to have a reference to the assemblies that hold the user controls. This goes against the principles of modular development where modules can be versioned, and deployed seperately.

We wanted to allow a model where you can visually compose your application in the same way as using UserControls, but without sacrificing modularity. To do this, we introduced a Top Down composition model:

So instead of the shell having a hard reference to the CustomerModule and putting a CustomerView directly on the ShellView, you put a ContentControl in the place where you want the user control. Then you use an attached property ViewType to specify what kind of View you want to display here, by specifying the interface of the view to display. The view interfaces can be defined in a seperate (Interface) module or in the shell.

When a module get’s initialized, it typically registers it’s views to the DI container. For example, the CustomerModule will tell the container that it can provide an implementation of the ICustomerView, because it registers the CustomerView type with the ICustomerView interface. Now after module initialization, the ShellView will ask the DI container for an implementation of ICustomerView. This will of course return the CustomerView, so it can then be shown in the ContentControl. Essentially, the ContentControl on the ShellView is pulling the CustomerView in from the CustomerModule, without having a direct reference to that module. We are calling this “Top Down” composition, because the Higher level modules define which views are displayed where.

This is an example (from the TopDownCompositionQuickstart) on how you specify a view that’s pulled into the shell in XAML:

<ContentControl 
    Regions:ContentController.ViewType=
         "TopDownComposition.Modules.Employee.IEmployeesListView, EmployeeModule.Silverlight, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />

You might notice 2 things:

The viewtype is a string
At first we wanted to use the type of the interface directly. Unfortunately, this doesn’t work in Silverlight, because you cannot create types in XAML, because {x:Type} doesn’t work. But working with strings isn’t too bad. We’re planning to make the resolving logic pluggable. This way, you could for example use logical names, exported by your modules, to identify and retrieve the views. In fact, the MEF framework also works like that.
The viewtype is a really long string
To make working with those really long strings a bit more bearable, we’re also thinking of building a custom type resolver. Since 99.9% of the times the full typename (Namespace.TypeName) is unique, you can get away with just specifying that and let the framework figure out which assembly the type came from.

We’re also considering moving the View resolving functionality from the ContentController to the RegionManager. Even though technically this has nothing to do with regions, conceptually it’s very similar. A region specifies where you want to display visual elements from other modules. In the top down approach, you specify the content via it’s interface and in the bottom up approach you give it a name so others can push views into it. But it’s still a placeholder for views.

Conclusion

Hopefully you’ve found this post useful in explaining what we’re building. As always, we are very open to feedback. If you don’t like something we do, please tell us! Also if you do like something, tell us that as well! It might just prevent us from changing something you are already happy with :)

Prism V2 (Composite Application Guidance) – Drop 3 is out

erwinvandervalk — Tue, 14 Oct 2008 23:19:54 GMT

Yesterday, we’ve put the third drop of the Prism V2 project (Composite Application Guidance for WPF and Silverlight) online.

You can download it from here:

http://www.codeplex.com/CompositeWPF/Release/ProjectReleases.aspx?ReleaseId=18184

In this blog post I’m going to answer the following questions:

What’s new in this drop?
What are the Prism V2 module loading scenario’s?
How is module loading implemented in Prism V2?
Why the change from module enumerators to module catalogs?

What’s new in this drop?

In this drop, we are starting to address Modularity. We’ve laid down the foundations for two new quickstarts: a static loading quickstart and a remote module loading quickstart. The most interesting of these two is the remote module loading quickstart because it does asynchronous downloading of modules from XAP files, and introduces a new XAML markup based way of defining modules.

Why address modularity in the third drop?

It might be interesting to address why we haven’t started to address modularity until this third drop. In the first two drops, we’ve mostly focused around multi targeting solutions between WPF and Silverlight. This might seem a bit strange, considering Prism is focused on composition. One of the goals of Prism V2 is to enable you to create applications that target WPF on the desktop and Silverlight from the browser using mostly the same codebase. we quickly found that targeting both Silverlight and WPF is not easy, so in true agile fashion, we tried to tackle this high risk unknown factor first. The added benefit is that we are dogfooding the tool we created to help multitargeting and can start capturing guidance on multi targeting applications early.

Prism V2 Module loading scenario’s

When designing the module loading strategy for Prism V2, we first had to come up with the scenario’s we wanted to address.

In a desktop application, you would typically want to create a modular application if you wanted to develop, version and deploy modules independently from each other. Of course these reasons are still valid for Silverlight applications, but we found that in Silverlight there is an other really important for creating a modular application: Minimizing download size. Especially on the web, users are very impatient. So you want users to wait for the minimum amount of time to start using your application. If you deploy your application in one massive 20 Mb Xap file, you are not going to end up with very happy customers.

So you could also use modularity to minimize download time. We defined three categories of modules for this: Core, background and On demand modules.

“Core” modules

There is going to be a group of modules that are the bare minimum for your application to run. Most of the time, this will be the shell, shared common infrastructure modules with shared services and one or more functional modules that the user absolutely needs to productively use the application. Of course, speed is essential, so you should try to keep these modules to the minimum size possible.

The core modules, will typically be packaged in the main Xap file. While this main XAP file is downloaded, you can use the built in Silverlight functionality to display a splash screen while the main XAP files are downloaded. Once the main XAP file is downloaded, the core modules will get initialized and the application will start up.

Background downloaded modules

Now there might be a couple of modules that are really important to your application, but the user doesn’t need them right away. However you don’t want them to wait for the module to get downloaded once they actually do need them. So to improve the user experience, you want to download these modules in the background. Modules will be downloaded in order and initialized when they are downloaded.

On demand downloaded modules

Then you might have a group of modules that are only used by a very select group of users (IE: an administration module). This will mostly help in minimizing the installation bandwidth used, because it’s not needlessly downloading assemblies.

Module loading in Prism V2

In Prism V1, there was no concept of module downloading, because all modules where assumed to be available on the file system. Now for silverlight, this approach only works for assemblies that are present in the main XAP file. In Prism V2, we want to support retrieving modules from elsewhere. We’ll support downloading XAP files for Silverlight, but nothing prevents you from downloading modules from the web or from a database in WPF.

This image displays roughly how the module loading pieces relate to each other:

The bootstrapper creates the Catalog and the Module manager. Then it kickstarts the modulemanager to start initializing the modules.
The Catalog holds a list of ModuleInfoGroups which is a collection of module info’s. We’ve created a grouping, to make it easier to define which containers (XAP files) hold which modules. It’s also a convenient way to create a group of modules that are ‘Core’.
The ModuleManager is responsible for coordinating the whole module retrieval and loading process. It will query the Catalog for core modules, background modules. It will also be the point where you hook up events to get notified when modules are downloaded.
The moduleManager has a list of ModuleRetrievers. We are likely to ship only one retriever: the XapModuleRetriever that downloads silverlight modules. However, this way you can plug in your own retrieval strategies (IE, load modules from a database, webservice or some other means)
If a module is present (either it was already on the filesystem, or it has been retrieved) the ModuleManager calls the ModuleLoader to instantate the module and call the Initialize method on it. This is the place where you can plug in your own module loading and initialization strategy.

Defining module information in XAML

One other new thing we are supporting is defining module information in XAML. This is different from defining module info’s from a config file, because loading the XAML actually instantiates the ModuleInfo files. This way, it’s easier to create your own ModuleInfo files and extend it with custom properties. Defining modules in XAML looks like this:

        1: <Modularity:ModuleCatalogBuilder xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

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

       3:                xmlns:Modularity="clr-namespace:Microsoft.Practices.Composite.Modularity;assembly=Microsoft.Practices.Composite.Silverlight">

       4:     <Modularity:ModuleInfoGroup Ref="ModuleY.Silverlight.xap" InitializationMode="WhenAvailable">

       5:         <Modularity:ModuleInfo ModuleName="ModuleY" ModuleType="ModuleY.ModuleY, ModuleY.Silverlight, Version=1.0.0.0" />

       6:     </Modularity:ModuleInfoGroup>

       7:     <Modularity:ModuleInfoGroup Ref="ModuleZ.Silverlight.xap" InitializationMode="WhenAvailable">

       8:         <Modularity:ModuleInfo ModuleName="ModuleZ" ModuleType="ModuleZ.ModuleZ, ModuleZ.Silverlight, Version=1.0.0.0" />

       9:     </Modularity:ModuleInfoGroup>

      10: </Modularity:ModuleCatalogBuilder>

      11:

This example (from the RemoteModuleLoading quickstart) has two XAP files. Each XAP file has a single ModuleInfo. These modules will be downloaded on a background thread and initialized when they have been downloaded (WhenAvailable)

Moving from ModuleEnumerators to Catalogs of modules

In Prism V1, we have the concept of module enumerators that define which modules are used by the application. For instance, the DirectoryLookupModuleEnumerator would find all modules in a specific directory. After many discussions, we found that this name is a bit confusing. If you think about it, an enumerator in .Net takes a collection and provides a way to walk through that collection. The prism ModuleEnumerators acted more like Module Info providers because they read module information from a certain location (IE: a directory or a config file) and returned the list of module info’s.

In Prism V2, we have defined the concept of a Catalog (of modules). A catalog contains the list of all the modules that are available to the application. Other components, like the ModuleManager can query the catalog for specific groups of modules. Like: “Give me all the Core modules”. Or “Give me all the modules to download in the background”.

Conclusion

There is a bunch of interesting stuff going on in this drop. We are still in the middle of a bunch of changes, but it does give a clear indication of the direction we’re taking.

As always, let us know what you guys think, either by commenting here, commenting on the CodePlex site, or by sending us an E-mail.

Thanks

Composite Application Guidance for WPF has landed

erwinvandervalk — Fri, 04 Jul 2008 21:03:00 GMT

My new colleagues at patterns & practices have just delivered a great new deliverable around creating composite applications in WPF. Check it out at:

http://msdn.microsoft.com/en-us/library/cc707819.aspx or at: http://www.codeplex.com/CompositeWPF

This deliverable contains:

Composite Application Library components.
Guidance around creating composite applications, including detailled descriptions of common UI design patterns.
Reference implementation
Quickstart applications that demonstrate specific aspects of CAL
Lots of hands on labs

Great stuff!

First Post

erwinvandervalk — Thu, 26 Jun 2008 21:48:00 GMT

Hi All,

Wecome to my Blog. I've just started my new job at the patterns & practices team in Redmond. I hope to write some interesting blogposts about the stuff I'm working on. Let me know if there is anything you'd like me to blog about :)

Erwin...