Smart Client

How I won the Lab49 WPF in Finance Innovation Contest?

Szymon Kobalczyk — Mon, 17 Mar 2008 20:39:06 GMT

Honestly, I still don't know how I did it. The LAB49 WPF in Finance Innovation Contest was announced back in December and I think I first read about it on Tim Sneath blog. With all the cool prizes I was very inclined to participate, but it quickly turned out that its available only to US citizens. However that changed in the first week of February, so I started considering it again, but still didn't had any clue what to do. You see the goal of this contest was to create a WPF application that visualizes a set of provided financial data in some interesting way. While the first part was easy (writing the app in WPF) the hardest part was to figure out what to do with the data. Only after "last call to action" email from Daniel Chait I decided its about time to start coding.

Because I started working late on this project, initially I wanted to create only a charting control capable of displaying the line and candlestick plot of stock prices. But after the contest deadline was extended I started thinking of a better way to visualize the stock prices for a given day – something that goes beyond a simple listbox or a datagrid. The next option I considered was to create a heatmap – i.e. use color gradients to denote the change in stock prices relative to the previous day. But in all samples I’ve seen these symbols were placed on a regular grid and the placement didn’t correspond in any particular way with the data. I started thinking about how to sort the symbols so that those that experienced similar data change would be close to each other, and those with different data change remain further apart. This finally led me to the idea of applying Craig Reynolds’ flocking algorithm to perform this clustering.

Here is a screenshot from my final entry called Stock Information Boids:

Also you can already download the source code for this application from my resource page at MSDN Code Gallery. Make sure to read the user guide that describes how the algorithm works and how to use the application.

Turns out that for some reason the judges liked my solution, because last week at the closing keynote of 2008 Microsoft Financial Services Developer Conference in New York, Daniel Chait announced that I won the grand prize in the contest!

The two finalist were Jacob Carpenter and Jobi K Joy, while the honorable mention went to Paul Hounshell. Congratulations guys, great work! You can download their very cool applications from here:

In following weeks I will try to share some details on my implementations (in particular about the Timeline and Flock controls). I was already told that Jobi K Joy and Jacob Carpenter plan to do the same, so make sure to subscribe to their blogs too.

I would like to thank the judges for selecting my entry. And last but not least, big kisses for my wife Joanna for letting me work on the project all nights and weekends considering her present condition (L)

Introducing WikiSpider

Szymon Kobalczyk — Wed, 30 Jan 2008 21:22:47 GMT

About two weeks ago Daniel Biesiada (who is ISV DE here in Poland) announced on his blog a little programming contest. The goal was to build a .NET application that would check if the the theory of Six Degrees of separation applies to two given topics in Wikipedia. In order words to find a path from the source page to destination with no more then six links. At the time I had not much else to do (apart from setting up website for the C2C Conference, helping out with the European Silverlight Challenge, and preparing for the WPF Beta Exam) so I decided to give it a try.

Fast forward two weeks and I present you my WikiSpider:

As usual building this took me much more time than I initially anticipated (including few sleepless nights). And still I didn't make it before the deadline, so this even didn't count as a contest entry anymore (sigh!). However this was mainly because my personal goal was to throw in there every new piece of .NET 3.5 I could find fit - and most of them I never used before.

Here are some key technologies I managed to put into this:

The UI is done in WPF (and this was the only thing here I knew a bit about). However I borrowed the graph control from the excellent Kevin's WPF Bag-o-Tricks.
The caching is done using SQL Server Express. Initially I wanted to do this using SQL Compact but I run into performance issues and had to switch to full SQL in order to run the queries in profiler. But since this was fixed (with big help from Paweł Potasiński) I could try with SQL Compact again.
Of course data-access is done using LINQ to SQL. And of course this was the main source of my problems, as it was first time I've done anything in it, and so far I only read the Scott Gu's tutorials. Still, I'm already in love with it.
Speaking of LINQ. Initially we were screen scrapping the HTML pages to get all the links. But turns out that Wikipedia has a little known about Query API that enables to get the page content in XML. So the obvious move was to rewrite this part with LINQ to XML.
The path-finding algorithm was borrowed from Eric Lippert. The nice thing about it is that it uses lots of C# 3.0 language features, so it is a great resource to learn from. The new C# syntax is so addictive that I already miss it in my other project.
Finally, I wanted to publish the app with ClickOnce but run out of time. So maybe later.

I learned many interesting things and tried out some new stuff that I wanted to check out anyway. I will try to share my discoveries in the next few days, but in the meantime feel free to download and take a look at may code (I know it's not prettiest piece of code you've seen but I was in a rush to finish this on time):

Download the source code

Here you can also download the entries from other participants: Łukasz Sowa, Maciej Rutkowski, and Arkadiusz Benedykt. Congratulations to all of you!

Installation

Download the code from the above link and extract it.
The application uses local SQL database for caching and unfortunately you need to create it yourself (now you know why I wanted to use SQL Compact). Simply launch SSMS and create empty database called WikiCache.
Run the Create_WikiCacheDB.sql script from the data folder to create the database schema.
By default the app is configured to look for the WikiCache database on the local SQLEXPRESS instance. If you installed it somewhere else update the connection string in app.config accordingly.
Run the build.bat or open solution in Visual Studio 2008 and run from there.

Usage

Enter the name of the Wikipedia page in the address bar at the top and press the Go! button. The entered topic and the pages it links to will be displayed as graph.
Clicking on any topic will make it currently selected (put it in the center of the graph).
Right-click on any topic to open the context menu. Select "Open in browser" to.... load the page in browser.
Select "Set as source" or "Set as destination" to put the topic name in appropriate field on the sidebar
[Note: Currently it's the only way to show the sidebar]
You can also enter the source/destination topics manually.
When both are set click on the Start button to begin searching for the path. Few statistics are displayed on the bottom of the sidebar.
During the search you can still use the graph or navigate to other pages (thanks to the BackgroundWorker magic).
When path is found it is displayed on the sidebar, and you can click on each topic to center it on graph.

Have fun!

White paper: Designing Smart Clients Based on CAB and SCSF

Szymon Kobalczyk — Sat, 13 Jan 2007 10:09:00 GMT

A year ago I've published a series of articles on understanding Composite UI Application Block (CAB). Although I've never got to finish it I still occasionally receive comments and questions on this subject.

Recently I came across two great papers on CAB and SCSF that I would like to share:

Designing Smart Clients Based on CAB and SCSF by Mario Spuszta, is architectural guidance created for RACON Software GmbH, and later published as white paper on MSDN. It contains complete overview of CAB and SCSF, with many interesting tips on implementation and project management. It answers many question I had when I was learning CAB. What I particularly liked is the use case-driven strategy for identifying work items.
Commonwealth Bank of Australia CommSee Solution: Case Study. Commonwealth Bank of Australia designed, developed, and implemented its CommSee application, a relationship banking solution custom-built by the Commonwealth Bank of Australia. This project was major success and has been successfully deployed to 30,000 users at more than 1,700 sites across Australia. Its architecture inspired patterns&practices implementation of CAB and serves as great source of ideas on building composite smart clients and SOA applications. Ron Jacob recorded series of video interviews with the CommSee core team available on Channel 9.

Understanding Composite UI Application Block, Part VII

Szymon Kobalczyk — Sun, 26 Feb 2006 06:57:00 GMT

There seams to be some confusion around WorkItem's State. I've seen few posts on CAB message boards with questions if it's OK to put certain data into it. I will try to add my two cents to it but note that this is my point of view and it might be wrong.

Let's think for a minute what kinds of data we can have in our applications. First that comes to mind is the data that is presented to the end-user and this of course must be stored in the View (SmartPart) for the time it's displayed. This data can be loaded from some external sources (files, database) but this should be handled by services. To do their work services can also carry some runtime data that is not visible to the end-user.

So we have some flow of data between Views and Services (preferably with Controller or Presenter in the middle). But many times we also need to share same data between several Views. This will be for example in classical master-detail scenario when one View presents list of records and the other one shows details of currently selected record. Clearly the information of selected item lays outside of the service's domain because the same service can be used by several Views so from this standpoint it should be “stateless“. So here is where WorkItem's state comes in handy. In short State property is a loosely typed collection of items identified by some key. In my understanding it should be primary used for communication between SmartParts and other Items contained within the same WorkItem and its child WorkItems.

There are several mechanisms in CAB that help us with this scenarios.

State change notification

Often we want to react somehow to changes in State item's value. CAB automatically publishes events to state changes and allows to declare handlers simply by putting StateChangedAttribute on a method:

[StateChanged("MyProperty")]
public void MyProperty_StateChanged(object sender, StateChangedEventArgs args)
{
 // handle state change
}

The StateChangedEventArgs contain State item's key, and both old and new values. Of course there can be more then one handler to this event. Also check out John Luif's blog entry on this.

Injecting State into child WorkItems

Sometimes we need to pass the current value of some State item from parent WorkItem to the newly created child WorkItem. We can do this by manually copying the respective values or let the CAB do the work for us. To indicate that property value or constructor parameter should be injected from parent WorkItem's State we can use the StateAttribute:

[State("MyProperty")]
public string MyChildProperty
{
get { ... }
set { ... }
}

Note that this will only copy the value when child WorkItem is created and won't update it when it changes on parent WorkItem. There are some restrictions when using state injection and be sure to read two excellent entries on Mariano's Szklanny blog on how to avoid them.

Persisting WorkItem's State

Finally, CAB defines IStatePersistenceService that allows to persist WorkItem's State between sessions. Out of the box CAB provides to implementations: FileStatePersistenceService and IsolatedStorageStatePersistenceService. Both store state in binary files using the BinaryFormater serializer, but the later one uses Isolated Storage so it should work in restricted access scenarios. Both inherit from StreamStatePersistantService base class with you can also use to implement you own service.

This service does not load by default and you need to add following entry in app.config to enable it:

<CompositeUI>
 <services>
 <add serviceType="Microsoft.Practices.CompositeUI.Services.IStatePersistenceService,
Microsoft.Practices.CompositeUI" 
 instanceType="Microsoft.Practices.CompositeUI.Services.IsolatedStorageStatePersistenceService,
Microsoft.Practices.CompositeUI" />
 services>
CompositeUI>

To store or retrieve WorkItem's State simply use it's Save() and Load() methods. Note that it uses WorkItem's name to uniquely identify that WorkItem's state so make sure you assign it to the same value before saving and loading.

I haven't tried this one yet but it opens some interesting possibilities.

As example of using state let's take a look at the Inventory WorkItem of my sample application. There are three primary views in this WorkItem: Product list, Items list and Item details. When user selects a product category the first view shows list of products for this category. Next when product is selected second view shows product items. Then after selecting the item it's details are presented on the final view. The IDs of currently selected records are stored in Inventory WorkItem's state and the View's are wired to state change events so they react immediately to any changes.

Currently only one view is displayed at a time but now we can easily build an "Advanced View" that will show all three views at once. We will start by creating container SmartParts for both modes. SimpleView hosts a DeckWorkspace while AdvancedView contains ZoneWorkspace with two SplitContainers. Both also contain simple link buttons to switch the view. These buttons invoke a TogleValueCommand that changes the value of the ViewMode property. This in turn rises a StateChange event that is handled in ViewMode_StateChanged method. Finally this method changes the current container view and moves the three inventory views to current workspace. It also tries to maintain current active SmartPart.

You can see the inventory screens in both modes below:

But the nicest part in all this that I didn't have to change the existing SmartParts at all! They were already communicating with State and changing their arrangement on screen didn't required any changes to their code. Isn't that cool or what :-)

CAB sample published and future plans

Szymon Kobalczyk — Sun, 19 Feb 2006 10:46:00 GMT

The source code for SmartPetShop, my sample project for Composite UI Application Block, is now available for download.

If you want to run it, first I recommend to download and install the original PetShop.NET 3.2 from Microsoft , as it will setup properly the database and register COM+ services. After that you should update the connection strings in Win application's app.config with encrypted settings taken from original Web PetShop's web.config. Simply find settings like and copy them to app.config. Later I will try to provide my own installation scripts for this. Finally, to compile the code you would need to place CAB DLL's om the Lib folder.

Currently my changes concentrate only on presentation layer so I simply replaced the Web project with my own Win project. All other code remains unchanged (with kind of proves that this is indeed well architected application).

Future plans

My first goal was to create sample application that would demonstrate how CAB can be used in real-life project. But during the process I realized I can further extend this sample and try to apply some other new technologies emerging in .NET world. So here are my future plans for this project.

Finish conversion to Windows Forms
From the original Web PetShop there is only couple of functions left to implement (for placing orders). But looking at CAB I already covered following features:
To make it complete I still need to discuss:
- WorkItem's State and StateChange events
- Services
- Events and background processing
- Modules and WorkItem extensions
- ObjectBuilder
Reimplement Data Access Layer using Enterprise Library
CAB is only a little brother of EntLib so I think it makes sense to show how to use them both in the same application. I'm also curious to what degree it will simplify the original code for the data access and business logic layers. I will definitely explore the Data Access AppBlock but I will also try include others like Logging, Exception Handling and Caching. Also, I should try to replace the PetShop's ConfigTool with EntLib's Configuration. At the same time I would try to deploy the database on MS SQL 2005 Express using user instance databases and embedded update scripts (seen nice articles on both recently).
Separate client code from server
I called my version SmartPetShop to indicate that it will support the SmartClient architecture. There are three main characteristics of SmartClients: rich user experience, intelligent updates, and offline capabilities. If we assume that my CAB implementation provides richer experience that the previous Web based (actually it tries to mimic it closely) there are two things left to address. For installation and updates I would use ClickOnce, but there is not much to say that wasn't well known already. So last thing is to enable the application to work without connection to server. In this mode it should at least enable to browse the product catalog and place items in shopping cart. Then, when application goes on-line, user can submit orders and check status of earlier orders.

Currently the application connects directly to database so the main task here would be to move the data access and business logic to separate server process. Necessity to connect these two will allow me to explore another exciting new technology, the Windows Communication Foundation (aka Indigo). This will also test the current architecture as it seems that it should suffice to switch ServiceAgent implementations and there should be no change to UI logic.
Another type of client
When I'm done with above I should have working example of SmartClient. Then I can try to implement another type of clients. There are two candidates. I'm really excited to start working with Windows Presentation Foundation (aka Avalon), however I don't think I would have opportunity to apply it in my professional work in foreseeable future. It is more likely that I would need to refresh my skills in ASP.NET. I stopped working on Web apps almost one and a half years ago and didn't had opportunity to try out all the goodies in ASP.NET 2.0. I'm also excited about the Atlas extensions since I've done some work with AJAX technologies on my own (some really cool DHTML behaviors).

So here you have it. I will try to do as much as I can of this in upcoming months. I need to learn these things anyway but if I also put myself to write about it the process is more systematic. Feel free to drop me a note if you have additional ideas or like me to explore any particular topic more closely.

Update: I just discovered that last week Microsoft released .NET Pet Shop 4.0. What a perfect timing! I guess I need to revise my goals as some became obsolete. Most notably these guys saved me work (and pleasure) of upgrading to ASP.NET 2.0. I haven't reviewed the code yet but judging from the accompyning article most changes were made to the presentation layer (bummer!). However, it seems it would be easier to update my code base now before starting any modifications to other layers. Anyway, it's great this project is not dead and I'm sure it will be valuable source of information on building enterprise .NET 2.0 applications for everyone.

Understanding Composite UI Application Block, Part VI

Szymon Kobalczyk — Sun, 05 Feb 2006 18:54:00 GMT

It's been over a week since my last post on Composite UI App Block, but don't start thinking I have given up on it already. I still want to finish the PetShop sample and at the same time to cover all important parts of CAB on this blog.

Last time I have covered some basics on using Commands and UI Elements and demonstrated how I implemented commands in my sample application. But as I said before, out of the box CAB only has UIElementAdapters for ToolStrips and MenuStrips. Just to get started I put all my commands on the main menu, but the original PetShop was a web app so this were all links. So it got me thinking what it takes to implement my own UIElementAdapter. For most people support for menus and toolstrip could be enough, but some of us use third-party controls or wants to invoke commands from other controls like trees, or Outlook style navigation bars. I think knowing how to extend CAB to handle such situation can be helpful.

(On the other hand, I heard on ARCast that Infragistics committed to release CAB wrappers for their controls so those of you who use NetAdvantage don't need to read any further).

First thing was to create the control that will display my links and fire events when one is clicked. For this I have extended the standard LinkLabel adding collection of my own LinkListItems. These items are similar to a menu items having Text, Enabled, and Visible properties, and a Click event. The control automatically updates itself based on these settings. Under the hood it constructs a single line from the texts of all visible items inserting bars ( | ) as separators, and it positions a LinkArea on each enabled item. Then upon receiving LinkClicked event it propagates it back to corresponding item and fires its Click event. It took ~200 lines of code but there is nothing fancy so I won't bore you with it here.

Now having the control ready I need to plug it into the CAB framework. There are three additional elements that I need to provide: IUIElementAdapter, IUIElementAdapterFactory, and CommandAdapter.

As explained in last post, UIElement adapter is responsible for properly showing items of given UIElement type. This interface has only two methods: Add and Remove that are called each time items are added or removed from extension site. In my case these methods simply add or remove items from the LinkList items collection:

public class LinkListUIAdapter : UIElementAdapter
{
    LinkList linkList;

    public LinkListUIAdapter(LinkList linkList)
    {
        Guard.ArgumentNotNull(linkList, "linkList");
        this.linkList = linkList;
    }

    protected override LinkListItem Add(LinkListItem uiElement)
    {
        if (linkList == null)
            throw new InvalidOperationException();

        linkList.Items.Add(uiElement);
        return uiElement;
    }

    protected override void Remove(LinkListItem uiElement)
    {
        if (uiElement.Owner != null)
            uiElement.Owner.Items.Remove(uiElement);
    }
}

The role of IUIElementAdapterFactory is to provide appropriate UIElementAdapter instances for given UIElement's type. The Supports method should indicate if particular factory supports the given UI Elements type, and then GetAdapter methods should create adapter for that UI Element.

public class LinkListItemAdapterFactory : IUIElementAdapterFactory
{
    public IUIElementAdapter GetAdapter(object uiElement)
    {
        if (uiElement is LinkList)
            return new LinkListUIAdapter((LinkList)uiElement);

        throw new ArgumentException("uiElement");
    }

    public bool Supports(object uiElement)
    {
        return (uiElement is LinkList);
    }
}

If we want to be able to attach command to the UI Elements we also need to provide a CommandAdapter. It's purpose is to provide logic that is needed for UIElement to invoke a Command, and also to synchronize changes to Command with the UI Element. Luckily for me the first part is handled by the base class EventCommandAdapter, so I only had to make sure that changes to Command status will be applied to the corresponding link:

public class LinkListItemCommandAdapter : EventCommandAdapter
{
    public LinkListItemCommandAdapter()
        : base()
    { }

    public LinkListItemCommandAdapter(LinkListItem item, string eventName)
        : base(item, eventName)
    { }

    protected override void OnCommandChanged(Command command)
    {
        base.OnCommandChanged(command);

        foreach (KeyValuePairstring>> pair in Invokers)
        {
            pair.Key.Enabled = (command.Status == CommandStatus.Enabled);
            pair.Key.Visible = (command.Status != CommandStatus.Unavailable);
        }
    }
}

Having all these three pieces we can now register them in CAB. It should be done in the AfterShellCreated method of the ShellApplication class:

protected override void AfterShellCreated()
{
    base.AfterShellCreated();

    ICommandAdapterMapService mapService = 
        RootWorkItem.Services.Get();
    mapService.Register(typeof(LinkListItem), typeof(LinkListItemCommandAdapter));

    IUIElementAdapterFactoryCatalog catalog = 
        RootWorkItem.Services.Get();
    catalog.RegisterFactory(new LinkListItemAdapterFactory());
}

Finally we have all set up and we are ready to use the new UI Elements. But the best thing it was, that the only change I had to make was to replace references to ToolStripMenuItem with my own LinkListItems like this:

  LinkListItem signInItem = new LinkListItem("SIGN IN");
  UIExtensionSites["NavigationBar"].Add(signInItem);
  Commands["SignIn"].AddInvoker(signInItem, "Click");

All the other code that handles commands and updates their status remains unchanged. And thats the real advantage of CAB!

Understanding Composite UI Application Block, Part V

Szymon Kobalczyk — Tue, 24 Jan 2006 17:28:00 GMT

In most applications certain user interface areas are shared among various modules. Examples are all kinds of menus, tool bars, status bars, Outlook style sidebars and others. What is common for all of them is that they serve as containers for collections items (menu items, toolbar buttons, etc.) that user can activate to trigger some actions in the application. For example, the File > Open menu item normally would invoke the action of opening a file. However same action could be also accessible using a toolbar button. So it is desirable that we could decouple the user interface elements from the actions that they trigger. CAB provides solution for this in the form of UIElements and Commands.

UIExtensionSites are the shared containers that can contain your UIElements. Out of the box CAB provides support for MenuStrips and ToolBarStrips but you can easily add support for other elements by implementing your own UIElementAdapter. After you add a menu or toolbar to your SmartPart you need to register it as an extension site, by calling the RegisterSite method on the WorkItem.UIExtensionsSites collection and providing unique identifier for that site. Usually extension sites are registered in the RootWorkItem by the developer of shell the application. Later when module developer needs to add his own items to that site he only need to create these items as usual and than call the Add method of the specific UIExtensionSite. The corresponding UIElementAdapter is responsible for properly showing items for given UIElement type.

Next step is to attach Commands to your UIElements. Commands are used to assign easily the same code to multiple UIElements. To declare command you need to create event handler that implements your action. Then you add the CommandHandler attribute to the method declaration specifying command name. To assign Command with a UIElement you can call the AddInvoker method on specific Commands collection passing reference to the UIElement and specifying name of its event that will trigger the action.

All pages in the .NET PetShop sample share a common NavigationBar that contains links to following pages: Sign In, Sign Out, Edit Account, View Shopping Cart and the Search TextBox. So we can consider them as UIElements that invoke Commands in different modules. For example, SignIn command is handled in the Account module, and ViewShoppingCart is handled in the Orders module. So it would be nice if each module could register the commands it provides and the Shell doesn't need to know anything besides providing an extension site for them.

Because out of the box CAB only supports UIElementAdapters for toolbars and menus for now I will implement the navigation bar in form of the main menu to see how this works. Later I can implement a custom UIElementAdapter that would closely match the web style.

First I need to add a MenuStrip to the the ShellForm and make it publicly accessible. Then I can register it as UIExtensionSite by adding following line in ShellApplication's AfterShellCreated method:

  RootWorkItem.UIExtensionSites.RegisterSite("NavBar", Shell.menuStrip);

Basically that is all that shell developer needs to do -- the rest belongs to module developers. So I quickly switch hats, and go to the account management module. Let's start by adding the SignIn button. In the OnRunStarted method of AccountWorkItem I add following lines:

  ToolStripMenuItem signInItem = new ToolStripMenuItem("SIGN IN");
  UIExtensionSites["NavBar"].Add(signInItem);

As you can see, first I create a normal ToolStripMenuItem. But then, instead of adding it directly to a MenuStrip, I add it to the UIExtendsionSite defined earlier. Internally CAB finds the MenuStrip defined earlier in ShellForm and passes it together with the menu item to the correct UIElementAdapter with knows how to handle them both correctly.

Now, when I run the application I should see my first menu item and I can add items for other two commands (SignOut and EditAccount) the same way. However, clicking all these menu items does nothing so I need to attach handlers for appropriate events on these items. I could to this the usual way by directly attaching instance method to the Click event but in CAB we should use Commands to handle such things. Following line will register the Click event of the SignIn menu item as invoker for the SignInCommand:

 Commands["SignInCommand"].AddInvoker(signInItem, "Click");

To handle this command I need to declare the event handler and mark it with CommandHandler attribute:

  [CommandHandler("SignInCommand")]
  public void SignInHandler(object sender, EventArgs e)
  {
    SignIn();
  }

What is important is that command handlers and UI elements that invoke them doesn't need to be defined in the same class or in other way directly accessible. For example, the command could be invoked in one WorkItem and handled in another WorkItem, SmartPart or Presenter. And I guess that there can be multiple handlers as well as many invokers attached to single command but I haven't tried this yet.

In many cases command's availability depends of the application's state. For example, toolbar's undo button would be disabled if user hasn't made any modifications. In my case the SignIn button should be visible only if no user has authenticated and SignOut and My Account buttons should be visible otherwise. Normally I would control this by setting the Visible property on MenuItems but again in CAB I can do this indirectly using Commands. This ensures that if there are multiple UIElements for the same Command then all of them would get updated accordingly. Commands define the Status property that can have one of three values: Enabled, Disabled and Unavailable. When value of this property changes, the adapters linked to particular command can apply these changes to the corresponding UIElements. So in my case when user signs in or signs out I execute following code:

  if (userAuthenticated) 
    Commands["CommandSignIn"].Status = CommandStatus.Unavailable; 
  else
    Commands["CommandSignIn"].Status = CommandStatus.Enabled;

Unit-testing in CAB applications

Szymon Kobalczyk — Fri, 13 Jan 2006 19:54:00 GMT

Here is another gem from the message boards (thanks to Justin Burtch):

One of the advantages of MVP is that it allows easier unit-testing. For this you need to declare all public methods of view that the presenter uses as an interface, and then you can easily substitute the actual view with its mock implementation. But to test all your components properly you need to run them in the same environment as when you run it in a GUI. By this I mean that you have some WorkItem that adds these items into the ManagedObjectCollections of the WorkItem. The WorkItem internally uses the ObjectBuilder to create the objects and initialize the properties as specified in the attributes that adorn the properties.

In the VSTS Test project for CAB, there is an object called TestableRootWorkItem. Create one of those and then add the view and controller into it's Items collection. That will get the ServiceDependency to be detected and initialized. Though the initialization you are doing by adding this WorkItem into the mix means that you're testing the CAB dependency injection framework and without a little manipulation of configuration of services, you are also testing your service. Just means that if the test breaks, you have a couple of classes you have to investigate.

Here is one example of such test from the SC-BAT project:

[TestMethod]  
public void ShowAppraisalCalledInResponseToEventBrokerEvent()
{
   TestableRootWorkItem wi = new TestableRootWorkItem();
   wi.Services.AddNew();
   AppraisalDetailPresenter presenter = wi.Items.AddNew();
   MockView view = new MockView();
   presenter.View = view;
   wi.EventTopics[Constants.EventTopics.WorkingAppraisalSelected]
     .Fire(this, new DataEventArgs("1"), wi, PublicationScope.Global);
   Assert.IsTrue( view.ShowAppraisalWasCalled);
}

Understanding Composite UI Application Block, Part IV

Szymon Kobalczyk — Fri, 13 Jan 2006 14:45:00 GMT

Yesterday I was reading CAB message boards and came across number of threads with questions about implementing MVP patter in CAB. Indeed, among provided samples only the walk-through uses MVP but its rather simplistic. Luckily some of these questions got answered.

First of all I've learned of the Smart Client Baseline Architecture Toolkit project, that aims to provide collection of guidance for implementing Smart Clients (including Hands-On-Labs, How-Tos and Reference Applications). Although the project just started there are already first deliverables (and they promise to release frequently on weekly base). What's important, the provided reference application show MVP in more complex scenario. It also confirms my feelings that there was something wrong in my implementation.

If you want to learn about MVP pattern itself, see The Humble Dialog Box paper, that was mentioned as one that best describes the style of MVP that Smart Client team is doing. Another great paper is Twisting The Triad: The evolution of the Dolphin Smalltalk MVP application framework. It starts with widget-based approach, then introduces MVC and finally explains MVP and shows how it simplifies design while leveraging strengths of both earlier patterns. You can also read the MVP paper from Martin Fowler (although I read it a year ago and till now I didn't had a clue how to implement it properly).

Here is how I understand Model-View-Presenter pattern right now (you can refer to the diagram from last post):

The Model
This is the data upon interface will operate. It is typically a domain object and there is intention that such objects should have no direct knowledge of user interface. Instead the Observer pattern (in other words events) is used to communicate changes in model to the view.

The View
This is the presentation part that is responsible to display the contents of a model. The model is expected to trigger change notifications whenever its data is modified and these allow the view to reflect these changes on screen. This allows multiple views to be connected to a single model.

The view is also responsible for handling all raw user interface events generated by user gestures. These events are then translated into operations meaningful for given view and in most cases routed to the presenter.

The Presenter
This component governs how the model can be manipulated and changed by the user interface. Most of the user interface logic is built into a presenter class. The main difference between presenters and controllers is that presenter is directly linked to its associated view. That means the view can pass user interface events to presenter but also presenter can directly affect the state of the view.

How does it all fit in CAB? First of all you should remember that the WorkItem is NOT the model. State in WorkItam can be used to store model objects, but WorkItem is a higher level concept used to group components working together to fulfill some use case.

As far as I know there is no base class for Presenter. But in summary for Controller class you can read that it is “A base class for controllers and presenters that provides access to the WorkItem and State“. So the only thing that is missing is reference to owning View and we can create Presenter by extending this class. I also decided to declare it with generic parameters of ViewType and WorkItemType to avoid much repetitive code.

public class Presenter : Controller where WorkItemType : WorkItem
{  private ViewType _view;
  
  public ViewType View
  {
    get { return _view; }
    set { _view = value; }
  }
 
  public new WorkItemType WorkItem
  {
    get { return base.WorkItem as WorkItemType; }
  }
}

Then I use following code to instantiate the presenter when the view is created:

private MyPresenter _presenter;
 
[CreateNew]
public MyPresenter Presenter
{
  get { return _presenter; }
  set
  {    _presenter = value;
    _presenter.View = this;
  }
}

Understanding Composite UI Application Block, Part III

Szymon Kobalczyk — Mon, 09 Jan 2006 05:40:00 GMT

Next important part of Composite UI, if not the most significant, is the WorkItem. According to documentation it “a run-time container for components that are working together to fulfill a use case. These components may consist of SmartParts, controllers, services, UIElements, and other components.” So if we look at Outlook as example here, we have use cases like: browsing email, scheduling appointments or looking up contacts. As I understand, these would correspond to main WorkItems of EmailWorkItem, CalendarWorkItem and ContactWorkItem. Of course each of them can have child WorkItems like ComposeEmailWorkItem or EditContactWorkItem. What's more there can be also some cross references like you can call “add contact” use case from “browse emails”.

What is important here is that WorkItem is the only component that has access to all other components mentioned above. Visibility of all other elements to one another is limited and basically all communication goes through the WorkItem. This architecture nicely supports two most common design patterns for moder UI: Model-View-Controller (MVC) and Model-View-Presenter (MVP). The purpose of both patterns is to separate the user interface logic from the business logic. The primary difference between them is that MVC requires events that are exposed from the model to update the view, whereas MVP depends on the presenter to update the view directly. Diagram below compares the two patterns.

Here Forms, SmartParts and user controls play the role of View, and WorkItems hold state and other data that form the Model. To implement the Controller we can derive from the base class with the same name that contains references to owning WorkItem and associated State.

Lets get back to the PetShop sample and try to discover what WorkItems exist here. I would try to group the pages (now SmartParts) into following three functional areas:

Inventory - Category, Items, ItemDetails, Search,
Account - EditAccount, CreateAccount, SignIn, SignOut,
Order - ShoppingCart, Checkout, OrderBilling, OrderProcess, OrderShipping.

I will start with the InventoryWorkItem because it is first thing we would probably use in the PetShop. The Category, Items and ItemDetails views are all similar - they just show bunch of data for given identifier. For first two I would use DataGridView and a BindingSource and on the last one will just throw some labels. The interesting part is how to assign the identifier to the corresponding view. For this I would implement methods in InventoryWorkItem that create the view, put it into the workspace and order it to load data for given identifier. Here is one such method:

public void ShowCategory(string categoryId)
{ 
  CategoryView categoryView = this.SmartParts.AddNew<CategoryView>();
  this.Workspaces["content"].Show(categoryView);
  categoryView.LoadData(categoryId);
}

Methods ShowProduct and ShowItemDetails are implemented in similar way. But who would call these methods? Looking at the Inventory use case we have a scenario that selecting a product in a category would open a list of items for that product and then selecting one such item would show its details. Therefore I would turn one of the grid columns on both views into links and add handlers for CellContentClick event. But how do I access the WorkItem from the view? From the above diagrams I see that for this I should create a Controller. For now it would simply forward my calls to the InventoryWorkItem.

public class InventoryController : Controller
{  public new InventoryWorkItem WorkItem
  {
    get { return base.WorkItem as InventoryWorkItem; }
  }
  
  public void ShowProduct(string productId)
  {
    this.WorkItem.ShowProduct(productId);
  }
  
  public void ShowItemDetails(string itemId)
  {
    this.WorkItem.ShowItemDetails(itemId);
  }
}

Now I only need to create instance of this Controller for each view. We can do it quite easily with the power of dependency injection:

private InventoryController _inventoryController;
 
[CreateNew]
public InventoryController InventoryController
{
  get { return _inventoryController; }
  set { _inventoryController = value; }
}

The CreateNew attribute instructs the ObjectBuilder to instantiate and initialize the InventoryController when the SmartPart is created. How convenient.

One last thing is to actually create and Run the InventoryWork item. I would do this whenever user selects one of the categories from the default page or the navigation bar. And now I realize that I also need a root WorkItem to maintain the main page and other WorkItems. I create a ShellWorkItem and change the declaration of ShellApplication class. Now I can also move the code that loads the default page from application's AfterShellCreated to ShellWorkItem's OnRunStarted method. Finally, here is the code to run the InventoryWorkItem when user selects a category:

public void ShowCategory(string categoryId)
{
  InventoryWorkItem inventory = this.WorkItems.AddNew<InventoryWorkItem>("inventory");
  inventory.Run();
  inventory.ShowCategory(categoryId);
}

Ok. Now I will try to implement remaining views using what I've learned already. I won't be boring you with details until I start to use some new elements.