WPF command & CAB command - run into one another

My previous post was dedicated to the set of classes that constitutes my DM-V-VM pattern implementation being an extension to the smart client software factory (SCSF - CAB based factory) & Kent Boogaart's SCSFContrib (WPF CAB extensions project).

An interesting point was ActionViewModel class that contains and binds all view's commands. But there is another implementation of command pattern in CAB. Which of them a smart programmer should use? What are the pros and cons of each variant?

In CAB's command implementation you have access to an IoС-container and a whole lot of CAB's infrastructure (local services, resources, views). At the same time WPF command is tightly integrated in UI engine, and UI control is the WPF engine's problem. Is there a way to gain united advantages?

The answer is yes and it follows below.

Honestly speaking there is an implementation of merged CAB and WPF commands in Kent Boogaart's SCSFContrib project (WPF integration in CAB). It is a WrappedCabCommand, but I see a huge disadvantage in this implementation - it lacks ability to pass a parameter to a command. I solved this problem by extending Kent's approach.

IActionCatalogService

My main enhancement to WrappedCabCommand is the use of CAB's local service IActionCatalogService as main command executor and state controller. Here you can find a good description of this SCSF part. This service links named actions with methods, marked with [Action(ActionName)] attribute,

registrers conditions - a code that controls action state (whether it can be executed or not),

and allows executing named action (invokes a pipe of subscribed methods).

Method marked with [Action(ActionName)] attribute should be public and match an ActionDelegate delegate signature. Subscribing process is controlled by ActionStrategy from SCSF, that is plugged into the ObjectBuilder strategy chain.

Action conditions are classes that implement IActionCondition interface. Their respective method is automatically invoked by IActionCatalogService before executing, or it could be invoked externally by a client code through the same IActionCatalogService service. The service builds an action pipeline, and results an integral decision of all IActionCondition classes registered for concrete action.

СAB Command.

Commands in CAB are a collection of Command objects stored in WorkItem and indexed by unique string identifier. CAB itself works with commands by means of CommandAdapter class, controling subscribers, command invokers etc. Commands are created by a CommandStrategy that is plugged in the ObjectBuilder strategies chain. Command is created when the strategy meets in created object public methods marked with [CommandHandler(CommandName)] attribute and matching the EventHandler delegate signature. CommandAdapter keeps internal invokers and subscribers tables for the named commands. And when it catches the specified event in invoker, WorkItem invokes all methods subscribed by means of [CommandHandler(CommandName)] attribute.

Adding list view item as a ActivateOverview command invoker with Selected event

ActivateOverview command's subscriber method.

WPF Command.

In WPF commands are presented by classe implementing ICommand interface. There are 2 built-in command classes in WPF library - RoutedCommand and RoutedUICommand. They routes their CanExecute and Executed events in a visual-tree as it follows from their name. The built-in commands doesn't contains any predefined logic and simply allows to handle it by any object from VisualTree that is subbscribed to this command via CommandBinding. UI elements, that can be binded to a command, should implement ICommandSource interface. This interface contains the following properties: Command - the command itself (ICommand), CommandParameter - parameter being passed to the command handler (optional property) and CommandTarget - target - an object particular command will be executed on (optional property).

Come together!

I've chosen a CommandModel class invented by Dan Crevier as a foundation for merged CAB and WPF commands entity.

The ModuleCommand is the idea.

ModuleCommand class interface. IActionCatalogService is injected by CAB's IoC-container while created.

This class finds a CAB command object by name - CommandName.

I've made a convention in unique command naming, it is identifies by the following way - CommandName identifies Command and IActionCatalog Service action, CommandName with prefixes Before[CommandName] and After[CommandName] identifies command-triggers being executed before and after actual command execution respectively.

WPF invokes the ModuleCommand's object overrided OnQueryEnabled method automatically. It queries CAB command and ActionConditions if the command can be executed, promoting all the specific logic into the external infrastructure code (IActionCatalogService CanExecute call), and WPF reflects the command state in UI automatically - the UI element will be enabled or disabled.

There is an ActionTarget property in a class - it is an optional parameter, that the command will pass to the subscribed method automatically by means of IActionCatalogService.

WPF invokes the ModuleCommand's object overrided OnExecute method automatically when it catches event that triggers the command execution and delegates the execution to my ModuleCommand object that in turn delegates it to the Command and Action subscribers.

Thus the problem of merging WPF and CAB commands is being solved by means of IActionCatalogService. UI element is binded with ModuleCommand by CommandBinding in a visual tree, and IActionCatalogService links ModuleCommand with the CAB infrastructure and allows to pass a target and parameter objects to a command handler.

CAB command is still can be used when the logic is simple.

I said work!

Let's assemble an example now. We will modify the code from the previous post. Main changes will happen with FooViewModel class. There is only one type of command objects in it's collection now. There will be no more command classes with hardcoded logic.

but we'll need a command handler class and an action codition class. Here they are:


+ unique strings list.

Code for download: here.

Good luck!

PS: A very interseting approach was demonstrated by wpf-rockstar Josh Smith in this article. He suggests to make RoutedCommand "smarter", by adding it an ability to keep logic itself. Josh inherits his class from RoutedCommand and introduces an attachable-property, marking UI element as a command handler, and also he introduces 2 abstract methods OnCanExecuteCore and OnExecuteCore to be overriden in descendant classes. Other words we could replace our CommandModel class with SmartRoutedCommand, but it would involve xaml complexity.

PPS: remembered that I saw another approach that was built on CAB's EventBroker. But I don't like it though it is easier as it mixes the entities.

DataModel-View-ViewModel in WPF. Part 3 Example.

This is the last part on DM-V-VM pattern overview. In this part we'll write a simple WPF application built on this pattern.

DM-V-VM

Let's suppose that we have an object of class Foo that is provided by the SEModel class (parameterized with Foo and FooProvider types). It will be a demonstration of simplicity that SEModel gives - we don't have to write datamodel class, only provider class will be written.




All the logic is contained in a FooViewModel class. It is derived from ActionsViewModel as we'll have some actions triggers in UI (buttons). The actions are represented by two CommandModels - IncCommandModel and DecCommandModel. IncCommandModel increments Foo.Bar property when executed and DecCommandModel decrements it respectively. The DataModel is asked to refresh on View's Load event. DataModel will fetch data asyncronously and throw an event on UI thread as described in a first post.

CommandModel classes implements logic for editing underlying data (Foo object) that is referenced in CommandParameter property of UI command triggers (objects that implement ICommandSource interface - Buttons in our example).

Now it is a view's turn.

In this example we won't use an IoC-container and will hardcode all dependecies in our classes. View creates ViewModel on it's Initialized event.



And keeping in mind that ViewModel sets itself to the DataContext property of View (window in our case) we know that all visual tree of our view will inherit VM in DataContext property. So just put a ContentControl in a view, bind it's Content property to VM and write a template to render VM.



The only evil SEModel can bring - is lack of ability to bind to it's Entity property. DataBinding just can't fetch the object even if all paths are accurate in 2 or more level templates. But this issue can be avoided easily - just put your object in View's resources in DataModelLoaded event in ViewModel and reference it in Binding via Source property.



This is how our application looks like:



Source for download: here.

Good luck!

PS: PnP group will finish their new project called - Prism, soon. It is intended to become CAB's replacement in developing LOB applications with WPF. Check for weekly drops here.

DataModel-View-ViewModel in WPF. Part 2 View and ViewModel.

This is the second part on my DataModel-View-ViewModel overview. In the previous part I was talking about DM classes which are intended to supply presentation layer that is composed of the View and ViewModel with data. Let's look at this View and ViewModel.

View

View is just a view (a xaml + codebehind class) and nothing more. It shouldn't keep any state or implement any logic operations except ones that relates to rendering.

VM doesn't "know" the view class and "speaks" with it through the IView interface. As I've mentioned earlier VM doesn't let you to switch UI framework without code review as ViewModel is tightly coupled with WPF-specific entities (such as commands), so for simplicity's sake I've promoted a IWPFView interface that consists of WPF-specific properties and events.



ViewModel

And at last main trinity's player. This class keeps all view related logic and state. My base VM class is parameterized vith view interface and it's descendant is parameterized with DM interface. Using CAB's IoC-container I resolve all of VM dependencies and inject it (VM) into View.


This classes have a bunch of useful virtual methods that are fired when View/DataModel set/unset events happen, in DataModel Loaded/ExceptionCatched events and View's Loaded/Unloaded. In a base class VM sets itself to a view's DataContext property, thus enabling it to update itself by DM, business objects and VM change events catching in databinding. So, speaking in Martin Fowler's words view in WPF is an ActiveView.

You can also find an ActionsViewModel on the diagram above. This class keeps a CommandModel objects list (very useful approach to wrap wpf command from Dan Crevier). For every command VM creates a command binding in a view automaticly.

ViewModel doesn't prohibit you from editing business object supplied by DM in UI and doesn't makes any validations of unedrlying data. So to avoid errors of this kind all of my objects are being edited in wizard UI (I've written a custom WPF control for it. I'll propably write about it later) that tracks object state and avoids saving invalid objects. But if you want to edit objects in your UI in a simple way you propably should read this article from Pete W.

That is all on View and ViewModel. In next part I'll assemble a simple example and (as I promised before) I'll include a sample code.

Good luck!

DataModel-View-ViewModel in WPF. Part 1 DataModel.

All of my UIs are built on very powerful pattern called DataModel-View-ViewModel (DM-V-VM) that was first described by Dan Crevier. I've written a small "framework" (I better say set of classes) to enhance it to my needs.


We have chosen a WPF UI framework in conjuction with the Composite Application Block (CAB) and SmartClient Software Factory (SCSF) to be the foundation of the presentation layer for the project. CAB stimulates and actively using another two UI patterns Model-View-Controller (M-V-C) and Model-View-Presenter (M-V-P). So my set of classes is an extension to an existing infrastracture that uses some of the built-in CAB functionality, especialy IoC-container to resolve dependencies of my classes.

DM-V-VM pattern is a special case of another more brief UI pattern - M-V-P. Martin Fowler calls it the PresentationModel. There is one problem with this pattern - it is fantastic in WPF, but you won't be able to switch to another UI technology without rewriting some code (you can read some on this in Dr.WPF blog). And if it is an evil you can live with than this pattern will be the best choice. And may be it will become too complex to maintain your code when you will have more then 5 data sources. In this case I would recomend you to switch to the M-V-P pattern.

So let's go on.

DataModel(DM)

Classes that provide data (business objects). Their duty is to provide data in WPF-friendly way (at least to implement INotifyPropertyChanged). All the properties and some of methods should only be accessed from UI thread, and it is strongly recommended not to block the UI thread for long.

I think that DM classes (as they were described by Dan Crevier) perfectly fits SOA way of programming, being a data gateway from services to UI.

But services are not the only possible source of data, it can be anything - a file in a file system, for example. To make DM classes lossely-coupled with this different data sources there are providers system that is delegated to obtain data (a strategy by GoF).

A foundation for my DM classes is the Dan Crevier's implementation of DM-V-VM pattern so I shall concentrate on my enhancments instead of rewriting code here.

1. The first thing to come is the base interface for DM classes with the couple of inherited generic interfaces that are narrows (or should I say precises) DM functionality by restricting Entity and Provider types.
   
2. The second thing is the typed provider interface.



3. Base DM class is the third thing. It contains a bunch of asyncronous methods (load complete notification, exception catched notification, etc.) plus a set of virtual methods to be overriden in descendant classes.
   

Invention of generic provider enabled me to write generic DM class that is parameterized with an entity type and typed provider (typed by entity type). I've called it SingleEntityModel. This class frees you from writing lots of DM descendants with the only duty to provide some Entity.

All the clients work with the DM objects through their interfaces as they are treated as a local services and can be injected in dependent code by an IoC-container.

That is all on DataModel, check for new parts.

Good luck!

PS: I will include code in a later parts.

Making objects "UI'ish".

I'm here again to describe another challenge that I've come across (and successfully solved).

This challenge came up from the fact that my project used some functionality of another parallel project (let me call it “parental project”), which was built on .Net 2.0. Nobody thought of implementing objects in WPF-friendly way of course, why should they? So here is the point - I've got a bunch of classes that I want to render and edit in WPF UI. I want to use data binding. I want to write in elegant way Paul Stovel calls Binding Oriented Programming (here and here). I don't want to write wrappers or inherit from that objects (let’s call them “raw”) every time I come across this case.

And then I've recalled a little hook rock-star Josh Smith found to refresh UI. It is described here. Thiss code solved one huge problem – lack of refresh when you bind your UI to the whole object (in spite of it was implementing INotifyPropertyChanged (INPC) interface). So I've taken that solution and expanded it a little to fit my needs.

The essence of that hook is substitution of wrapper object in place of an expected one. This wrapper raises PropertyChanged event every time UI tries to edit some property and renew itself (the wrapper) forcing UI to refresh. This wrapper is injected in UI via binding converter.

In my case there can be no INPC implementation in an object. Idea, described above, plus the generic type argument are my enhancements to Josh Smith's BuisnessObjectHolder (ObservableObjectWrapper in my version):


This class is a descendant of base class implementing INPC - ObservableObject, that was described by Josh here.

There are 2 internal methods - SetValueProperty и GetValueProperty. They are used by binding converter... later on.

Wrapper accepts a wrapping object in constructor or in Value setter. Then it gets property descriptors list by means of type descriptor and caches them. And it subscribes to a PropertyChanged event in there is one.

So now it is time to describe binding converter that substitutes our wrapper in UI or wrapped object property values, that can be obtained by name in ConverterParameter.

Converter works in the following way:

• In a forward process (binding source => binding target) it checks if there is a created wrapper for an object (BindingSource) and in case wrapper is not exist yet it creates a new one. It returns the value in UI depending on received parameter: ConverterParameter = null - wrapper; ConverterParameter = propertyName - a value of the property of wrapped object with name = propertyName, by means of GetValueProperty() method from wrapper;





• In backward process (binding target => binding source) it checks ConverterParameter value and if it is not null calls SetValueProperty() method in wrapper with ConverterParameter and value, recieved from UI, as method parameters.

UI is forced to refresh by the Value_PropertyChanged method (that raises PropertyChanged on the whole object), that is triggered by SetValueProperty() method.



Please note, that first we need to set wrapped object to null and restore it after the first call to SendPropertyChanged. It is necessary to force WPF binding engine to refresh as every time it gets PropertyChanged notification it checks the values and rejects update if it finds them equal.

And now when solution is almost ready one little question comes up - how do I create my generic converter without code-behind in Xaml? And again it struck to me that the guru already wrote about it - Mike Hilberg's post on limited generics support in Xaml. The essence of this approach is to use markup extension to create generic types in Xaml. Here is a slightly modified code of main markup's method:



And at last whole scenario assembled one:



One of disadvantages is you can't reference to this converter from StaticResource anywhere except StaticResource in Style in resources. Otherwise you will have to create this converter every time you use it in every binding.

PS: another approach was demonstrated by Paul Stovell. It uses custom typedescriptor and wrapper that can simulate fake properties and interfaces. This approach is useful not only in WPF but in other frameworks too! Here is the original article - http://www.paulstovell.net/blog/index.php/runtime-ui-binding-behavior-ieditableobject-adapter/

must read.

Good luck!

Xaml Viewer

Here I am again trying to translate my thoughts.

In my previous post I've mentioned the complex case in localization caused by the WPF document API formatted text in TextBlock. For example:






-, that in Russian looks like this:






There is no possibilities to use markup extension in document objects (such as Run or Bold etc.), because it will raise exceptions in XamlParser. The reason is simple - these document objects are not parts of a visual tree. Therefore I need another way to localize and render this text, so I've decided to write custom control for rendering loose-xaml in run-time and keep this localizable xaml same way as I keep string resources - in resx file and obtain them with the CultureResource markup extension.

Well, there is absolutely nothing complex in this control, and I am mentioning it only in the scope of localizing formatted text scenario.

It works in the following way:

• control has 2 states: Host (this is our case - static rendering of bounded xaml) and Edit (in this state you can edit xaml and see render output changes in runtime, there will be an edit box in the upper half for xaml editing);
• it has a string property Xaml;
• control parses xaml (by means of XamlReader) and render it in its Content property;
• Content is binded to internal control part - ScrollViewer, so in case your render output is bigger then the control area, you'll see a scrollbar;

The edit mode control template:



The Host mode control template:

In case of exceptions in xaml parsing process (the most propable is XamlParseException) control will catch them and show the exception message in its content area. This process is governed by a trigger in default style.

The error content style:



This is the way Xaml looks in the resources table:



And this is the way our scenario looks like an assembled one:



Disadvantage is lack of xaml formating (since it is just a string property, it can be nonformatted xml - very annoying!).

Good luck!

Safe event pattern

I've found this useful little pattern browsing the code of the latest Prism drop.
It looks like this:

public event EventHandler Updated = delegate { };

I've never declared events in my code this way. But using this little pattern you can forget about the tedious safety event raising checks and write like in the following line of code:

Updated(null, new AccountPositionEventArgs());

instead of:

EventHandler handler = Updated;
if (handler != null)
handler(null, new AccountPositionEventArgs());

I'll remember this great stuff.

Good luck!