As documented here on MSDN the PropertyItem object does not have a public constructor.

What to do then when you want to add a property to an image, using Image.SetPropertyItem(..) method?

This post suggests you create some bank of all property items you want, hold it memory and clone from it.

A commenter on that blog suggested using reflection: Get the non-public parameter-less constructor and invoke it. Notable downside for this approach is reliance on internal implementation of the object. True. I'll risk it though.

In my implementation, I added a helper method which simply generates the PropertyItem using System.Activator like so:

public static PropertyItem CreatePropertyItem(int id, int length, short exifType, byte[] buffer)

{

    var instance = (PropertyItem)Activator.CreateInstance(typeof(PropertyItem), true);

    instance.Id = id;

    instance.Len = length;

    instance.Type = exifType;

    instance.Value = buffer;

    return instance;

}

Pretty clean and simple. Under the covers, Activator will use some reflection to create the instance, but would also utilize some caching and speed written by not-me. I like not-me code because it means I don't have to write it.

Since one of my my upcoming talks at http://socalcodecamp.com is on the subject of reflection, this all falls neatly into place.

In a previous posting, I discussed replacing the stock MVC serializer used for the JsonResult exposed when you use the controller method Json(..) instead of View.

This was all find and dandy. But how – you may wonder – can I call actions that contain complex parameters? Do I need a special binder? Should I write my own?

The answer is mostly "no". As Phil Hack blogged, the ASP.NET MVC framework already contains value providers that take care of that for you. All you need to do is ensure that your Javascript calls your action using some very specific header and mime types.

Here is a function that may help you

   1: <script type="text/javascript">

   2:        var postToAction = function (sender) {

   3:            var json = $('textarea#' + sender.data).val();

   4:            $("textarea#myResponse").val('working...');

   5:             $.ajax({

   6:                 url: document.location.href,

   7:                 type: 'POST',

   8:                 dataType: 'json',

   9:                 data: json,

  10:                 contentType: 'application/json; charset=utf-8',

  11:                 success: function (data) {

  12:                     var replyText = JSON.stringify(data);

  13:                     $("textarea#myResponse").val(replyText);

  14:                 }

  15:             });

  16:         };

  17:     </script>

The special sauce here is the dataType and contentType together with the POST method. The rest is pretty much how jQuery wants to be called.

On line 6 you will note that I'm POSTing to the same URL as the browser is on – you may want to fiddle with that.

We  call this function by hooking up a button, something like:

   1: $("button#myButtonId").click('myTextAreaWithJsonContent', postToAction);

In your own implementation you will no doubt compose some object in JavaScript, or create a Json object. In the code above, I'm simply using Json formatted string: Line 3 gets the value from a text area element. If you compose a complex object and want to send it, you will need to convert it into a Json string. jQuery 1.5.1 – which I happen to use – already contains this facility, JSON.stringify(x) would do the trick. You can see it here used  on line 12, for the inbound response which I simply stringify and hydrate a response text area. But this is only demo code – you will wire up the success (and failure function- right?) to your own logic.

But back to the core issue: Yes, MVC supports submitting Json and hydrating my controller action, but how do I persuade it to use my custom chosen super duper serializer rather than the stock one?

The answer is: Create a custom ValueProviderFactory and instantiate your favorite serializer in there. A bit of inspection on the MVC source code on CodePlex.com reveals the stock implementation.

Here's a modified version, which isolates the serialization in a clear way:

   1: public class MyJsonValueProviderFactory : ValueProviderFactory

   2: {

   3:     public override IValueProvider GetValueProvider(ControllerContext controllerContext)

   4:     {

   5:         if (controllerContext == null)

   6:         {

   7:             throw new ArgumentNullException("controllerContext");

   8:         }

   9:  

  10:         if (!controllerContext.HttpContext.Request.ContentType.StartsWith(

  11:                 "application/json", StringComparison.OrdinalIgnoreCase))

  12:         {

  13:             return null;

  14:         }

  15:  

  16:  

  17:         object value = Deserialize(controllerContext.RequestContext.HttpContext.Request.InputStream);

  18:  

  19:         if (value == null)

  20:         {

  21:             return null;

  22:         }

  23:  

  24:         var bag = new Dictionary<string, object>(StringComparer.OrdinalIgnoreCase);

  25:  

  26:         PopulateBag(bag, string.Empty, value);

  27:  

  28:         return new DictionaryValueProvider<object>(bag, CultureInfo.CurrentCulture);

  29:     }

  30:  

  31:     private static object Deserialize(Stream stream)

  32:     {

  33:         string str = new StreamReader(stream).ReadToEnd();

  34:  

  35:         if (string.IsNullOrEmpty(str))

  36:         {

  37:             return null;

  38:         }

  39:  

  40:         var serializer = new JavaScriptSerializer(new MySpecialTypeResolver());

  41:  

  42:         return serializer.DeserializeObject(str);

  43:     }

  44:  

  45:     private static void PopulateBag(Dictionary<string, object> bag, string prefix, object source)

  46:     {

  47:         var dictionary = source as IDictionary<string, object>;

  48:         if (dictionary != null)

  49:         {

  50:             foreach (var entry in dictionary)

  51:             {

  52:                 PopulateBag(bag, CreatePropertyPrefix(prefix, entry.Key), entry.Value);

  53:             }

  54:         }

  55:         else

  56:         {

  57:             var list = source as IList;

  58:             if (list != null)

  59:             {

  60:                 for (int i = 0; i < list.Count; i++)

  61:                 {

  62:                     PopulateBag(bag, CreateArrayItemPrefix(prefix, i), list[i]);

  63:                 }

  64:             }

  65:             else

  66:             {

  67:                 bag[prefix] = source;

  68:             }

  69:         }

  70:     }

  71:  

  72:     private static string CreatePropertyPrefix(string prefix, string propertyName)

  73:     {

  74:         if (!string.IsNullOrEmpty(prefix))

  75:         {

  76:             return (prefix + "." + propertyName);

  77:         }

  78:         return propertyName;

  79:     }

  80:  

  81:     private static string CreateArrayItemPrefix(string prefix, int index)

  82:     {

  83:         return (prefix + "[" + index.ToString(CultureInfo.InvariantCulture) + "]");

  84:     }

  85: }

It all really boils down to the same ceremony as the default implementation, except on line 40 and 42 we now get to use our own special serializer. Woot!

To use this instead of the built in one, you will modify your global.asax.cs Application_Start() to include something like

   1: var existing = ValueProviderFactories.Factories.FirstOrDefault(f => f is JsonValueProviderFactory);

   2: if (existing != null)

   3: {

   4:     ValueProviderFactories.Factories.Remove(existing);

   5: }

   6: ValueProviderFactories.Factories.Add(new MyJsonValueProviderFactory());

where the built in one gets removed and my custom one gets added. Pretty straightforward.

With this technique and the one described in my previous post, you are ready to use the full power of MVC as an API supporting a nice strongly typed parameter for the back end developer and supporting fully customizable JSON in and out of methods. No real need for other frameworks or technologies for the serving jQuery needs.

Depending on your methods, you may even get away with one set of actions serving both form posts and jQuery invocation.

Happy coding!

Oh, I remember it like it was yesterday: Dot-com, no DBA, late nights, a pale developer walking into my office head hung low and mumbling something about restoring backup because he ran an update query with no where clause.. the good old days.

Zoom forward a decade.

A developer is cranking away on some MongoDB query generation in code. Not wanting to make any rookie mistakes, she uses the Query.EQ builder, which would surely create the correct syntax. Better than her own string.Format() at least!

Or so she thought.

The issue is a small peculiarity with the Query methods. The formal signature takes a string and a BsonValue:

   1: public static QueryComplete EQ(

   2:     string name,

   3:     BsonValue value

   4: )

So a some call path would get to a method which would create the query. Lets say

   1: public string CreateFooQuery(string value)

   2: {

   3:     var query = Query.EQ("Prop1",value);

   4:     return query.ToString();

   5: }

Did you spot the issue? I didn't. She didn't either.

The issue is that the Query.EQ method would boil down a value "xyz" to the MongoDB query {"Prop1":"xyz"} just fine. It would also boil down an empty string "" to the query {"Prop1":""} without flinching. But if you supply null – and yes, strings can be null – then the query becomes {}. Yes, that's right, the null query. Yes, the one that matches EVERY document!

Now take that query as a read query – you got all documents returned. Use it for an update – might as well have some good backup strategy!

Note to self: write more unit tests. Ensure that every code path you visit have been visited before and the expected values are returned.

Sigh!

For various reasons you may find that the default JsonResult returned by invoking the controller method such as

return Json([data);

Is unsuitable for the consumer. The main issue most often encountered is that this method uses the JsonResult which in turn uses the JavaScriptSerializer with no access to the JavaScriptTypeResolver.

This means that you can provide that serializer a parameter specifying you own custom type resolver.

Other issues, such as maximum recursion depth and maximum length and type resolvers can be simply configured in web.config. See  Configuring JSON Serialization section on MSDN.

Back to the core problem though.

To override the JsonResult, we would need to do 2 things:

1) Create our own custom JsonResult implementation

2) Tell the controller to use ours rather than the stock one.

A new JsonResult is needed because the base one hard codes the construction of the JavaScriptSerializer.

So here we go. Some CTRL+C, CTRL+V later from the open source MVC on Codeplex gives us

   1: public class TypedJsonResult : JsonResult

   2: {

   3:     public override void ExecuteResult(ControllerContext context)

   4:     {

   5:         if (context == null)

   6:         {

   7:             throw new ArgumentNullException("context");

   8:         }

   9:  

  10:         if ((JsonRequestBehavior == JsonRequestBehavior.DenyGet)

  11:             && string.Equals(context.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase))

  12:         {

  13:             throw new InvalidOperationException("JsonRequest GetNotAllowed");

  14:         }

  15:  

  16:         var response = context.HttpContext.Response;

  17:  

  18:         response.ContentType = !string.IsNullOrEmpty(ContentType) ? ContentType : "application/json";

  19:  

  20:         if (ContentEncoding != null)

  21:         {

  22:             response.ContentEncoding = ContentEncoding;

  23:         }

  24:  

  25:         if (Data != null)

  26:         {

  27:             var serializer = new JavaScriptSerializer(new BiasedTypeResolver());

  28:             response.Write(serializer.Serialize(Data));

  29:         }

  30:     }

  31: }

You will note on line 27 that we're still using the JavaScriptSerializer, but this time we're controlling its construction and decided to give it our own type resolver. More on that type resolver in a bit.

Next, we want to our controller(s) an easy way to choose our TypedJsonResult rather than the stock one. Luckily, the controller boils down the call Json(data) and several other signatures to a call to a virtual signature which we may simply override, like so:

   1: protected override  JsonResult Json(object data, string contentType, Encoding contentEncoding, JsonRequestBehavior behavior)

   2: {

   3:     return new TypedJsonResult { Data = data, ContentType = contentType, ContentEncoding = contentEncoding, JsonRequestBehavior = behavior };

   4: }

That's it! On line 3 you will notice we return our custom TypedJsonResult, whereas the stock implementation would have returned the JsonResult.

If this new behavior is desired everywhere, then you would probably want to place this override in a base controller of your own, and have all your controllers inherit it.

Other powers this bestows on you is of course using some other serializer altogether, such as Json.NET or whatever you fancy.

Now back to my own type resolver. You could, after all, use the SimpleTypeResolver built into the framework, which works quite well. However, it introduces fairly long type names – frowned upon by my clients consuming this Json on other platforms, and also doesn't enable me to map my own type names to a type of my choice. Enter the BiasedTypeResolver.

   1: private static readonly Dictionary<string, Type> _KnownTypes;

   2:  

   3: static BiasedTypeResolver()

   4: {

   5:     _KnownTypes = new Dictionary<string, Type> ();

   6:     var appDomain = AppDomain.CurrentDomain;

   7:     foreach (var assembly in appDomain.GetAssemblies().Where(a => a.GetName().Name.EndsWith(".ValueObjects")))

   8:     {

   9:         foreach (var type in assembly.GetTypes().Where(t => !t.IsInterface && !t.IsAbstract))

  10:         {

  11:             _KnownTypes[type.Name] = type;

  12:         }

  13:     }

  14: }

  15:  

  16: public override Type ResolveType(string id)

  17: {

  18:     var result = Type.GetType(id);

  19:     if (result != null || _KnownTypes.TryGetValue(id, out result))

  20:     {

  21:         return result;

  22:     }

  23:     throw new ArgumentException("Unable to resolve [" + id + "]", "id");

  24: }

  25:  

  26: public override string ResolveTypeId(Type type)

  27: {

  28:     if (type == null)

  29:     {

  30:         throw new ArgumentNullException("type");

  31:     }

  32:  

  33:     return type.Name;

  34: }

This resolver spelunks specific assemblies only (those named [whatever].ValueObjects which are my naming convention for POCO public objects) and catalogs them into a dictionary by short type name.

It doesn't know how to resolve 2 types of the same name if they only differ by namespace, but then again I'd ask "how come you would define 2 classes of the same exact name in your solution?" You can define type names to whatever suites your needs.

The resolver's responsibility is twofold: Given a string , return the System.Type that corresponds to it. Given a type, return a name for it. The former is used during deserialization, the latter when serializing.

Now you may not need or like this particular type resolver implementation. But now that you can inject your own, possibilities are limitless. These can range to configuration based type resolution, versioning decisions base on some revision upgrades etc.

Note also that upon deserialization, the type resolver is only called when a type discriminator exists in the JSON stream. That is, a complex type that doesn't contain "__type":"foo" will be serialized by the JavaScriptSerializer by matching the target member name rather than the resolver. This is nice because the JSON can contain strategically placed type discriminators for polymorphic reasons on some members, but be left terse and bare otherwise.

Hopefully, this helps you, or me-of-the-future when the gray cells got filled with the next great thing..

Happy Coding!

Often enough we have frameworks do heavy lifting for us. That's usually a good thing. But I always found it kind of sedating to let "the man" provide me with too much comfort. Especially when the framework or other SOUP library fails to perform exactly what you want. That usually leads to some grumpiness followed by some code-acrobatics to punch that square peg into a round hole – often negating the elegance and usefulness of the library call altogether.

One task a framework often performs is binding. Binding – as defined here – is taking an object and assigning values to it's properties from a property bag of sorts. For example, a property bag could be a hash-table or list of name-value pairs and an object would be a POCO (Plain old class object). It's common in web and ORM contexts, also in web services to receive a dictionary of values and have to attach them to your domain model. The plain straightforward way would be to pluck key value pairs one by one by name and assign to your object. But that's no fun and error prone. What we would like is to be able to auto-attach values to the target object.

How do we achieve that? Steve Bearman and I actually presented this very briefly as part of a larger talk on advanced C# at SoCal Code Camp last weekend. A bit of reflection, a bit of generics and extensions, and viola:

   1: public static T Populate<T>(this T target, IEnumerable<KeyValuePair<string, object>> values)

   2: {

   3:     Type targetType = target.GetType();

   4:     foreach (var kvp in values)

   5:     {

   6:         PropertyInfo pi = targetType.GetProperty(kvp.Key);

   7:         pi.SetValue(target, kvp.Value, null);

   8:     }

   9:     return target;

  10: }

The extension method Populate() above takes an IEnumerable of KeyValuePair as a parameter. It then iterates a these pairs and for each key finds a property  by that name and assigns the value from the dictionary to the target object. Reflection comes in at lines 6 and 7. A property is found based on the name alone, and assigned to. Usage of this extension can look something like this:

   1: Dictionary<string, object> assignments = new Dictionary<string, object>();

   2: assignments.Add("Name", "Paris Hilton");

   3: assignments.Add("ID", 42);

   4: assignments.Add("HomePhone", "(310)-555-1212");

   5: assignments.Add("WorkPhone", "(310)-777-FILM");

   6: Person paris = new Person();

   7:  

   8: Person result = paris.Populate(assignments);

Simple, granted. Simplistic perhaps. But let's consider that the average programmer doesn't write much code like this. There can be many bells and whistles added here: A property getter might only assign if the prperty is writable, attempt to match without case sensitivity, only match if property is public or adorned with an attribute. The main thinks is that you can write this method into your solution in very few lines and shape it as you wish. You do not have to depend on default MVC binders or ORMs being open source or anything like that to have binding performed. Further utilizing this bit (!) of code you might create a simple object factory that returns a new populated type from any object given a property bag of values. In fact, let's do this right here:

   1: public static class MyFactory<T>

   2: {

   3:     public static T Create(IEnumerable<KeyValuePair<string, object>> values)

   4:     {

   5:         T result;

   6:         ConstructorInfo ctor = typeof(T).GetConstructor(System.Type.EmptyTypes);

   7:         result = (T)ctor.Invoke(null);

   8:         result.Populate(values);

   9:         return result;

  10:     }

  11: }

The generic factory MyFactory has a Create() method which takes a property bag as a parameter and returns a populated instance with the values provided. The usage of the factory eliminates the need for creating a new empty instance before populating it. Well, actually , it does it so you don't have to – code was not eliminated, just consolidated. The usage then becomes:

   1: Dictionary<string, object> values = new Dictionary<string, object>();

   2: values.Add("Name", "Paris Hilton");

   3: values.Add("ID", 42);

   4: values.Add("HomePhone", "(310)-555-1212");

   5: values.Add("WorkPhone", "(310)-777-FILM");

   6:  

   7: Person actual = MyFactory<Person>.Create(values);

So there we have it folks. Another DIY tidbit that would hopefully help you take control of the common binding task away from framework writers and back into your hands - where it belongs.

In production, you would probably want to also take a look at whether there's a Populate() or TryPopulate() -exception or return boolean -  and handle the whole error pathing in an explicit way that fits your own style of coding. Similarly you should consider whether an unassigned property (missing value in the bag) is cause for error and whether extra unmatched values are cause for error. In this example, an extra value will cause an exception and an unassigned property will not.

Happy Binding!

Sometimes I just write code. And sometimes I clean up my code. Most of the times, I focus on the meat of the methods, hacking away at verbose or lengthy flows, re-factoring out common code, trying to untangle overly complex logic etc.

Recently, I noticed that many of the conditional terms I write span very long lines and are a bit cumbersome to read. The reason for that is that many of the variable names are long, or the properties or both and that often the comparison is on a property of an object or member of a collection etc.

So for instance:

if (summerCatalog.Products[0].ProductCategories[0].ParentCategoryID >= 1 && summerCatalog.Products[0].ProductCategories[0].ParentCategoryID <= 4)
{ 
//...
}

Can become quite long.
Long is not easy to read.
Long is not easy to maintain.
Long is not easy to think through.

What I really wanted to say is if [value] is between [a] and [b].

Of course, one could say "lets just make the variable names shorter". But that flies in the face of self explanatory plain naming. So abbreviating for the sake of short-lineliness (New word! You heard it her first!) is out.

Well, this is just screaming "EXTENSION METHODS" doesn't it?

Here we go then:

/// <summary>
/// Returns whether the value is between the 2 specified boundaries.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="value">The value to compare</param>
/// <param name="minValueInclusive">The min value (inclusive).</param>
/// <param name="maxValueInclusive">The max value (inclusive).</param>
/// <returns>True if the value is equal to or between the boundaries; False otherwise.</returns>
public static bool Between<T>(this T value, T minValueInclusive, T maxValueInclusive) where T : IComparable<T>
{
    if (minValueInclusive.CompareTo(maxValueInclusive) > 0)
    {
        throw new ArgumentException("minimum value must not be greater than maximum value");
    }
    return (value.CompareTo(minValueInclusive) >= 0 && value.CompareTo(maxValueInclusive) <= 0);
}

The Between function takes any object which supports IComparable<T> and performs syntactic sugar comparison with the inclusive min and max values.
What's more, it adds a basic sanity check for the comparison. How many times do I do that sanity check in my normal code (!)?

Now the conditional is

if (summerCatalog.Products[0].ProductCategories[0].ParentCategoryID.Between(1, 4)) 
{
///...
}

At least I don't have to refactor this in my brain while reading.

Sure, you might say, but you could have just de-referenced the deep value and then have a shorter conditional, like so:

Category category = summerCatalog.Products[0].ProductCategories[0];
if (category.ParentCategoryID >= 1 && category.ParentCategoryID <= 4)
{
    //...
}

It's been years now that unit testing frameworks and tools have grabbed our attention, made their way into our favorite IDE and sparked yet another wave of seemingly endless "my framework is better than yours" wars. And then there are the principal wars of whether TDD is better than Test After Development. And most excitingly the automated testing tools etc. Oh, and let's not forget mocks! So we have all the tools we need – right? Well, kind of, no.

I recently attended a talk by Llewellyn Falco and Woody Zuill the other day, and they used a little library called Approval Tests (http://approvaltests.com/). I immediately fell in love with the concept and the price ($0). Llewellyn is one of the two developers of the product, hosted on http://sourceforge.net/projects/approvaltests/.

What does it do that years of frameworks don't?

For me, a major nuisance is that you have a piece of code, and that piece of code produces a result (object, state – call it what you will). That result is commonly named "actual" in Visual Studio unit tests. The developer must then assert against that result to ensure that the code ran properly. In theory, unit tests are supposed to be small and only test one thing. In reality, functions which return complex objects rarely can be asserted with one assert. You'd typically find yourself asserting several properties or testing some behavior of the actual value. In corporate scenario, the unit tests might morph into some degree of integration tests and objects become more complex, requiring a slew of assert.this and assert.that().

What if you could just run the code, inspect the value returned, and – if it satisfies the requirements – set "that value" to be the comparison for all future runs? Wouldn't that be nice? Good news: Approval Tests does just that. So now, instead of writing so many asserts against your returned value, you just call ApprovalTests.Approve() and the captured state is compared against your current runtime. Neat huh?

But wait, there's more! What if your requirements are regarding a windows form, or a control? how do you write a unit test that asserts against a form? The answer is simple and genius: Capture the form as an image, and compare the image produced by your approved form (after you have carefully compared it to the form given to you by marketing – right?) and compare it to each subsequent run. ApprovalTests simply does a byte by byte comparison of the resultant picture of the form and tells you if it matches what you approved.

Let's break down the steps for installation:

1. Add a reference to the ApprovalTests.dll assembly.

Yeah,it's that simple.

Ok. Let's break down the steps for adding an approval to your unit test

1. Write your unit test (arrange, act – no asserts) as usual.
2. Add a call to Approve()

Yeah, it's that simple.

How do you tell it that the value received is "the right one"? Upon first run, the Approve() call will always fail. Why? Because it has no stored approved value to compare the actual it received against. When it fails, it will print out a message (console or test report – depends on your unit test runner). That message will contain a path for the file that it received, complaining about a lack of approved file. The value captured from that run (and any subsequent run) is stored in a file named something like "{your unit test file path}\{your method}.received.xyz". If you like the result of the run -the image matches what the form should look like, or the text value is what your object should contain etc – then you can rename it to "{your unit test file path}\{your method}.approved.xyz". You should check the approved file into your source control. After all, it's content constitutes the basis of the assertion in your unit test!

Consider the very simple unit test code:

   1: [Test]

   2:         public void DateTime_Constructor_YMDSetDate()

   3:         {

   4:             DateTime actual;

   5:             actual = new DateTime(2038, 4, 1);

   6:             Approvals.Approve(actual.ToString());

   7:         }

The function under test here is the constructor for System.DateTime which takes 3 parameters – month day and year. Upon first run, the test will fail with a message resembling

"TestCase 'MyProject.Tests.DateTimeTest.DateTime_Constructor_YMDSetDate'
failed: ApprovalTests.Core.Exceptions.ApprovalMissingException : Failed Approval: Approval File "C:\….\MyProject\DateTimeTest.DateTime_Constructor_YMDSetDate.approved.txt" Not Found."

That's because this file was never created – it's your first run. Using the standard approver, this file will actually now be created but will be empty. In that same directory you will find a file named {…}.received.txt. This is the capture from this run. You can open the received value file, and inspect the text to ensure that the value returned matches your expected value. If it does, simply rename that file to .approved.text or copy it's content over and run the test again. This time, the Approve() method should succeed. If at any point in the future the method under test returns a different value, the approval will fail. If at any point in the future the specs change, you will need to re-capture a correct behavior and save it.

How do you easily compare the values from the last run and the saved approved value? The approved file is going to be a text file for string approvals, and an image file for WinForm approvals. As it turns out, you can instruct Approval Tests to launch a diff program with the 2 files (received, approved) automatically upon failure, or just open the received file upon failure or silently just fail the unit test. To control that behavior, you use a special attribute

   1: [TestFixture]

   2: [UseReporter(typeof(DiffReporter))]

   3: public class ObjectWriterTest

   4: {

The UserReporterAttribute allows you to specify one of 3 included reporters

1. DiffReporter – which opens tortoisediff for diffing the received and approved files if the comparison fails.
2. OpenReceivedFileReporter – which launches the received file using the application registered to it's extension on your system if the comparison fails.
3. QuietReporter – which does not launch any program but only fails the unit test if the comparison fails.

When your have a CI server and run unit tests as part of your builds, you probably want to use the quiet reporter. For interactive sessions, one of the first 2 will probably be more suitable.

How are value comparisons performed? Under the standard built in methods, a file is written out and compared to byte by byte. If you wish to modify this or any behavior, you can implement your own approver or file writer or reporter by implementing simple interfaces. I ended up adding a general use object writer so that I can approve arbitrary objects. The effort was fairly painless and straightforward.

I did have to read the code to get the concept. If only my time machine worked: I could have read my own blog and saved myself 20 minutes. Yeah, right.

The project has some bells and whistles – plug ins for a few IDE's and there's a version for Java and Ruby. I have not reviewed these versions.

There you have it folks- a shiny new tool under your belt. I can see this saving my hours of mindless typing of Assert.* calls and I can go home early. Yeah, right.

As predicted, I came around to using some radio  buttons. As you might guess by now, I didn't like the HTML or the implementation in the current MVC release. As you may expect, I wrote my own :-)

The implementation is fairly simple and straightforward. It extends System.Web.MVC.ViewPage, takes a list of objects, allows for selection of one of the radio buttons, supports orientation and supports selection of both the value the radio button submits and the display string for that item independently.

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq.Expressions;

   4: using System.Web.Mvc;

   5: using System.Web.UI;

   6:  

   7: public static partial class HtmlHelpers

   8: {

   9:     public static void ShowRadioButtonList<T>(this ViewPage page, IList<T> list, string name, Expression<Func<T, object>> valueProperty, Expression<Func<T, object>> displayProperty, System.Web.UI.WebControls.Orientation orientation)

  10:     {

  11:         page.ShowRadioButtonList(list, name, valueProperty, displayProperty, "3", orientation);

  12:     }

  13:  

  14:  

  15:     public static void ShowRadioButtonList<T>(this ViewPage page, IList<T> list, string name, Expression<Func<T, object>> valueProperty, Expression<Func<T, object>> displayProperty, string selectedValue, System.Web.UI.WebControls.Orientation orientation)

  16:     {

  17:         HtmlTextWriter writer = new HtmlTextWriter(page.Response.Output);

  18:         if (writer != null)

  19:         {

  20:             Func<T, object> valueGetter = valueProperty.Compile();

  21:             Func<T, object> displayStringGetter = displayProperty.Compile();

  22:  

  23:             for (int i = 0; i < list.Count; i++)

  24:             {

  25:                 T row = list[i];

  26:                 string value = valueGetter(row).ToString();

  27:                 writer.AddAttribute(HtmlTextWriterAttribute.Type, "radio");

  28:                 writer.AddAttribute(HtmlTextWriterAttribute.Id, name + "_" + i);

  29:                 writer.AddAttribute(HtmlTextWriterAttribute.Name, name, true);

  30:                 writer.AddAttribute(HtmlTextWriterAttribute.Value, value, true);

  31:                 if (value == selectedValue)

  32:                 {

  33:                     writer.AddAttribute(HtmlTextWriterAttribute.Checked,"checked");

  34:                 }

  35:                 writer.RenderBeginTag(HtmlTextWriterTag.Input);

  36:                 writer.Write(displayStringGetter(row));

  37:                 writer.RenderEndTag();

  38:  

  39:                 if (orientation == System.Web.UI.WebControls.Orientation.Vertical)

  40:                 {

  41:                     writer.RenderBeginTag(HtmlTextWriterTag.Br);

  42:                     writer.RenderEndTag();

  43:                 }

  44:             }

  45:         }

  46:     }

  47: }

This implementation uses the type Expression<Func<T,Object>> for the selection of the value and the display string. To invoke the helper, assuming you have a list of Product objects, Product being defined:

   1: public class Product

   2: {

   3:     public int ProductID { get; set; }

   4:     public string Title { get; set; }

   5:     public string Description { get; set; }

   6:     public decimal Price { get; set; }

   7: }

You can now call the helper from your MVC View Page strongly typed with a model List<Product>:

   1: <%@ Page Title="" Language="C#" Inherits="System.Web.Mvc.ViewPage<List<Product>>"

   2:     MasterPageFile="~/Views/Shared/Site.Master" %>

   3:  

invoked simply

   1: <% this.ShowRadioButtonList<Product>(Model, 

   2:                             "productRadioButtonList", 

   3:                             a => a.ProductID, 

   4:                             d => d.Title, "4", 

   5:                             Orientation.Horizontal); %>

This call will create a radio button for each product in the list (Model is a List<Product> because we strongly typed the page as such). The radio button will use the ProductID property for the value of the input, and the Title property as the displayed string. If one of the product Id's happens to be 4, that radio button will be selected in the group. The radio buttons will all be named "productRadioButtonList" but their ID will be appended an ordinal number  "productRadioButtonList_1","productRadioButtonList_2","productRadioButtonList_3" etc.

There you have it: another day, another MVC control, another blog post.

In this article we'll explore the use of classic ASP.NET controls in combination with extension methods in the MVC framework in order to facilitate development while remaining true to the MVC pattern and best practices.

A lot of hype around MVC these days. So, of course, yours truly is working on some project utilizing MVC. While brushing the dust off my raw HTML tag memory and designing the obvious: lists, grids, repeated item displays and the such, I thought "why not use the asp.net controls instead?"

For one, most of the ASP.NET data bound controls have a rich site of event post backs to hook up. MVC says: no dice! You can't rely on the event dispatch loop of asp.net. In fact, this is the whole point of going MVC – to create a simple, well separated delineation between the presentation and the BL. If you have all these states and post back logic pieces all in the code behind you really have a tightly coupled application.

What *is* available though, is the rendering of most controls. So instead of "for each" and "if" statements sprinkled in the "presentation" template, you can actually just use the plain old asp.net controls declaratively. I put "presentation" in quotation marks because the more code (branching is code!) you have in the View, the more brittle it becomes, the more tightly coupled to BL it is and the less testable it is.

The main advantages I find in using the old controls is that:

1. Familiarity – My developers know them already
2. Rich – Theming, localization behavior and layout aspects built in and available
3. Well tested – These controls have been around a while, and are generally well behaved
4. Modular – The controls isolate the presentation of a particular element and divorce it from the surrounding. In particular, it avoids issues of nesting and other inline logic in the presentation layer.

The main issue to overcome in a DataBoundControl is that with no code behind, how do you specify the data source declaratively? How do you do so with minimum code and maximum flexibility?

One solution is to use a data source object. Yes, they work. In most scenarios you can use them as you did before, but you must note that hooking up events (OnSelecting, OnSelected and the such) would again be challenging to do declaratively.

My approach for my project was to create an extension method for

DataBoundControl has a property "DataSource", to which you assign an object that will be data bound. The most permissive base object System.Object, so we simply create an extension method:

using System.Web.UI.WebControls;

public static class DataboundControlExtensions
{
    /// <summary>
    /// Extends <typeparamref name="System.Object"/> to bind it to a <typeparamref name="System.Web.UI.WebControls.DataList"/>
    /// </summary>
    /// <param name="data">The data source object to bind.</param>
    /// <param name="control">The control to bind the data source object to.</param>
    public static void BindTo(this object data, DataList control)
    {
        control.DataSource = data;
        control.DataBind();
    }

    /// <summary>
    /// Extends <typeparamref name="System.Object"/> to bind it to a <typeparamref name="System.Web.UI.WebControls.ListView"/>
    /// </summary>
    /// <param name="data">The data source object to bind.</param>
    /// <param name="control">The control to bind the data source object to.</param>
    public static void BindTo(this object data, ListView control)
    {
        control.DataSource = data;
        control.DataBind();
    }
}

Note that the control is passed in as the target and is strongly typed. As it turns out, you get a runtime error if you attempt to specify the control parameter typed as DataBoundControl – the base class for all data bound controls. In other words, this doesn't work:

public static void BindTo(this object data, DataBoundControl control) // Runtime error!

With the extension included in my project, I can now add the control and  bind it in one code line:

<% Model.BindTo(dataList); %>
<asp:DataList runat="server" ID="dataList" RepeatColumns="2" RepeatDirection="Horizontal">
    <ItemTemplate>
        <fieldset>
            <legend>
                <%# Eval("ID")%></legend>
            <p>
                Title:
                <%#Eval("Title") %>
            </p>
            <a href='<%#Eval("ImagePath") %>'>
                <img src='<%#Eval("ThumbPath") %>'  height="64" width="48" alt="pic"/></a>
            <p>
                Description:
                <%#Eval("Description") %>
            </p>
        </fieldset>
    </ItemTemplate>
</asp:DataList>

This is not as clean as completely declarative binding, but is much cleaner than having loop and branch constructs all over your view.

Most of you would note that the current MVC release includes HTML helpers. The Futures release is promising several more HTML helpers, which would provide with single line calls that would render lists, and other data bound presentation we are accustomed to. The reasons I didn't use the futures HTML helper methods are:

1. The futures were not in release yet at time
2. I don't love the mode in which the HTML helpers work
3. The HTML helpers are not as rich as the asp.net components

The reason I don't love the HTML helpers is simple: they are string valued functions. As string valued functions, they must, internally generate strings and throw away memory. Even when you use StringBuilder, the repetitive appendage of strings creates discarded buffers in the underlying byte array. Asp.Net controls, on the other hand, have access to the underlying output stream via a TextWriter. This means that the appended string snippets do not create intermediary buffers but rather get copied more efficiently to the actual byte stream that would be shipped to the browser.

So if I need to add an HTML helper to MVC what I do is write an extension method that extends System.Web.MVC.ViewPage, like so

using System.Web.Mvc;
using System.Web.UI;

public static class HelloKittyHelper
{
    public static void Meow(this ViewPage page, string text)
    {
        HtmlTextWriter writer = new HtmlTextWriter(page.Response.Output);
        if (writer != null)
        {
            writer.RenderBeginTag(HtmlTextWriterTag.Pre);
            writer.Write(KITTY_ASCII);
            writer.Write(text);
            writer.RenderEndTag();
        }
    }
    /// <summary>
    /// ASCII art of a kitty - source unknown.
    /// </summary>
        private const string KITTY_ASCII = @"
  .-. __ _ .-.
  |  `  / \  |
  /     '.()--\
 |         '._/
_| O   _   O |_
=\    '-'    /=
  '-._____.-'
  /`/\___/\`\
 /\/o     o\/\
(_|         |_)
  |____,____|
  (____|____)
";
}

Then pass it the data from the Model or anything you like from the view:

<%
   1:  this.Meow("purrr.. meow");  
%>

With the ambient objects in the page, I just extend "this", and internally utilize the HtmlTextWriter to write directly to the stream – no intermediary StringBuilder and hopefully less wasted immutable objects. The other advantage is that HtmlTextWriter can do things like begin/end tag tracking, add attributes and encode HTML as necessary. Leveraging existing well tested framework again, reducing costs of testing and education to deliver value early and often.

In conclusion, we can use the new MVC concepts and remain true to the separation of view and logic by leveraging existing components and developing minimal custom extensions that help us avoid the pitfalls of "presentation logic".

After seeing Pex in action at PDC 2008 I have caught the fever.

Since then, I gave it a whirle on my own and was pretty impressed. So much so, I chose it as a topic for one of my So-Cal Code Camp  talks in January. Got some very good questions and concerns regarding the capabilities and place of Pex in the world of software development and vis-a-vis TDD.