Julian Dominguez Blog

As some of you might probably know because of some posts by Blaine, the patterns & practices team that brought you Prism is working on a new Web guidance.

This project is currently under development, and as with all p&p assets, we opened up our biweekly drops to the community, so we can get early feedback from you.

This all new Web guidance is not built on top of Web Client Software Factory, but can coexist with it. So if it’s not WCSF, and it is from the same group…

… what is this all about?

The anticipated benefits include (but might change in the final release, again, FEEDBACK is the magic keyword):

• Provides infrastructure for developing and maintaining ASP.NET and AJAX applications
• Provides guidance on MVC 2, jQuery, and AJAX library
• Unit testing for ASP.NET and JavaScript client applications
• Responsive applications
• Flexible architecture that allows change
• Separated presentation including unit testing view logic
• Application modules are developed, tested and deployed separately
• User Interface components are dynamically composed
• Guidance on how to improve Web client security
• Allows incremental adoption of the components

What is the current state?

This is the first public drop of the Web Client Developer Guidance. We are currently in the 5th iteration. The Reference Implementation (RI) shows several UI patterns (predictive fetch, preview, edit-in-line). Most recently, we’ve been working on implementing separated presentation patterns and composability within MVC. The RI has JavaScript unit tests using QUnit. Also included in the RI is guidance on minification and combining JavaScript files.

The 3 included QuickStarts are:

• RI_WebForms. This is a port of the RI, developed using MVC, to Web Forms.
• Validation QuickStart. This shows server and client-side validation.
• WebFormsMVCHybrid. This shows MVC functionality within a Web Forms application.

The documentation includes draft guidance on cross-site scripting, cross-site request forgery, update panel, and more.

Bare with us that this is in a very early stage, so for example you might see a bad looking site, as we hadn’t hired a designer to enhance our CSS and so on (yup, us developers frequently pick colors from the combobox, and remember that the usual choices are Aqua, Magenta and so on :D).

How can I consume this?

There is a readme file included in the drop, that will tell you how to get the dependencies (they are just a few). It will also tell you how to run the RI or the JavaScript unit tests.

Once you are running the RI, you’ll see in each page a very last-minute-information-panel, that will tell you what we are demonstrating in each of the pages, from a technical perspective (expect improvements to this in future drops).

Now that this drop is out, I’ll be writing blog posts more frequently, to tell you about the decisions and hidden goodies we’ve found while developing.

Where is it?

Get it from codeplex! Current drop is the one from Nov 13th.

Remember, WE WANT FEEDBACK FROM YOU! (yes, we are not kindly asking, you can make the project be what you need, we just need to know what you think about it).

Good news people: WCSF 2.0 was finally shipped.

There were a lots of changes since the June 2007 release (WCSF 1.1). Many of you may have already downloaded the bundles that were released in October through December.

The big change since the October 2007 releases (apart from having all the content that was shipped as separate bundles in a single deliverable) is that this release targets Visual Studio 2008 and .NET Framework 3.5 natively. There are also some changes that enhance the performance of the Composite Web Application Block, and some other minor changes and bug fixes.

There are already some great posts about this release that contain detailed information of this new release, so instead of writing it myself, I’d better link you to them:

• See Blaine Wastell’s post
• See Glenn Block’s post
• See Michael Puleio’s post

Go to the Web Client Software Factory website and download the installer now!

I’m proud to announce that the Composite Web Client Libraries Bundle (including Composite Web Application Block and associated libraries) and the Automation Bundle (a.k.a the Web Client Software Factory Guidance Package) has just been released.
Both releases are updates to what was previously packed in one deliverable as the Web Client Software Factory - June 2007 release,
This release of the Composite Web Client Automation Bundle has additional recipes as well as modifications and bug fixes to some existing recipes. PageFlow recipes have been removed, but don’t worry too much, as they will be released as a separate automation bundle. This will allow you to take only the assets you really want to use on your web applications.

The Composite Web Application Library Bundle adds support for creating responsive composite Web applications using Microsoft’s ASP.NET AJAX and AJAX Control Toolkit.

Be sure to download these bits, as they are a must for developing web client applications on the .NET Framework. Don’t miss the other bundles from the team while you’re on it on the codeplex site.

Coming soon: a Reference Implementation that puts all these pieces together, so stay tuned!

As you may know, p&p is in our lives to provide us (the developer community) with guidance for different and recurrent topics.

We will be releasing a series of bundles that consist mainly of guidance in the form of documents and small quickstarts that illustrate some of the concepts in the docs which concentrate on one specific topic each time.

In this first bundle released by p&p, the topic is the AutoComplete feature on text boxes.

For more info, read Glenn’s post, or go directly to the landing page and download it here.

There is a new Knowledge Database to organize all of the content that is already out there on the Internet about Web Client Software Factory.

The KB is very well categorized, and easy to access. If you’re a WCSF user, you should definitively check it out, as you’ll find solutions to many common problems and little pearls that are worth reading. They promise to update it periodically, so be sure to bookmark it.

More info on Ezequiel Jadib’s blog post, or go directly to the KB itself.

That’s right, the second weekly drop is available on Codeplex for you to download.

We’ve decided to try a new approach to injecting dependencies to web pages. Instead of letting the application build up every page automatically for you, you have to specify with code that you want the page to be built up. Why? So you can build user controls, master pages and web services in the same consistent and high-performant way.

But what about other approaches already on the web? we’ve considered them, but we wanted to try this approach too. One advantage over the ones we saw, is that this also works with dynamically created UserControls, which will probably be an important part of WCSF vNext when we focus in UI Composability. You can read more on this in Juan’s post, or better yet, download the code here.

Please, play around with the code, and tell us what you think. Your feedback is very valuable. Remember that we are on a very early stage, so your feedback can make a huge difference.

The P&P has started the development of the WCSF vNext after releasing the WCSF 1.1 minor update.

We plan on releasing weekly drops for your early evaluation, so we can drive our development based on your feedback. So don’t hesitate to download the drop and let us know what you think.

As you’ll see, June 29th drop is in a really early stage, and basically what we have until now is a draft of a Reference Implementation to start digging in what guidance we can provide in this common scenario.

Download the drops from Codeplex: WCSF Source Code

With the Web Client Softare Factory you can easily use dependency injection for object creation and obtaining required resources. For example, the factory demonstrates how to use view/presenter pairs with an application (module) controller. As the user interacts with a Web page, the presenter notifies the controller, where the business logic and flow decisions reside. This means a presenter requires a reference to a controller instance. With the WCSF, the presenter can use the CreateNewAttribute to have the controller object injected into the presenter (the presenter does not create the controller):

public ApproveCustomerViewPresenter([CreateNew] CustomersController controller)
{ 
  controller = controller;
}

However, the CreateNewAttribute requires that you specify a concrete type. Wouldn’t it be great if we could request an implementation of an interface, and make WCSF behave like a simple factory?

For example, imagine that we want to tell the ObjectBuilder to inject a concrete implementation of the interface IMyInterface, but we don’t really care which implementation to use. In fact, we want to let some other part of the code (e.g. in another module, or in the configuration file) determine the concrete implementation to use. In essence, we want the developer experience to be similar to the code required when you request a service:

public CustomersController([ServiceDependency] INavigationService navigationService)
{
  navigationService = navigationService;
}

While we want the developer experience to be similar, we want the behavior to be different. We want the ability to have a new object created and obtain a reference to that object.

First Attempt

Those with experience in CAB or SCSF might consider implementing this with a  TypeMappingPolicy. Actually, that was the first thing I intended to do, as I was inspired by this forum thread. Unfortunately, it turns out we can’t use the TypeMappingPolicy without modifying the way WCSF builds objects. When objects are created by WCSF, it assigns a random GUID as a temporary id for the object being built. It does not let you specify a custom id, and therefore the builder cannot find the appropriate TypeMappingPolicy required to provide a new concrete type of the object being requested.

Proposed Solution

Introduce a new attribute, InterfaceDependencyAttribute, to provide this functionality. With this attribute, your code requests an object instance that implements a particular interface:

public ModuleController([InterfaceDependency] IMyInterface myInterface)
{
    myInterface.Foo();
}

We want this to attribute to behave in the same way as the [CreateNew] attribute, but instead obtain a concrete implementation of an interface.

What if there are multiple implementations of an interface, and a developer wants to request a particular one? The attribute allows you to specify the key of a particular implementation:

public ModuleController([InterfaceDependency] IMyInterface myInterface, [InterfaceDependency(Key="Other")] IMyInterface myOtherInterface)
{
    myInterface.Foo();
    myOtherInterface.Foo();
}

To support this, you must add a mapping when you register particular types. This way ObjectBuilder will know which concrete type to inject. For example in the ShellModuleInitializer you could add the following method:

private void AddRegisteredTypes(IInterfaceMappingService interfaceMappingService)
{ 
    interfaceMappingService.RegisterType(typeof(MyConcreteObject), typeof(IMyInterface)); 
    interfaceMappingService.RegisterType(typeof(MyOtherConcreteObject), typeof(IMyInterface), “Other”);
}

And in the Load method, add the InterfaceMappingService to the root WorkItem.

AddRegisteredTypes(moduleContainer.Parent.Services.Get<IInterfaceMappingService>());

Extending WCSF

To make this even easier (and not require developers to write this code in each application) we could extend WCSF a little. All we need to do is add a few classes to our solution, and register IInterfaceMappingService as a global service before trying to build any object using the InterfaceDependency attribute. This could be done in a custom application class, and make global.asax inherit from this class:

public class CustomWebClientApplication : WebClientApplication
{ 
    protected override void AddRequiredServices() 
    { 
        RootContainer.Services.AddNew<InterfaceMappingService, IInterfaceMappingService>(); 
        base.AddRequiredServices(); 
    }
}

Possible Enhancements

You could even add another attribute to decorate your concrete classes, and let ObjectBuilder register them automatically to the IInterfaceMappingService. (This is not done in the provided source code.) Another improvement could be to register the concrete types in the web.config file, and implement a class that reads them and configures them automatically.

Comparison between CreateNew and InterfaceDependency attributes

Don’t confuse this InterfaceDependency with ServiceDependency. The ServiceDependency attribute is specific to CWAB services (which are stored in the services container), and not for the creation of objects. The InterfaceDependency attribute is closer to (but a little more complex than) the CreateNew attribute. The difference is that with the InterfaceDependency attribute you do not specify which concrete class to instantiate.

The following table compares both attributes:

Source code

• You can get the source code of the CompositeWeb.Extensions project by downloading the CompositeWeb.Extensions.zip file below. The solution contains the source code of the required services and parameter, plus a sample application that uses this approach
• If you face problems building the solution, make sure the references to the Composite Web Application Block and ObjectBuilder assemblies are correct.
• Important: The code is provided “as is” without warranty of any kind.

Attachment: CompositeWeb-InterfaceDependency.zip

The “fix” provided here for the Add View (with Presenter) seemed to solve the problem, but we realized soon that it was not the case.

Since a lot of members of the web client community at Codeplex are having problem with this, I decided to post the fix that will be part of WCSF 1.1.

1. Install the source code of the Guidance Package if you haven’t done so already. Open WebClientFactory Guidance Package.sln (located in GP\WebClientFactory) in Visual Studio

2. In Recipes\ CreateWebClientFactoryView.xml, change the ModuleInfos and SelectedModuleInfo arguments’ Type to the following:

<Argument Name=“ModuleInfos“ Type=“Microsoft.Practices.WebClientFactory.ValueProviders.CustomDependantModuleInfo[], Microsoft.Practices.WebClientFactory.GuidancePackage“>

…

<Argument Name=“SelectedModuleInfo“ Type=“Microsoft.Practices.WebClientFactory.ValueProviders.CustomDependantModuleInfo, Microsoft.Practices.WebClientFactory.GuidancePackage” Required=“false“>

3. Add the following class to the ModuleInfoListProvider.cs file inside the namespace brackets (to keep the amount of changed files for this fix to a minimum), and add a using statement to Microsoft.Practices.CompositeWeb.Interfaces:

public CustomDependantModuleInfo(IModuleInfo source) : base(source.Name, source.AssemblyName, source.VirtualPath)

{

    if (source is DependantModuleInfo)

    {

        this.Dependencies = ((DependantModuleInfo)source).Dependencies;

    }

}

4. Change the ModuleInfoListProvider class to return an instance of this new class instead of the conflicting one:

…

WebModuleEnumerator moduleEnumerator = new WebModuleEnumerator(store);

IModuleInfo[] modules = moduleEnumerator.EnumerateModules();

CustomDependantModuleInfo[] returnModules = new CustomDependantModuleInfo[modules.Length];

for (int i = 0; i < modules.Length; i++)

{

   returnModules[ i ] = new CustomDependantModuleInfo(modules[ i ]);

}

newValue = returnModules;

return true;

…

5. Build and Register the custom package

6. Open a new instance of Visual Studio. If you want to use this modified package with your existing solutions, go to Tools -> Guidance Package Manager, disable Web Client Development and enable Custom Web Factory Guidance Package instead.

The source code provided is not the same as the one that will be provided in the upcoming WCSF 1.1 release, but the main idea is the same.

For your convenience, here are the two modified files, just extract the zip in the GP folder of the source code overriding both files when asked. Then open the solution and register the package.

Attachment: WCSF_AddView_crashfix.zip

One of the requested features for the Web Client Software Factory has been the possibility to register global services through the Web.Config file. By registering the services through configuration there is no need to rebuild any module when you want to switch the concrete implementation of a service.

This is what we wanted to be able to write in the Web.Config:

Ezquiel Jadib and me have been working on this request, and to see what we came up with, check Ezquiel’s blog post: http://staff.southworks.net/blogs/ejadib/archive/2007/03/30/WCSF_3A00_-Registering-services-through-configuration.aspx