MVVM Fabric: Using TriggerAction

A few days ago, I wrote about using MVVM Fabric’s ActionCommand.  Commanding can be useful with controls that provide a Command property, such as Buttons and MenuItems.  However, commanding doesn’t help when you want to wire up arbitrary events to your view model.  That is where TriggerAction come in.

Overview

TriggerAction is a look-less framework element that wires itself up to whatever event you specify on whatever control you specify.  When that event is raised, TriggerAction calls whatever method you specify on your view model.

TriggerAction was written by Rocky Lhotka for his business object framework, CSLA .NET.  Since CSLA is open source, Rocky gave me permission to include TriggerAction with MVVM Fabric because of the great value it would provide consumers of the library.  I have been using a precursor of TriggerAction, called InvokeMethod, on my projects with great success.  While InvokeMethod has some limitations (no designer support and the ability to only wire one event for a control), TriggerAction provides a more robust implementation and eliminates these issues.

Wiring an event to a method

There’s really two different ways that I typically use TriggerAction.  The first way is when I really only care if an event happened.

For this example, we will wire up TriggerAction to call the Close method on our view model when a button is clicked.  We first need to name the button that we will be hooking events from.

Next we place the TriggerAction on our view.

Notice that I used an Element Binding for the TargetControl property.  That is how we tell TriggerAction to listen for the click event on our button.  I also set the MethodName property with the name of the method we want called.  It is important to note that TriggerAction looks for the method specified on its DataContext.  So, you have to make sure that the DataContext is your view model if you want it to call methods on your view model.

Now we need to write the Close method on our view model.

We’re all set.  When the Click event is raised on our button, TriggerAction will look for a method called Close on its DataContext (which is our view model).  The method it looks for must have 0 or 2 arguments.  We have the 0 argument version here because we only care that the event happened.

Wiring an event to a method with a MethodParameter

The second way I typically use TriggerAction is for those situations where I need to pass a parameter to my method when the event I care about is raised.

For this example (and the one you will see in the sample application), we will wire up the MouseDoubleClick event on a ListView to pass the SelectedItem back to our method on the view model.

First, the ListView.

 

Next, the TriggerAction.

 

There are two things different about our usage of TriggerAction here.  The first difference is the addition of the MethodParameter property, which we are binding to the SelectedItem property on the MoviesList element.  The second is setting RebindParameterDynamically to true.

The MethodParameter property on TriggerAction is where you bind whatever you want from the view to be passed back your view model.  This can be something on the element you are listening for events on or something somewhere else on the view.

The RebindParameterDynamically property is really cool.  When this is set to true, TriggerAction will go out and rebind to the method parameter before calling back to your method so that you are always sending back the latest and greatest.  Since not all of the properties you want to bind to raise property changed events, this is a huge benefit.

Now, on to the view model.  As I mentioned before, when looking for methods on our view model, TriggerAction will look for methods with either 0 or 2 parameters.  Since we need that MethodParameter passed in, we will need the 2 parameter version.

 

This is a typical event handler method signature.  The event args that are passed through are ExecuteEventArgs, which have some useful properties.  The property we care about right now is the MethodParameter property, which needs to be cast before we use it because it is of type Object.  Once we cast it as our Movie business object, the view model is free to do what it needs with it.

Conclusion

Although commanding is a decent start to executing methods on your view model, TriggerAction is a much more robust solution.  With drag-and-drop designer support, the ability to bind a method parameter and the ability to have that method parameter dynamically updated at execution time, TriggerAction is an extremely powerful way to wire arbitrary events from your view to your view model.

MVVM Fabric: Using ModalViewPlacer

In yesterday’s post, I talked about how to do testable navigation with MVVM Fabric.  In that post I made mention of ModalViewPlacer as a stock implementation for IViewPlacer provided by MVVM Fabric.  I think ModalViewPlacer is worth explaining so that you can make effective use of it.

Overview

ModalViewPlacer is an implementation for IViewPlacer which displays views as a modal dialog.  It works with two interfaces provided by MVVM Fabric: IModalView and IModalViewModel.

IModalView must be implemented by the view and provides some hooks for ModalViewPlacer to do its thing.  MVVM Fabric provides an implementation of IModalView, called ModalView, to simplify things.  ModalView inherits from Window.  I will show how to use this shortly.

IModalViewModel must be implemented by the view model and provides a hook for view models to request that they be closed.  MVVM Fabric also provides an implementation of IModalViewModel, called ModalViewModelBase.  ModalViewModelBase inherits from ViewModelBase and provides implementations for the hooks.

When a modal view is shown, its view model needs a way to be able to request the view be closed.  IModalViewModel provides an event, RequestClose, which can be raised.  The view subscribes to that event and closes itself when the event is raised.  ModalViewModel provides several methods which can be used to initiate that close request.  The methods also provide the ability for the view model to indicate whether it was accepted (or cancelled) and give back some sort of result object.  ModalView then takes what was provided by the view model and exposes them as properties to be used by ModalViewPlacer.  ModalViewPlacer will use those properties to create a new message, called ModalViewClosedMessage, and publish it to the message bus to signal to the application that the view was closed.

Using ModalViewPlacer

The sample application provided with MVVM Fabric uses ModalViewPlacer in conjunction with its own custom implementation of IViewPlacer to have a combination of tabbed views and modal views.  This example will be more simple and will only leverage ModalViewPlacer.

First off, you need to have your view inherit from ModalView.

Next, you need to update your XAML to reflect this.

Notice that Window is replaced by nav:ModalView, with nav being the namespace I defined for MVVM Fabric.

Next you need to have your view model inherit from ModalViewModelBase.

Your view and view model are all set now.  You can have methods on your view model such as Accept and Cancel to react to the OK and Cancel buttons.

This illustrates two uses of the NotifyCloseRequest method provided by ModalViewModelBase.  The Accept method signals that the view was accepted and returns Keywords as a result.  Cancel signals that the view was not accepted (read cancelled).

To wire up and request a modal view is no different than I described in yesterday’s post. unless you care about the modal view being closed and possibly the results it provided.  If that is the case, then you must subscribe to the ModalViewClosedMessage from the message bus prior to making the request for the view.

With the ModalViewClosedMessage, you can determine which view just closed and act according to whether the view was accepted and optionally use the result.

Conclusion

Modal dialogs are a type of view that you don’t want to overuse in modern applications, but there usually is a need for at least a few of them.  Using the ModalViewPlacer, you can tap into the navigation functionality provided by MVVM Fabric and still show modal dialogs in a testable way.

Testable Navigation with MVVM Fabric

One of the biggest problems I encountered while writing WPF apps with MVVM is navigation.  The traditional approach to navigation would be to have one view create the view being navigated to.  Now, there’s a couple of issues with that approach which make it less than desirable.  The first issue is that having one view create another view heavily couples the two views.  The second issue is that this approach quickly becomes very difficult (if not impossible) to unit test.

Things get more complicated when view models are introduced.  Since the functionality that initiates the navigation is going to be in the view model, that would mean the view model would have to know about the new view.  When I structure an MVVM solution for WPF, I create a separate class library for the view models.  The client project (which contains the views) needs to have a reference to the view models project in order to use them.  That means there would be a circular dependency if the view model project had a reference to the view project as well.  Doing the traditional approach with this project structure is no longer even an option.

MVVM Fabric solves the navigation problem with some convention, some configuration, a pinch of dependency injection and a dash of the message bus.

10,000 ft View

MVVM Fabric funnels all navigation through one source, the ViewController.  The ViewController subscribes to the message bus to listen for ShowViewMessages requesting views.  When a view request comes through, the ViewController coordinates the resolution and creation of the view and its view model.  Then the ViewController takes the new view and passes it along to the view placer to be placed in the application.

By leaning on the message bus to request a view, writing unit tests for the view model making the request becomes a breeze.  By letting all navigation flow through the ViewController, it de-clutters your codebase by eliminating the need for code creating views throughout the application.  This decoupling will greatly simplify your application and each view model can focus on its own responsibilities and not have to worry about the specifics of any other view or view model.

Convention

As I mentioned, there is an element of convention required to leverage the navigation model provided by MVVM Fabric.  The conventions are as follows:

  1. All view models must have a default constructor.
  2. View models have the option of providing a Load method as a way of allowing itself to be loaded during the dynamic creation process provided by MVVM Fabric.  The Load method may take 0 or 1 arguments.
    1. If there is an argument, it can be whatever is required by the view model to load itself.
    2. If more than one thing is required to load the view model, I recommend creating some sort of criteria class that contains any required data.
  3. A class inheriting from ViewTargets must be provided with unique definitions for all navigable views in the application.

The reason that all view models must have a default constructor is that they are dynamically instantiated when a view is loaded.  Since there are many scenarios where a view model will need some information to load itself (picture a detail view, for example), MVVM Fabric looks for a public Load method on the view model and calls it if found.  That Load method may be a no argument method which simply kick-starts the loading needed for the view model or it may take a single parameter.  If the Load method takes a parameter, a parameter must be provided when the view is requested.  That’s where the ShowViewMessage comes into play.

The ShowViewMessage has a ViewTargets parameter (which tells the ViewController which view is being requested) and an optional parameter called LoadArgs.  LoadArgs can be anything required by the view model, but if something is provided a Load method which takes that object type as a parameter must exist on the view model or an exception will be thrown.

If you saw my presentation WPF with MVVM: From the Trenches, you heard me talking about how ViewTargets is an enumeration.  While refactoring my navigation code into a stand-alone library for MVVM Fabric, one of the issues I had to overcome is the fact that enumerations cannot be inherited from and extended from an external object.  The reason I liked using an enumeration to articulate all the navigable views in the first place is because it provided a level of safety at compile time when views are requested.  I could have used strings instead to identify views, but that would not make refactoring easy.  To overcome this limitation of enums, I leveraged a concept introduced by Hugh Ang to create an Enumeration class which acts like an enum, but can be extended.  It’s not a perfect solution, but it does help address the compile-time and refactoring issues.  The new ViewTargets inherits from this Enumeration class and must be further inherited from in your implementation.

Configuration

In order to leverage the navigation model provided by MVVM Fabric, you must provide implementations to an interface or two: IViewPlacer and optionally IViewAuthorizer.

IViewPlacer is what will actually place the views when the navigation model has loaded the view and it’s view model.  I leave that implementation up to you because each application is different in how views are presented.  The sample application provides an implementation that works with the tabbed interface used by Movies.  MVVM Fabric does contain an implementation of IViewPlacer for views displayed as modal dialogs because this will likely be the same across applications.  The sample application shows the usage of ModalViewPlacer in conjunction with it’s custom IViewPlacer to illustrate how you could implement a combination of the two.

IViewAuthorizer is an interface which can optionally be implemented to give you control over whether the user is authorized to see each view before it is shown.  This allows you to put restrictions on your views from one location.

Enough talk, time for code!

Here’s the part you are probably waiting for, how do I make it work?  Here are the steps that you need to take to get up and running.

1.  Inherit from ViewTargets and provide values for your views.

2.   Provide an implementation for IViewPlacer (unless you strictly use ModalViewPlacer)

Note: Your custom ViewPlacer would also be a good place to subscribe to CloseViewMessages from the message bus.  Since views have the ability to request that they be closed, it only makes sense to keep the showing and closing functionality in the same place.  You can see this in action with the sample application.

3.  Provide a way to wire up the IViewConfigurationResolver when the application starts up.

Note: The sample application calls ContainerConfiguration.InitContainer() in the application’s OnStartup method.  I also do some configuration for Windsor Container in this method.

4 (Optional).  Provide an implementation for IViewAuthorizer.  This one is up to you since application security varies on a case-by-case basis.

5.  Instantiate the ViewController and all the pieces it needs.  This will probably be done in the code-behind of your main window.  The sample application uses Castle Windsor, so I will leave it up to you how you get all the pieces standing.

You’re There!

The steps described above may seem like a lot of work, but the work is almost all front-loaded.  When a new view is added, only steps 1 and 3 must be revised to accommodate the new view.

Now, let’s look at how to initiate navigation.

That’s it!  This example shows how to pass a parameter to the Detail view.  You could remove the LoadArgs parameter from the ShowViewMessage for those cases where there is either no need for a Load method on the view model or the Load method has no parameters.

From a testing perspective, the above example is extremely simple to write unit tests for.  You would simply assert that the message bus received a ShowViewMessage with the correct arguments.

Conclusion

The navigation model provided by MVVM Fabric takes a pain point with the MVVM pattern and smooths it over in a testable manner.  With all the navigation being handled in one place, it reduces the surface area that you must test for in your application.  A testable application is a maintainable application!

MVVM Fabric: Using MessageBus

While working with MVVM and trying to keep clean separation of view models, it becomes clear that there is a need for some sort of communication mechanism to allow view models to interact with each other without knowing about each other.  A message bus works perfectly to fit this need.

Message Bus Overview

The message bus acts as a communication switchboard for your application.  All messages route through the message bus and the message bus gets them to any interested parties.

The message bus is an example of the publisher/subscriber pattern, similar to events in .NET.  However, events require at least one object to know about the other in order to subscribe to the event.  With the message bus, objects only need to know about the message bus to subscribe to or publish messages.  All messages go through a single instance of the message bus and that single instance must be available throughout the application or the pattern quickly breaks down.

With the message bus, there is no longer the need to bubble events from one object to the next, eventually getting them to an object that cares.  Objects subscribe to specific message types.  When that type of message is published through the message bus, the message bus passes the message along to any subscribers.  If there are no subscribers, the message quietly goes away.

A message is simply a class.  It can be an empty class, which acts more as a signal, or a sort of data transfer object, which contains relevant information.  The message bus doesn’t care what the message is, but it does care about the message’s type.  The message’s type is how the message bus knows who is subscribed.

A while back I wrote a post describing how to develop a simple message bus.  The message bus I wrote for MVVM Fabric uses the same interface I described in that post, but has a more robust implementation.  More specifically, I added thread-safety and the use of WeakReferences so that it doesn’t promote memory leaks.  The message bus provides a clean interface which can be used to send and receive messages throughout the application.  Let’s take a look at an example.

Message Bus In Action

First of all, here is a simple example of a message.

Notice that the message doesn’t derive from anything (though it very well could).  In this case, I am using the message to pass keywords used for a search.  Next up is the class which will publish the message.

I only included the important parts for brevity. Notice that we will be using the IMessageBus interface, so that this can be mocked out in testing.  The Search method creates a new instance of the SearchMessage and calls Publish on the message bus passing the message as a parameter and using the message’s type as the generic argument.

To make sure that the message doesn’t fall on deaf ears, we need a subscriber.

Notice the method called HandleSearch, which takes a SearchMessage as a parameter.  The constructor subscribes the HandleSearch method to messages of type SearchMessage and is all ready to search.

Conclusion

The message bus is something that I have used frequently in my travels with WPF and MVVM to keep my view models decoupled.  It provides a simple way to provide fire and forget functionality in a testable manner.  Using the message bus in your application will allow you to keep your view models nicely de-coupled.

MVVM Fabric: Using ActionCommand

The first thing I am going to discuss in my series describing my new WPF library, MVVM Fabric, is ActionCommand.  ActionCommand is an implementation of the ICommand interface.  The ICommand interface is interesting because it can be used in WPF and Silverlight as a way to route certain events (such as clicks) from the view to the view model.

Now, there’s nothing stopping you from doing custom implementations of the ICommand interface for every command your application needs.  I found that to be overkill, however, because in every case I just wanted to turn around and call some method when the command was executed.  Enter ActionCommand.

ActionCommand provides a way to create commands that will call methods on your view model when executed.  MVVM Fabric provides two flavors of ActionCommand, a plain one and a generic one.

Plain ActionCommand

The plain ActionCommand is great for those situations where you just want to execute some method on your view model and have no need for a parameter.  It’s usage is quite simple.

The above example has a method called Save which needs to be called from the view.  So, an ICommand property, called SaveCommand, is exposed on the view model.  In the view model’s constructor, SaveCommand is instantiated with an instance of ActionCommand.  The plain ActionCommand takes a plain Action as its parameter.  A plain Action is a method that has no parameters and a void return type.

To leverage this command, we need to wire up something like a Button to it.  With our view model already defined as the DataContext, the following XAML will do that for us.

Now, when the button is clicked our Save method will be executed on the view model.

Generic ActionCommand

The generic flavor of ActionCommand is useful for those situations where you want to execute some method but also need a parameter to be passed in.  WPF allows you to bind a CommandParameter along with the Command.  The generic part of the generic ActionCommand defines what type that CommandParameter is.  The usage is a little more complicated than the plain ActionCommand, but not by much.

As you can see, the generic ActionCommand uses an Action which takes a parameter type as defined by the generic parameter.  The view side looks a little different too.

Notice that we now have a binding set up on the CommandParameter property.  That binding tells WPF what to pass to the Command as a parameter, which ultimately ends up passed to the SelectMovie method. 

NOTE: If you are looking at the sample application included with MVVM Fabric, you’ll notice that the binding expression I am referencing is more complex.  That is due to the fact that the binding occurs in a DataTemplate, which has a Movie as it’s DataContext, the the MovieCommand lives on the view model.  I used some binding-fu to bind to two different DataContexts.

Conclusion

So, there we have it.  Commanding is not the ultimate solution to wiring events from the view to the view model, but it does work well for some cases.  When commanding applies, ActionCommand is a clean and simple way to leverage it.

Introducing MVVM Fabric

I’ve been working with MVVM on WPF applications for well over a year now on two major projects.  As the UI architect for both projects, I was the guy who had to figure out how to make things work in a way that was extensible and testable.  With each WPF project I did that leveraged MVVM, I found there were common problems that needed to be solved.  These common problems include communication between views, decoupled/testable navigation between views and commanding.  To solve these problems, I initially developed a solution and refactored as needed to fit the different scenarios I encountered.

After spending over a year with the solution, I feel that it stabilized well enough to be confident that I had the foundation for a more general purpose solution.   I have taken what I did on both projects and what I learned from them while doing it and created a library that I am calling MVVM Fabric.  The (mostly selfish) goal with MVVM Fabric was to create an MVVM library that I could weave into other projects with minimal effort.

The real trick was taking what I had integrated into my most recent project and extracting it in such a way that I could turn it into a library and keep it usable.

What is MVVM Fabric?

MVVM Fabric is the result of that exercise.  It is a WPF-centric library, written in C# 4.0, which helps address communication, navigation and commanding in an application leveraging MVVM.  It provides core functionality and leverages dependency injection to provide extensibility.

I have posted the library along with a sample application which uses it out on github: https://github.com/brentedwards/MvvmFabric.

If you have attended my presentation WPF with MVVM: From the Trenches or looked at the presentation materials, you will likely notice many similarities.  That presentation and the resulting sample application were both based on the same projects as MVVM Fabric.  So, I refactored that sample application to eat my own dog food and work out some kinks.  The result is something that I am happy with, though will likely be further extended as I (or you) see fit.

I plan to write several blog posts to provide a more in-depth introduction and explanation of the library (and reasons behind the decisions I made) in coming days.

Growing Pains

I recently moved my blog to a new domain. After messing around a bit to get it formatted to my liking, I announced the new location of my blog. At that point, my web host promptly gave up and let my site fall on its face. After numerous e-mails without a single response or any effort on my web host’s behalf to get things back up and running again, I have moved to a new host.

I have some work left to do to get my new blog at my new site formatted to my liking, but at least it is up and running again. I will get it formatted over the next few days, I hope. And I really do have some ideas for new blog posts. Time is at a premium for me right now, so I just need to wrap some things up before I can part with some time to get some writing done.

If you are still reading this, thank you for your patience!

WPF with MVVM: From the Trenches Presentation Materials – Updated

If you have heard my presentation, I hope that you found it useful. To give you a chance to review, here are the presentation materials I used.

Slides: http://www.slideshare.net/brentledwards/wpf-with-mvvm-from-the-trenches
Code: http://github.com/brentedwards/Movies

If you have seen my presentation, I would really appreciate some feedback.

Chippewa Valley Code Camp 2010

Roll Your Own Simple Message Bus / Event Aggregator

I was recently working on a project that had a need for some sort of centralized messaging system.  After doing some research into the matter, I decided to move forward with the Event Aggregator from the Prism team.  Prism’s Event Aggregator worked fine, but there were a few things about it that I found cumbersome.  While preparing for a presentation I gave recently, called “WPF with MVVM: From the Trenches,” I began to think about what it would take to create my own event aggregator that would smooth over some of the bumps.

First up, lets talk about the name, “Event Aggregator.”  During the course of our project, we used the event aggregator to publish data (or messages) in addition to events.  During a discussion about the event aggregator, Jason Bock pointed out that it is really more of a “Message Bus” than an “Event Aggregator.”  I agree.  So, for the remainder of this post, I will refer to it as a “Message Bus.”

The next bump that I wanted to smooth over was the fact that, with Prism, we had to create both an Event class which derived from CompositePresentationEvent and an EventArgs class for every message we wanted to publish.  With Prism, I wrote an extension method, called GetEventViaArgs(), which would get the CompositePresentationEvent based on the type of the args.  That eliminated the need for an explicit Event class, but that also made me question the need for an Event at all.  What if the message type was all that we needed for subscribing and publishing?  Eliminating the need for an Event would simplify testing as well because we wouldn’t have to mock out both getting the event and subscribing/publishing the message, which so happens to be another bump that I wanted to smooth over.

A Starting Point

So, lets take a look at the method signatures that I had in mind.  A Message Bus should provide functionality to Subscribe to a message, Unsubscribe from a message and Publish a message.

This looks straight-forward enough.  Whatever implementation I come up with, it should leverage generics to make sure all interested parties are notified of messages they care about.  The method signature I would like to see for the callbacks would be something like this:

Since I am a big fan of dependency injection and inversion of control, I wanted to define an interface, called IMessageBus, to be used instead of a concrete implementation.  Keeping in mind how I wanted to use this bad boy, here is the interface I came up with:

Let me break this down a bit…  TMessage is the Type of the message to be sent.  Action is a way for me to take, as a parameter, a method which has a void return value and takes a parameter of type TMessage.  Also note that TMessage is just a class that contains whatever data we need to convey the message.

So far, so good.  We now have a contract in place for our message bus.  Next up is implementation.

Making It Happen

First, we need a data structure that will have some sort of key/value association.  The key will be the Type of TMessage and the value will be the collection of Action which will be called when a message of type TMessage is published.  Since I plan to use generics at the method level, I decided to use Object in place of Action, then cast it before using it.  So, here is our MessageBus class so far:

Now that we have a data structure in place to keep track of subscribers, time to implement the Subscribe method.  Now, when a new subscriber is added, we need to first find out if there is already a subscriber list for that message type.  If there is, use it.  Otherwise, create a new one.

Next up is Unsubscribe.  When a subscriber makes a call to Unsubscribe, we need to make sure they are actually a subscriber in the first place and remove them if they are.  Also, if they are the last subscriber, we can go ahead and remove the subscriber list for that message type.

Almost there.  Now we just need to be able to Publish.  As you probably noticed above, I thought it would be nice to both explicitly define what type of message to publish and let the message type be determined dynamically.  For either case, we need to get the list of subscribers for the type of message being published and invoke each of their callback methods with the message as a parameter.  First up is the explicitly define flavor:

Pretty straight-forward here too.  If there are subscribers for that message type, iterate over them (casting them in the process) and invoke them.

The dynamic version of Publish is a little more involved, only because we have to use reflection in place of generics due to the dynamic aspect:

This one is essentially doing the same thing as the other Publish method.  If there are subscribers for that message type, iterate over them (finding their Invoke method in the process) and invoke them.  Don’t be confused by the two different Invokes that you see…  The first Invoke is the name of the method on the Action type and the second Invoke is what reflection uses to execute a method.

There we have it!  A simple message bus that is easy to use.  But how about testing with it?  Since testing was one of the bumps I wanted to smooth over, how did we do?  Let’s find out!

Testing Our Shiny New Message Bus

I use RhinoMocks, so here is how I would verify that some code is publishing the correct message:

I generate a stub for IMessageBus which will set my local searchMessage variable to the actual SearchMessage that is published.  I then could use searchMessage to verify that the message that is published has the correct data.

As an alternative, if all I wanted to do was verify that Publish was called on my Message Bus, I could do the following:

The key changes here are that I am using a Mock instead of a Stub and I am setting up an expectation.  That way I can verify that Publish was called without caring about the details:

Testing for messages being published is now much cleaner with our new MessageBus than it would be with Prism’s Event Aggregator.  But what about testing the handling of these messages that get published?  Well, the best way that I could come up with for that is the same way I did it with Prism’s Event Aggregator, which is to use the concrete implementation of the MessageBus and actually subscribe and publish with it in the unit test.  Oh well, at least we were able to clean up some of the testing aspect!

Conclusion

So, here we are at the end.  My goal here was to show that it isn’t all that difficult to implement your own message bus system or, at the very least, show the general concept behind how it works.  I hope that this has been useful.  If you want play with the code that we have written, as well as the tests that I wrote to beat on it a little, you can download the source here: