Today I had some fun trying to figure out how to fix the height of the jQueryUI dialog. The client wanted it to be exactly 500px. Or something that resembled 500px. Anyway, it definitely shouldn't have been from the top to the bottom of the screen. Although I sure set it to 500.

The fun part is that it had to work in IE7-9, but in *quirks* mode. The client won't switch to the standards mode, since the site (made in early 2000's, tables inside tables all the way down) would break ap...]]> codeproject

Today I had some fun trying to figure out how to fix the height of the jQueryUI dialog. The client wanted it to be exactly 500px. Or something that resembled 500px. Anyway, it definitely shouldn't have been from the top to the bottom of the screen. Although I sure set it to 500.

The fun part is that it had to work in IE7-9, but in *quirks* mode. The client won't switch to the standards mode, since the site (made in early 2000's, tables inside tables all the way down) would break apart.

After some debugging, I figured that one line in a certain method would save me. Namely, a fix would require adding a line at the beginning of the "_size" method. So, I could just leave it like that..

Except that I couldn't.

Doing so wouldn't just violate the Open/Closed principle, it would offended the shadows of the Fathers of SOLIDity and the Alt.Net deities.

After all, JavaScript is a dynamic language, right? So, we can do whatever dirty trick we can think of, including messing with "private" methods.

Extending a jQueryUI Widget by rewriting a widget's private method? Nothing could be easier!

		var proto = $.ui.dialog.prototype;
		var _size = proto._size;
		proto._size = function(){ 
			this.element.hide(); 
			_size.apply(this); 
		};

While I could easily put there something like alert('OHMYGOSH!!!') (and have fun imagining my coworkers trying to figure out what's going on), what I'm actually doing here is just add something to the beginning. So, first I'm saving a reference to the existing function, then I redefine it, adding the line I need and then invoking the function itself.

So, why do I feel like I've just committed a sin?

There are many binders in my big rusty toolchest. Some are good boys (and girls), others just like to misbehave. I mean, they do what they're destined for, and they do it really good, but in the process of doing it they break one or several Holy Laws that our Holy President wants us to abide by.

Nobody complains though.

This particular one saves me a lot of repetitive coding

Web requests tend to contain simple values. We developers like to work with objects. We li...]]> codeproject

There are many binders in my big rusty toolchest. Some are good boys (and girls), others just like to misbehave. I mean, they do what they're destined for, and they do it really good, but in the process of doing it they break one or several Holy Laws that our Holy President wants us to abide by.

Nobody complains though.

This particular one saves me a lot of repetitive coding

Web requests tend to contain simple values. We developers like to work with objects. We like it so much that we are even willing to create objects from simple values. In particular, we often have to retrieve an object from the database (or from the cache), using its ID. Believe it or not, I was doing it at the beginning of almost every action method, sometimes two or three times. I felt so exausted that I would postpone writing the rest of the method until after a lunch break.

And then I saw the light

A few years ago Scott Hanselman wrote an article about an IPrincipal model binder (I use it a lot as well). And I thought, hey, these binders are not just for slapping your form values together, they can do more than that!

And I wrote the EntityBinder.

This particular binder may be frowned upon by respectable developers. Binders should know their place, you know. They are meant to stay somewhere between your M, V, and C. Your database and the business layer should be a forbidden territory for them.

Ok guys, you may have your controller full of boring repetitive code. I'm done with this.

Another Bad Thing that this boy (or is it a girl?) does, is that it does two things instead of one (what?? you forgot about the Single Responsibility principle???). It serves both as a custom binder attribute and a Binder. I did it this way because I wanted to save several keystrokes writing [EntityBinder("projectId")] instead of [EntityModelBinder(typeof(EntityBinder), "projectId")]. While one can argue that the code for the binder became less maintainable, the code that used it became twice as maintainable, and that was a huge gain.

The downside is that I couldn't use Dependency Injection in that binder (at the time of the writing, I couldn't use it anyway, because it was the first version of Asp.Net MVC), so I had to resort to Service Location (and had never had any problem with that).

What exactly this shiny binder does, anyway?

The binder that I'm going to show you looks at the parameter name and type and tries to guess the name of the field that holds the ID, and the type of the entity. So, given a declaration like this:

public ActionResult AnketaDefinition([EntityBinder] Project project)

it looks first for a request value named "projectId", and if it cannot find it, for a value named "Id". Then it asks the ORM for an entity of the type Project with that Id.

In case we don't want the defaults, we can provide our own, but it happens very rarely.

There is one question though. What do we do if we don't find the id in the request? It turns out that there are cases when we want to return null, and cases when we want to throw an exception. There is an additional boolean parameter called "relaxed" which you can use for that. What is default behavior, you decide. I'd recommend throwing an exception, just in case.

And finally the code that you can steal use

The code together with a sample aplication can be found at GitHub. The main part, however, is below:

public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {
	var fieldName = bindingContext.ModelName + "Id";
	var result = bindingContext.ValueProvider.GetValue(fieldName);
	if (FieldNotFoundOrValueIsEmpty(result))
		fieldName = _idName;
		result = bindingContext.ValueProvider.GetValue(fieldName);
	if (FieldNotFoundOrValueIsEmpty(result)) {
		if (_relaxed) return null;
		throw new MissingFieldException("Could not find the request parameter: " + fieldName);
	}
	var entityType = _entityType ?? bindingContext.ModelType;
	var session = ObjectFactory.GetInstance<ISession>();
	var id = GetId(result, fieldName);
	object instance = session.Get(entityType, id);
	if (instance == null)
		bindingContext.ModelState.AddModelError("null", 
			new HttpException(404, 
				string.Format("Could not find {0} ({1}: {2}", entityType, fieldName, id)));
	return instance;

}

First I look for the field value using the rules I mentioned above. Next, I figure the entity type. If not specifically set in the attribute, the type should be that of the parameter we're binding to. Next, I use StructureMap.ObjectFactory to get an instance of NHibernate.ISession. You can use any container and ORM you like. The rest is simple. I have omitted the part where you handle array valued parameters, you can see it in the original source.

Writing a test for our great binder

As always, I prefer writing an integration test, the one that actully executes an Asp.Net request, because it lets me demonstrate how powerful Ivonna, my Asp.Net testing tool, is. This time, however, I'm adding a little bit of mocking (so it's not a 100% integration test). Because I don't want to setup NHibernate with all that mapping, bootstrapping, and stuff, I'm just stubbing the DB access using the new Ivonna/CThru Stub syntax:

session.Stub<ISession>("Get").Return(entity);

var entity = new Entity();
// We don't want to set up an ORM, 
// so we'll just fake ISession
var session = new TestSession();
session.Stub<ISession>("Get").Return(entity);
 
// Now let's execute a Web request
var response = session.Get("/Sample/Get?entityId=1");
 
// Check the result
Assert.AreEqual(entity, response.ActionMethodParameters["entity"]);

As you see, we prepare an Entity instance, have it returned from the stubbed ORM call, then execute our request, and verify the parameter of the action call. Our Web should have the SampleController class with the Get method having the following signature:

public ActionResult Get([EntityBinder()] Entity entity)

That's it for today, I do hope you'll find it useful, and please tell me that you like to break the rules as much as I do, whenever it makes your (and the others') life happier. I do believe that releasing this binder to the general public I'm doing a Good Thing, and the world became a better place because of this, and maybe even a couple of whales will be saved from brutal killing, but maybe not.

When you have a complicated View, things can easily get messy. A View may have several Partials, each Partial being reused in several Views. Each Partial might require certain library scripts, which in turn might depend on other scripts.

(At this point, I stopped and thought, maybe I should really add images to my posts. Ayende does it, although he has clearly no time for finding an appropriate image. All the cool guys do it. Perhaps I should do it, too.)

codeproject

When you have a complicated View, things can easily get messy. A View may have several Partials, each Partial being reused in several Views. Each Partial might require certain library scripts, which in turn might depend on other scripts.

(At this point, I stopped and thought, maybe I should really add images to my posts. Ayende does it, although he has clearly no time for finding an appropriate image. All the cool guys do it. Perhaps I should do it, too.)

<insert a messy picture here>

(By the way, if you know a place where I could quickly steal images for my posts, please tell me in the comments. I heard that it makes them more entertaining and gives a personal touch.)

Turned out FubuMVC provides a nice solution to this problem. You can have an arbitrary number of "config" files (the extension is misleading, they're plain text files) in arbitrary places, named either *.script.config, or *.asset.config. Each file describes relationships between assets, or just groups them for reference. After that, your View just references a file it needs, and your Master issues a directive to render all required files.

How do you write a config file

If you have scripts dependent on each other, you need an ordered set:

ordered set {set name}
{name1}
{name2}

For example,

ordered set jslib is
lib/jquery-1.7.1.js
lib/jquery-ui.js
lib/bootstrap.js
lib/tree.jquery.js
lib/amplify.js

Unordered set:

{set name} includes {name1}, {name2},..

Individual dependencies:

{asset name} requires {name1}, {name2}

For example,

demo.js requires jslib

Ordering individual files:

{asset name} preceeds {another name}

Applying a custom policy (should be a type implementing either IAssetPolicy or ICombinationPolicy):

apply policy {policy type}

Combining assets:

combine {name1}, {name2},.. as {set name}

Alias:

{alias} is {asset name}
e.g., jquery is lib/jquery.min.js

Extending (not sure what it means -- please enlighten me!):

{asset name} extends {another name}

In addition, you can have empty lines for readability, and lines starting with '#' for comments.

How works them config files?

Suppose you have the pieces provided above in one of your config files. Whenever you need the demo.js script on your page, you just put

<Script src="demo.js" />

<Scripts />

This should render all the required scripts for the page. In particular, although we have never mentioned we need jQuery, it's going to be referenced, since demo.js needs it. All scripts will be rendered in the correct order. In addition, there won't be any duplicates.

Another Good Thing is that the config files acan be easily reused across different projects. After all, the library dependencies is what doesn't depend on a particular project.

This can't be so good. Now tell me the bad news!

The bad news is that the current implementation enforces rather strict rules for where your assets should be. Namely, everything should be placed in the Content folder, with the hardcoded subfolder names for styles, scripts, and images. this doesn't work good with styles requiring images in a subfolder, and also can cause some friction e.g. when updating jQuery via NuGet. While having such a rigid structure is a bit unusual for this otherwise very flexible framework, the benefits, in my opinion, outweight the (forgot the English word for that thing that is outweighted by the benefits).

For a real-world sample of what I'm talking about, take a look at https://github.com/DarthFubuMVC/fubumvc/blob/master/src/FubuMVC.Diagnostics/diagnostics.script.config

So, you've read a book on TDD, a couple of blog posts from the gurus, and maybe even done the Calculator Kata several times. Now it's time to apply your knowledge to a Real Life Project that you are starting today. You probably stare at the empty solution and try to figure out where to start. "Create an instance of the System Under Test".. which system? "Mock or stub the dependencies".. which dependencies?

Sounds familiar?

Let me give you a hand

Right now I'm also...]]> codeproject

So, you've read a book on TDD, a couple of blog posts from the gurus, and maybe even done the Calculator Kata several times. Now it's time to apply your knowledge to a Real Life Project that you are starting today. You probably stare at the empty solution and try to figure out where to start. "Create an instance of the System Under Test".. which system? "Mock or stub the dependencies".. which dependencies?

Sounds familiar?

Let me give you a hand

Right now I'm also staring at the (almost) empty solution. I'll try to document what I think and do, and maybe you'll find it useful. However, remember that it's not the only way to do it, it's probably not the best way, and it even might be a bad way. But it works for me, and it might work for you, so, if you don't have a better solution, you might wanna try this one..

Meet Chpokk, an online .Net code editor.

Chpokk is meant as a lightweight replacement for Visual Studio, integrated with source control, plus some goodies like refactoring support, running your tests etc. I decided that today is a great day to develop the first feature that might be actually useful.

What do I want from my tests

There are several important requirements, that will help me a lot in writing my first test.

I want to produce some business value as soon as possible. I don't have time for all these funny AbstractFactoryFactory toys. If that means creating a one big static method, fine. I'll refactor it later. But when I refactor it, I need it to be covered with a test. So, my first test should be about the first useful thing I want to implement in my system.

I don't want my tests to be fragile. I don't know what my UI is going to be, and I don't know my API yet. But changing the UI can easily break many tests that depend on it, while the server side code can be easily refactored in sync with the tests. Not just UI, anything "stringy" should be kept out. For example, I don't want to hardcode the folder in which I'm going to keep the user's code files.

This requirement kind of contradicts the previous one, which suggested that my first test should cover everything. But while the first rquirement is more like a nice wish that would make me happy right now, the second one would save me from perpetual pain later, since robust tests are what makes me sleep well at night.

The tests should not use any knowledge from outside. This is better explained with an example. Say, I'm going to clone an existing repository from GitHub. Then I'm going to check if a certain file exists locally. The knowledge about the name of the file that should be there is not a part of the test. This can be a problem, since later looking at this test I won't know why it expects this particular file. In addition, I might rename this file later in order to use it in a different test.

How can I fix it? By adding this file to the remote repository as a part of the test. That makes my life harder, but at least I can look at the test and understand why the file should be there. In addition, my test is responsible for setting up its environment. Ideally, the test should have created a remote repository, of course, but that's probably too much. In fact, perhaps I could even manage without adding this file, but the repository content is a changing thing, while the repositories themselves tend to stay longer.

Enough philosophy, show me the code already!

Not so fassst, mah friend! Just wait for the next part, where I'm figuring the requirements for the first iteration and writing tests for them.

Managing your dependencies with NuGet can be just fine.

Unless you want some of these be compiled locally.

For example, imagine that you have a complicated dependency graph, and you've just modified a source of one of the assemblies. Or you just want the freshest bits from the source control. Now you want to use the local version in your project, since you don't want to wait till your modification is accepted and released as a NuGet package. At the same time, you want to ...]]> codeproject

Managing your dependencies with NuGet can be just fine.

Unless you want some of these be compiled locally.

For example, imagine that you have a complicated dependency graph, and you've just modified a source of one of the assemblies. Or you just want the freshest bits from the source control. Now you want to use the local version in your project, since you don't want to wait till your modification is accepted and released as a NuGet package. At the same time, you want to use the other dependencies managed for you by NuGet, plus merge the recent updates to the ones that you build locally. Welcome back to dependency nightmares.

This could be even worse than the pre-NuGet era. If only Ripple didn't exist.

Ripple was created for scenarios like this. Well, not exactly, but at least it can save you from Dependency Hell. What's even better, Ripple will do a lot of things for you so that all your solutions will have the freshest bits from NuGet when the local source is missing, and locally built assemblies conveniently put into the NuGet package folders.

In other words, Ripple is NuGet's best friend.

For a good introduction to Ripple (and its requirements), check the Ian Battersby's Ripple-tastic! post. Ian gives an example of a "targeted" rippling -- from one to another solution. However, I have discovered it's more fun to just "ripple around" -- shoot "ripple local" without the "from" and "to" pieces. This way Ripple just fixes and updates everything it can.

There are many Ripple commands available. Here is the (incomplete) list of them, as of today.

• Clean -- just clean a particular solution, or all solutions. Can clean packages, project outputs, or both.
• Float -- makes the package "floating" -- marked as to be updated by Ripple.
• GitIgnore -- Lists or adds values to the .gitignore file.
• History -- write the list of packages to the dependency-history.txt file.
• Init -- Creates a basic ripple.config file and opens it in an editor, removes packages from Git and adds their folder to .gitignore
• List -- for each solution, outputs the list of projects with their dependencies and published packages.
• Local -- you better try it yourself with a verbose flag and watch the output.
• LocalNuget -- Creates the nuget files locally
• Lock -- opposite to Float, locks a nuget to prevent it from being automatically updated from the Update command.
• Publish -- Builds and pushes all the nuspec files for a solution(s) to nuget.org.
• Restore -- another important command, interacts with nuget to restore all the nuget dependencies in a solution tree.
• Update -- gets the latest NuGets (or just lets you preview them). As I understand, either Restore or Update is used as part of the Local command execution.
• UseTheirs -- Does a 'use theirs' merge on all the project and packages file in a solution.
• WhereAmI -- Tells you where ripple thinks the root folder is at.

You can see that this is a great piece of functionality for those who works actively with OSS dependencies. It is opinionated, in the ForUsByUs way, but you can happily use it in non-Fubu projects. The only annoying limitation for me is that you should keep your projects in the same folder, but it's not annoying enough for a pull request.

Ripple is included in the buildsupport submodule if you get the source of any Fubu project.

Jasmine is one of the most popular BDD-style Javascript testing frameworks. I decided to use it for my new project, Chpokk, built on top of FubuMVC. Here are the steps that I made, together with some for-dummies explanations.

Adding Jasmine to your project

is as easy as adding the FubuMVC.TestRun...]]> codeproject

Jasmine is one of the most popular BDD-style Javascript testing frameworks. I decided to use it for my new project, Chpokk, built on top of FubuMVC. Here are the steps that I made, together with some for-dummies explanations.

Adding Jasmine to your project

is as easy as adding the FubuMVC.TestRunner NuGet package to your project. After that, navigate to /testing/suites/whatever, and see a greenish almost empty page that says "0 specs". Jasmine is installed.

What's under the hood?

After you add the package, you discover a zip file named fubumvc-testrunner.zip in your fubu-content folder. This file is a "bottle", a piece of functionality that adds itself to the main application. With the first Web request, the zip is extracted ("exploded") to a subfolder. Let's see what we have there.

The WebContent folder is mapped to the root of your application. The Shared subfolder contains the Application.spark file, which is going to be the master page for all test pages, and the bindings file.

Take a look at the following snippet from the Application.spark file:

	<Stylesheet href="jasmine.css" />
	<Script src="fubumvc-testrunner" />

  <element name="Stylesheet">#this.Asset('@href');</element>
  <element name="Script">#this.Asset('@src');</element>

this.WriteScriptTags()

<Scripts />

The actual View is called Run.spark, and located in the suites folder. It's very simple:

<viewdata model="FubuMVC.TestRunner.Suites.RunSuiteViewModel" />
<content:title>${Model.Suite}</content:title>
<content:scripts>
  <Script src="${Model.Suite}" />
</content:scripts>

Adding the first test

In order to use the Fubu's Asset Pipeline, I put my test script into the /Content/scripts folder of my Web.

Here is my sampletest.js:

describe("First test", function() {
	it("should fail", function() {
		expect(true).toBeFalsy();
	});
});

As a real TDD practitioner, I'm creating a failing test first. Mom would be proud of me!

After saving this file, I navigate to /testing/suites/sampletest.js, and I see a failing test. WIN!

Dealing with a Real World Problem

Having all your code in the tests is fine, but at some point a manager might want you to move some of it to the production files. So, we'll need to include several files in our tests. Let's see how to do it.

Let's create another file called realstuff.js, and put it into the Content/Scripts folder:

function arewegood() {
	return false;
}

tests includes realstuff.js, sampletest.js

Now, we'll use the name of the set in the Url: /testing/suites/tests. If we look at the source, we'll see that both scripts are loaded. We can put another script set in our config file, and we'll be able to run a different suite with a different Url.

The last step is to modify our test so that it depends on the "production" code:

describe("First test", function() {
	it("should fail", function() {
		expect(arewegood()).toBeTruthy();
	});
});

That's it for today, I still have to make this test pass.

Update

@jmarnold pointed me that Serenity does all that and lots of other great stuff. I guess I'll have to delete all this and start from scratch. In the next post, I'll tell you what happened.

This is the third part in the series about custom Asp.Net MVC Model Binders and Value Providers. Part 1 is about two ways of using DateTime.Now as an Action Method parameter for better testability, and Part 2 is about building a Value Provider for the Http Header values. Read on. codeproject

This is the third part in the series about custom Asp.Net MVC Model Binders and Value Providers. Part 1 is about two ways of using DateTime.Now as an Action Method parameter for better testability, and Part 2 is about building a Value Provider for the Http Header values. Read on.

What's up with subclassing your models

Often you need to use inheritance in your domain model. For example, you might have to model a book with a list bibliographic references. Each reference might be to an article in a magazine, to another book, to a Web page etc. So, you create a Reference abstract class, and a couple of subclasses for different types of references. You might also want to create a parallel inheritance chain for your models.

Now, suppose you have a list of references. Each row has a link to the page where you can edit the corresponding reference object. While different types of references have different fields to edit, you don't want to create a separate page for each type. Displaying a reference is simple: you just call Html.EditorFor() inside your form, and the fairies will generate the necessary fields for that particular kind of reference. The problem is how to get the new values back.

Suppose you have the following action method:

[HttpPost]
public ActionResult Update(ReferenceModel model) {
	//...
}

The default binder will try to create an instance of ReferenceModel, and will fail, since this is an abstract class. So, we'll have to use a different binder. The one that is smart enough so that it could create an instance of the concrete type.

Implementing the SubclassingBinder

In order to do it, we'll have to provide the name of the model's type. We'll do it via a hidden field called ModelType:

<input type="hidden" name="ModelType" value="<%=this.Model.GetType() %>"/>

One would be tempted to override the CreateModel method, but that wouldn't be enough. The model would be created, but it would not be populated with the subclass-specific properties. The binder would still use the metadata of the base abstract class, so the properties specific to the concrete class will not be picked up.

So, we're going to override the BindModel method and "correct" the model type, then let the binder create and bind a model of the requested type for us. Here's the code:

public override object BindModel(ControllerContext controllerContext, 
	ModelBindingContext bindingContext) {
	if (bindingContext.ValueProvider.ContainsPrefix("ModelType")) {
		//get the model type
		var typeName = (string) bindingContext
			.ValueProvider
			.GetValue("ModelType")
			.ConvertTo(typeof(string));
		var modelType = Type.GetType(typeName);
 
		//tell the binder to use it
		bindingContext.ModelMetadata = 
			ModelMetadataProviders
			.Current
			.GetMetadataForType(null, modelType);
	}
	return base.BindModel(controllerContext, bindingContext);
}

Do you have teh tests?

Oh yes we have! As always, we're going to test our code with the help of Ivonna, our favorite Asp.Net testing tool. Here's the test. It verifies two things: given the model type and a property value, a model of the correct type is created and the property is filled with that value (disclaimer: I'm usually opposed to several asserts in a test, but I'm doing it here for clarity):

[TestFixture, RunOnWeb]
public class ModelSubclassing {
	private const string NEW_ARTICLE_NAME 
		= "On the meaning of death";
 
	[Test]
	public void BinderCreatesArticleModelWithValues() {
		var response = new TestSession()
			.Post("/Sample/UpdateReference",
			new {
				ModelType = typeof(ArticleModel)
					.ToString(),
				ArticleName = NEW_ARTICLE_NAME
			});
			
		//verify that we have the corect model type
		Assert.IsInstanceOf<ArticleModel>(
			response.ActionMethodParameters["model"]);
		//verify that we have filled 
		//the concrete type specific properties
		var model = 
			(ArticleModel)response
				.ActionMethodParameters["model"];
		Assert.AreEqual(NEW_ARTICLE_NAME, model.ArticleName);
	}
}

So, following my previous post on implementing a custom Asp.Net Value Provider, here is another one.

Request Header Value Provider

Here is a totally useless requirement: add a Value Provider that would let you use your request headers in your actions without calling HttpContext.Current.Request (or something equally unacceptable). This is actually absurdly simple, because we alread...]]> codeproject

So, following my previous post on implementing a custom Asp.Net Value Provider, here is another one.

Request Header Value Provider

Here is a totally useless requirement: add a Value Provider that would let you use your request headers in your actions without calling HttpContext.Current.Request (or something equally unacceptable). This is actually absurdly simple, because we already have a convenient base class, NameValueCollectionValueProvider, that takes a collection and provides its values to the unsuspecting Controller. So, the code it pretty simple:

public class RequestHeaderValueProvider : NameValueCollectionValueProvider {
	public RequestHeaderValueProvider(ControllerContext controllerContext)
		: base(controllerContext.HttpContext.Request.Headers, 
			CultureInfo.CurrentCulture) { }
 
}
 
public class RequestHeaderValueProviderFactory : ValueProviderFactory {
	public override IValueProvider GetValueProvider
			(ControllerContext controllerContext) {
		return new RequestHeaderValueProvider(controllerContext);
	}
}

ValueProviderFactories.Factories.Add(new RequestHeaderValueProviderFactory());

Now it's enough to name the action method parameter as the header you need, and you'll get the value automatically.

Writing a test for it

So, I wasn't completely honest with you when I said it was completely useless. Apart from using it in RESTful apps, there is a pretty common need to get the Referer value, mostly for redirecting back to it as part of the Post-Redirect-Get routine. So, we can test two things (using Ivonna of course): that we have our Referer value as an argument, and that we are actually redirecting to it. Both are integration tests, and the second one is testing both our infrastructure and the actual Action method, but who cares:

[Test]
public void TestHeaderProvider() {
	var request = new WebRequest("/Sample/ActionUsingReferer")
		{AutoRedirect = false};
	const string previousurl = "/PreviousUrl";
	request.Headers["Referer"] = previousurl;
	var response = new TestSession().ProcessRequest(request);
	Assert.AreEqual(previousurl, 
			response.ActionMethodParameters["referer"]);
	Assert.AreEqual(previousurl, 
			response.RedirectLocation);
}

Notice that we have to disable the Autoredirection feature of Ivonna: without that, we'll be testing the result of the redirection (quick poll: do you want this property to be false by default?), rather than the original request. Notice that we ae using the new MVC feature of Ivonna: the ability to get the action method parameters.

Finally, here's the code that makes this test happy:

public ActionResult ActionUsingReferer(string referer) {
	return Redirect(referer);
}

Recently I started a challenge on LinkedIn: let's write blog posts about custom model binders, view results, and other extensible stuff in Asp.Net MVC; let's do it one post a day for a week and see what happens. Presumably, it should benefit everybody, especially Asp.Net MVC newcomers.

Well, I'm two days late already, and I don't feel like doing a big post today, so today's a really simple...]]> codeproject

Recently I started a challenge on LinkedIn: let's write blog posts about custom model binders, view results, and other extensible stuff in Asp.Net MVC; let's do it one post a day for a week and see what happens. Presumably, it should benefit everybody, especially Asp.Net MVC newcomers.

Well, I'm two days late already, and I don't feel like doing a big post today, so today's a really simple custom Model Binder. But first, we should decide which functionality we wan to move to our binders. For me, an eye opening post was Scott Hanselmann's one on his IPrincipal binder. The logic here is very simple. The Smart Guys Who Invented Asp.Net MVC wanted it to be testable. Specifically, they wanted the Action Methods to be testable. So, let's make them happy and proud of us, and let's write testable Action Methods, shall we?

There are two simple tricks that can help with it. One trick is widely adopted in general programming: Dependency Injection. You can write a service, use it as a constructor argument in your Controller, and use this service inside your method to retrieve the required value (and also to execute an action, but that's a different story). However, you can end up with 10 methods, each requiring a different service, hence 10 services injected in the constructor, and you'll have to create all 10 for testing each method.

Another option is parameter injection: you don't create a service in order to retrieve a value (and mock it in your tests), you just use your value as a parameter. The testability problem is solved, but how about the runtime behavior? Yes, we'll use custom Model Binders (and Value Providers).

Let's see your example

One of the common values that are used in our methods, but cannot be tested using our usual tools, is DateTime.Now. Yes, I know that Typemock Isolator can mock it now, but that's not the point. The point is that, rather than call it inside our method, we can provide it as an argument. It would be our Custom Model Binder's responsibility to look at the watch and tell us the time. (Note that we don't eliminate the untestable part, we just move it from our controller elsewhere)

Here's the code for the custom binder:

public class NowBinder : IModelBinder {
	public object BindModel(
			ControllerContext controllerContext, 
			ModelBindingContext bindingContext) {
		return DateTime.Now;
	}
}

And the example usage:

public ActionResult ActionUsingCurrectDateTime(
	[ModelBinder(typeof(NowBinder))] DateTime current) {..

You are encouraged to subclass the ModelBindingAttribute in order to make it more readable, but that's another story.

Doing it with a custom Value Provider

While custom Model Binders are used more or less widely, there's another point of extensibility tht might be of use here: a custom Asp.Net MVC Value Provider. This might be even more appropriate: while Model Binders are created to construct objects from data, Value Providers are the ones who retrieve this data from the outside world. Obviously, the system clock is a part of this "outside world" so, let's use a value provider:

public class NowValueProvider : IValueProvider {
	public bool ContainsPrefix(string prefix) {
		return prefix == "now";
	}
 
	public ValueProviderResult GetValue(string key) {
		var now = DateTime.Now;
		if (key == "now")
			return new ValueProviderResult(
				now, 
				now.ToString(CultureInfo.CurrentCulture), 
				CultureInfo.CurrentCulture);
		return null;
	}
}

public class NowValueProviderFactory : ValueProviderFactory {
	public override IValueProvider 
		GetValueProvider(ControllerContext controllerContext) {
		return new NowValueProvider();
	}
}

ValueProviderFactories.Factories.Add(new NowValueProviderFactory());

However, you don't have to use a custom binder now, just name your parameter "now", and it'll be automatically bound to DateTime.Now:

public ActionResult ActionUsingNowValueProvider(DateTime now)

In addition, whenever your model has a property named "Now", it'll be filled automatically by the default model binder.

Isn't it sweet?

Can we test that it works?

Previously I said that we're moving the untestable part to a different place. The point is, we have moved it to our infrastructure, leaving our controller clean of infrastructure concerns. However, with the latest Ivonna for MVC we can test that the whole thing works together correctly.

[Test]
public void TestValueProvider() {
	var result = new TestSession()
		.Get("/Sample/ActionUsingNowValueProvider");
	var model = (DateTime) result.Model;
	Assert.AreApproximatelyEqual (
		DateTime.Now, 
		model, 
		TimeSpan.FromSeconds(1)) ;
}

Today I'm fighting with two very annoying bugs in Ivonna.

The first one is, when you debug your tests, sometimes you get the AppDomainUnloaded exception ("Attempted to access an unloaded AppDomain"). That one has been annoying me for some time, so I decided to fix it. I have opened the thread list, found the thread that contained a call to AppDomain.Unload, switched to it, and checked the HttpRuntime instance. The _shutDownMessage field told me: "Change Notification for critical di...]]> codeproject

Today I'm fighting with two very annoying bugs in Ivonna.

The first one is, when you debug your tests, sometimes you get the AppDomainUnloaded exception ("Attempted to access an unloaded AppDomain"). That one has been annoying me for some time, so I decided to fix it. I have opened the thread list, found the thread that contained a call to AppDomain.Unload, switched to it, and checked the HttpRuntime instance. The _shutDownMessage field told me: "Change Notification for critical directories.\r\nbin dir change or directory rename\r\nHostingEnvironment initiated shutdown\r\nHostingEnvironment caused shutdown". So I watched the bin folder while running the test and discovered that Gallio copied the test project's config file to it, and then deleted it in the middle of a test. The runtime discovered that the bin folder contents has been changed and it should crash just in case.

Fixing it has been easy. I just stubbed the ReleaseResourcesAndUnloadAppDomain method using the CThru built-in Stub aspect.

The other bug is actually two bugs that manifest themselves only when combined. Ivonna creates an AppDomain for testing, and this AppDomain was having a duplicate PrivateBinPath (two identical paths actually). This was fine until I tried to test a FubuMVC based project that expected a single path in the PrivateBinPath property (actually it's a Bottles bug, but, since nobody uses multiple bin paths, the bug is probably not worth fixing). I won't bother you with technical details, but the good news is that Ivonna is now fully compatible with FubuMVC.