Now, before I get too carried away here, let me re-divulge the following preface: if you’re completely new to the madness of Chirpy, I recommend that you read about Chirpy’s core features, which were solidifed and released in Chirpy 1.0.0.4. Then, check out the additional features that we added in Chirpy 1.0.0.5. If you’re still not quite convinced that Chirpy will help reinvigorate all of your decompressed hopes and dreams, listen to the almighty David Ebbo wax ornithological about the goodness of the Chirpy Bird. Then, once you’re up to speed, come on back to this almighty post.

Like last time, I’d like begin by tipping my hat to the main Chirpy contributors. Please send them money, Cadbury Eggs, hugs, fresh tulips, etc.: Francis Noel (aka ploufs), Andy Edinborough, Wayne Brantley, and newcomers Martijn Laarman, and Domenic Denicola. I owe them all a huge thank you. They’ve kept this project alive (and uber vibrant) while I was away trying to keep my job and my love life (brown chicken, brown cow) alive, so I can’t thank them enough. If you happen to feel the same affinity for their amazing craftsmanship, please consider donating a couple bucks to the team. If you donate enough wads of cash-money-cash-cash, we’ll release a future version of Chirpy in your honor (eh, Budweiser Chirpy, anyone?).

If you’re teary-eyed or vulnerable to digital persuasion, you can donate to us here:

Bored already? Ignore me, and Download Chirpy now.

Okay, then. Welcome back. Let’s get down to it. In version 2 of Chirpy, we’ve fixed a lot of the bugs that were troubling our fellow Chirpsters. We’ve also added a slew of new mantastic features. We hope you like them:

• CoffeeScript Support
• Offline Google Closure Support
• Uglify.js Support
• JSHint Support
• Inline minification for Razor Views
• The Consolation Prize (Chirpy Console)

Feature 1: CoffeeScript Support

Step 1: Read up on CoffeeScript. You can find out all you need to know on the CoffeeScript homepage. Make sure to check out the thorough documentation, if you’re into that kind of stuff.

Step 2: Add a .chirpy.coffee file to your project.

Step 3: Add some CoffeeScript into your CoffeeScript file.

Step 4: When you save your file, you’ll notice that Chirpy creates .js and .min.js codebehind files. Open those files to see the JavaScript generated from your CoffeeScript. Time to bask in the caffeinated glory:

Feature 2: Offline Google Closure Support

Step 1: Download JRE (Java Runtime Environment) from java.com. You can snag it by clicking here.

Step 2: Install JRE. This can take some time. Consider watching an episode of Law & Order. If you can’t find an episode of Law & Order on TV, you’re probably not trying hard enough. If JRE is still installing, eat dinner. Learn your kids’ names. Hug them. Take a nap.

Step 3: Open Visual Studio. Click Tools > Options > Chirpy > Google Closure Compiler.

Step 4: Select the option to Use Offline Google Closure Compiler. If you’re lucky, Chirpy will automatically find JRE. If you’re not lucky, you’ll have to manually direct Chirpy to the honeypot.

Step 5: Download compiler.jar. You can download it here.

Step 6: Unzip compiler.jar and place the file in your Visual Studio AddIns folder.

Step 7: You’re good to go! When you use gct, your files will be minified locally:

Feature 3: Uglify.js Support

Step 1: Learn about Uglify.js here. If you think it’s the uglifier for you, jump to step 2.

Step 2: Create an .uglify.js file. Save it. And, mung-balls:

Your uglified output is generated. (Insert joke about your boyfriend/girlfriend/husband/wife/fakefriend here):

Feature 4: JSHint Support

Step 1: Learn about JSHint here. Snag the source code from here. Learn about the JSHint quality rules here. If you’re super-bored, check out Crockford’s JSLint from which JSHint is humbly derived.

Step 2: Do something stupid in your chirpy-managed JavaScript file. Like, eh, use the evil eval(). Save your file, and watch JSHint get ornery:

Step 3: If you prefer to be left alone, you can turn JSHint off. To do so, go to Tools > Options > Chirpy > JavaScript, and unselect Run JSHint.

Feature 5: Inline minification for Razor Views

Step 1: In your MVC project, create a new Razor View. Name the view Test.chirp.cshtml.

Step 2: Add some javascript, css, or DotLess to your file:

The Consolation Prize (Chirpy Console)

So, if the visual bling of VS2010 doesn’t strike your fancy, you can now run chirpy from the command line. Keep in mind, though: the console version of Chirpy is still in its early stages infancy, so if you have any ideas/concerns/insights, please fling them my way. Until then, the Chirpy Console shall serve as simple consolation prize (sorry) for the command-line pervs out there.

Step 1: Download the Console Chirpy zip file, here.

Step 2: Unzip the file and place the folder somewhere warm and safe.

Step 3: Pick a directory that you want Chirpy to chew through. For this example, I went with this doozy of a folder:

Step 4: Feed Chirpy the directory.

Step 5: Bask in the darkness. Check out the folder that you chewed through. Your minified files have been created/updated:

Ready? Run over to Codeplex when you’re ready and download Chirpy.

That’s it! Once again, Chirpy says (as always): Happy Coding!

Before diving too deep into the realm of the extreme, let me re-divulge the following preface: if you’re completely new to the madness of Chirpy, I recommend that you read about Chirpy’s core features. You can also watch David Ebbo demo Chirpy as a part of his MvcConf presentation. That should get you caught up. And once you’re caught up, come on back to this post.

Another important side-note: Chirpy’s current warp-like maturation is largely due to the superb and continued contributions of Andy Edinborough and Francis Noel. As a thanks for their support, and as an impetus for continued feather-laden progress, I kindly ask that you consider throwing a dollar or two (hundred [thousand]) into our donation hat. Andy, after all, has four children, and each requires at least one plate of sustenance per day. And I, although completely childless, have an insatiable, child-like desire for candy bars and diet Red Bulls.

At the very least, if you have experienced the pleasure of the flightless Chirpy bird (or if you feel like complaining about how crappy Chirpy is), go to Chirpy’s Codeplex page and write a comment or two. Or, if you’d like to follow the project more closely, feel free to follow all of Chirpy’s developers on Twitter.

Alright. Without further ado:

Xxxtreme New Chirpy Features

Let’s start with the obvious: you can download Chirpy v1.0.0.5 here.

Got it? Good.

Now, here’s an overview of all of the new features that you’ve just blessed yourself with. Click on the feature below that most likely suits your fancy, or, if you’re a real sucker for e-pain, you can scroll through the whole document (may God help you) until you reach the very, very end.

• Chirpy Handles Seven New File Extensions
• Chirpy Handles Inline Aspx and Ascx Translation and Minification
• Chirpy’s Source is Now More Modularized and Multi-Threaded
• Chirpy Can Use Google Closure Tools Offline
• Chirpy’s Config Files Now Tote Intellisense

<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

    <h2>Test.Chirp.aspx</h2>

    <script type="text/javascript">
        function thisWillGetMinifiedYo() {
            alert("hi");
            alert("bye");
        }
    </script>
</asp:Content>

<asp:Content ID="Content1" ContentPlaceHolderID="HeadContent" runat="server">
    <style type="text/less">
        @color : #123456;

        tag
        {
            background-color:@color;
        }
    </style>
</asp:Content>

using System;

namespace Zippy.Chirp.Engines
{
    public class TestEngine : TransformEngine
    {
        public TestEngine()
        {
            Extensions = new string[] { ".test.moo", ".test.foo" }; //extensions that this engine handles
            OutputExtension = ".test"; //outputted extension
        }

        public override string Transform(string fullFileName, string text, EnvDTE.ProjectItem projectItem)
        {
            return "//here is the outputted text:" + Environment.NewLine + text;
        }

        public override void Process(Manager.VSProjectItemManager manager, string fullFileName, EnvDTE.ProjectItem projectItem, string baseFileName, string outputText)
        {
            //process occurs after transformation
            //you can override, if you so choose...
            base.Process(manager, fullFileName, projectItem, baseFileName, outputText);
        }
    }
}

internal TestEngine TestEngine { get; set; }

public void LoadActions() {
    if(_EngineManager == null || _EngineManager.IsDisposed)
        _EngineManager = new EngineManager(this);

    _EngineManager.Clear();
    _EngineManager.Add(YuiCssEngine = new YuiCssEngine());
    _EngineManager.Add(YuiJsEngine = new YuiJsEngine());
    _EngineManager.Add(ClosureCompilerEngine = new ClosureCompilerEngine());
    _EngineManager.Add(LessEngine = new LessEngine());
    _EngineManager.Add(MsJsEngine = new MsJsEngine());
    _EngineManager.Add(MsCssEngine = new MsCssEngine());
    _EngineManager.Add(ConfigEngine = new ConfigEngine());
    _EngineManager.Add(ViewEngine = new ViewEngine());
    _EngineManager.Add(T4Engine = new T4Engine());
    _EngineManager.Add(TestEngine = new TestEngine()); //here's our baby
}

<?xml version="1.0"?>

<root
  xmlns="urn:ChirpyConfig"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ChirpyConfig http://www.weirdlover.com/chirpy/chirp.xsd">

  <FileGroup Name="mash.js" Minify="False">
    <File Path="jquery-1.4.2.min.js"/>
    <File Path="json2.min.js"/>
  </FileGroup>

  <FileGroup Name="mash.min.js" Minify="True">
    <File Path="jquery-1.4.2.min.js"/>
  </FileGroup>
</root>

alvinashcraft I have 162 fake followers, and you? http://twifakes.heroku.com/

I must’ve been feeling lonely. Because “fake followers” seemed like a really intriguing concept. It reminded me of a tweet written by Scott Hanselman a few days earlier:

shanselman Interesting little tidbit for you. Kevin Smith has 1.6 MILLION followers and tweets a lot. He RT’ed something of mine, and *crickets.*

I thought to myself, “How many of my followers are fake?” I mean, when I user twitter, it almost always feel like I’m taking a really long walk down a super lonely, cricket-laden pier. And, besides, if I could only find out exactly how many of my fake online friends/followers are super-super-fake, I might actually be able to stop Googlbating and peecrastinating, at least for a minute or two.

In my moment of despair and self-loathing, in walk two Brazillian fellows. Meet: Cairo Noleto (@caironoleto) and Cleiton Francisco (@cleitonfco). They created an “open source” twitter application that “counts” the number of fake followers that are fakely following you. It’s called #TwiFakes, and it’s sweeping the fake twitter nation.

So, as I was staring lovingly at my Twitter page, I naively thought to myself, “If it’s good enough for Alvin Ashcraft to retweet about the #TwiFakes phenomenon, then it’s good enough for me to try!” And try I did. And, without my consent (which is of little use to anyone), #TwiFakes went ahead and FarmVilled me right in the face. My newest post, which I did not consent to, looked a lot like Alvin Ashcraft’s, except instead of 162 fakers, I had a measley 12:

evannagle I have 12 fake followers, and you? http://twifakes.heroku.com/

Flash forward a few days. Julie Lerman (@julielerman) falls victim to the same malicious Brazillian antics. Lucky for Julie, she has fewer fake followers than I do (proportionate to the total number), so one of her dedicated followers was kind enough to point her to Adrian Short’s excellent TwiFakes post. In it, Adrian offers the following bit of quasi-conspiratorial (albeit excellent) advice:

You may have seen the website at http://twifakes.heroku.com/ which promises to tell you how many “fake” Twitter followers you have. Do not authorise this website. It tweets without your permission and there’s no telling whether it may do other damage to your account.

Now, here’s the real kicker:

In case you’re wondering, your number of “fake” followers is the number of followers you have divided by twelve. Hardcore algorithm.

And here’s how Cairo and Cleiton plead their case for their so-called algorithmic masterpiece:

In the Holy Bible, Jesus had 12 followers loyal to his cause, but among them was a fake that was the name of this apostle was Judas.

Following this logic, we conclude that every 12 that a person has followers on Twitter, one of them is fake.

Simply calculate the number of followers a person has and divide by 12, this result is the amount of people who are fake.

Flash forward to this very moment in time. Cairo and Cleiton’s devious invention is still sweeping the twitter nation, especially amongst the Portuguese-speaking population. (Interesting sidenote: it seems that black people [who virtually own Twitter] have largely been spared). Though Cairo and Cleiton have removed the non-permissive tweet from their arsenal, their super-simple algorithm is still churning away behind the curtain of shame, and more and more desperate souls are selling their personal privacy for a possible quenching of their ever-increasing hunger for reality.

Aside from the obvious complaints I could make here–complaints that are well-detailed in Adrian’s post–I do believe that Cairo and Cleiton’s spamtastic app sheds some light on a fundamental twitterer’s desire. A desire for fame and self-affirmation, that is. Twitter, after all, is really a vehicle for micro-fame, as it allows non-Jesuses like myself to accrue exponentially more followers than Jesus ever did (to follow me, click here). And, admittedly, there’s something really pleasing about writing a quick fetishized fragment of thought and fantasizing about all the world salivating and retweeting it.

Time to get really, really real, then: Twitter is itself not a valid means of calculating self-worth. One’s “number” of “followers” is more like one’s “number” of “co-fantasizers”, and, sooner or later, we’re all going to wake up and realize that the internet, as social and as complex and as beautiful as it is, can’t really tell us who we are beause it’s way too busy catering to the people that we want to pretend to be. In other words, all of your followers are pretty much fake. No need for division, or frivolous spamming, or crucifixions.

Now, though I’m not a religious fellow by any means, I figure that a quote from Jesus might be in order:

If any of you wants to be my follower, you must turn from your selfish ways, take up your cross, and follow me. If you try to hang on to your life, you will lose it. But if you give up your life for my sake and for the sake of the Good News, you will save it. And what do you benefit if you gain the whole world but lose your own soul? Is anything worth more than your soul? If anyone is ashamed of me and my message in these adulterous and sinful days, the Son of Man will be ashamed of that person when he returns in the glory of his Father with the holy angels.

Or, the tweetable version:

jesuschrist #ff @jesuschrist

You’ve sucked all the blood out of me. Hence, the bottomless silence.

That said, I’ve finished creating a working version of Big Fat Dish. Joy almighty! Beer and Cool-aid-induced unconsciousness await!

Now, don’t get too excited. The site is nowhere NEAR perfect (unlike my looks). And I haven’t finished everything that I set out to finish. Not even close. But the project’s not crappy. And I have plenty more blogging to do (though the 25 posts I’ve written thus far will have to suffice as the ‘in-depth’ portion of this experiment, at least for now). I’ve gotten some great feedback from the community (a huge thanks to everyone), and I think it’s time that the “Big Boy MVC series” finally became more of a, eh, community experiment. In short: help me.

Hopefully, if you’ve been following along, you’ve learned a decent amount about MVC (while also enjoying my self-effacing jokes). Now, since my hair and my patience are growing thinner, and since you’ve surely grown into a hair-greased MVC pro by now, it’s time that YOU teach ME something. That’s right. Teach me anything. Do it. I dare you. Wise-cracking and smack-talking can only get you so far. So, have at it.

Okay. Anyways. Here’s the idea:

• Download Big Fat Dish. You can grab the source code here
• Fiddle around with the source code. Add new features. Fix crappy features. Add crappy features. Keep in mind: I’m using the term “feature” loosely here. Add WHATEVER suits your fancy (design, code, copy, coffee stains, WHATEVER). In essence, start learning/doing crap on your own. Like my ex-girlfriend always used to tell me: some time apart will be good for our relationship. So, spend some time by yourself, create something cool, and get back to me.
• If you think that your addition/s to the project might be worthwhile to others then I beg you to blog about what you’ve done. Or, at the very least, make a pull request, and I’ll be sure to add your changes to the main project.
• If I like your addition (which I probably will), and if the addition is substantial enough (which it probably will be), I’ll add you as a developer on the project. If you are a developer on any of the project, I consider you a lifelong friend. I will divert bullets for you. I will also respond to your emails in a timely fashion.
• Most importantly, have fun. And don’t be evil. And don’t cry. I’m excited to learn some new tricks. And I’m excited to see what kind of website is brought forth from the OSS ether.

A quote from the Codeplex page, which sums it up methinks:

In its current state, the project is well-formed but severely lacking in all kinds of digital coolness (features, styling, logo, love-making, etc). As a natural extension of the Big Boy MVC series, the Codeplex project will serve as a community-oriented means of continued MVC learning. If you’re new to MVC, or if you’re a sleazy MVC master, this project is a great sandbox for feature-testing and crap-flinging.

Alrighty. That’s all for now! I’m excited to see what kind of madness ensues! Happy coding!

It’s an awesome new assembly/namespace that contains everything you’ll ever need to access a database. In ASP.NET WebPages we wanted people to be able to access the database without having to write too many lines of code. Any developer that has used raw ADO.NET knows this pain:

using (var connection = new SqlConnection(@"Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\Northwind.mdf;
                                           Initial Catalog=|DataDirectory|\Northwind.mdf;Integrated Security=True;User Instance=True")) {
    using (var command = new SqlCommand("select * from products where UnitsInStock < 20", connection)) {
        connection.Open();
        using (SqlDataReader reader = command.ExecuteReader()) {
            while (reader.Read()) {
                Response.Write(reader["ProductName"] + " " + reader["UnitsInStock"]);
            }
        }
    }
}

Wow, that’s a lot of code compared to:

using (var db = Database.OpenFile("Northwind")) {
    foreach (var product in db.Query("select * from products where UnitsInStock < 20")) {
        Response.Write(product.ProductName + " " + product.UnitsInStock);
    }
}

Shortly thereafter, Rob Conery had this to say:

Data Acess is hard! Let's go shopping! http://bit.ly/cbO9Kh - we've been down this road, oh so many times.

Then, Oren Eini wrote this scathing response. An excerpt:

I really don’t know where to start. Yes, compared to raw ADO.Net I guess that this is improvement. But being beaten only thrice a week instead of daily is also an improvement.

I mean, seriously, are you freaking kidding me? Are you telling me that you are aiming to make the life of people writing code like this easier?

Then, a baby calf was born.

Then, a bunch of developers started tweeting and making jokes at Microsoft.Data's expense!

Then, Andrew Nurse (one of the creators of Razor), wrote this defense. An excerpt:

David Fowler, fellow ASP.Net team member, posted about it earlier today, and the response has been … active. The message behind most of these responses has been that it encourages bad practices to novice developers. I think there’s an important point that’s being missed here: It doesn’t matter how hard we work, as professional developers, to create clean architectures and abstractions, there’s a whole world of novice developers who just don’t care about that. They want to write code now and be done with it. This is the audience targeted by Microsoft.Data, and the WebMatrix product as a whole.

Then, David Fowler wrote a follow-up post. In it, he clarified (perhaps fearful for his life, and the lives of his unborn children...):

These blog posts point out that WebMatrix targets a different audience than our traditional pro developer audience. These are people who are not yet developers (if they ever plan to be). They may never want to become a pro developer, but want to be able to put together a simple website. If you've internalized best practices and patterns and know your way around an ORM, then you will most likely never use this library. We are trying to attract a different kind of customer: people who are on other platforms and are already using SQL today in their web pages, and people that are trying to get into programming and haven’t chosen a platform as yet.

Most likely, if you're even reading this, you're not the intended audience, though we are still interested in your feedback.

Then, my friend, David Ebbo, chimed in:

As great as ORMs are, there is a measurable number of web developers who favor writing raw SQL over using an ORM. Now you may not think highly of people in that camp, but if you’re trying to pretend that they don’t exist, you’re in denial. Though they tend to be less vocal, there are a lot of people who prefer this approach, for a variety of reasons. They could be ‘SQL gurus’ who like full control, or more likely they are not experienced programmers, and all the OOP that come with ORMs are just not for them.

Then, Andrew Nurse, Scott Gu, and Rob Conery started fighting (with words) on Twitter.

Then, other stuff happened.

Then, my mom called me.

Then, after all the punch in the punch bowl had already been consumed and regurgitated, I started writing this very post. It's too late to save anyone. Or to say anything interesting. But I might be able to bring a little bit of comic relief to the battle zone. We'll see. Here comes the meta.

So, let's take a breath, and, before we punch anybody, let's reflect.

Okay. Reflection over. Now, let me shamelessly divulge my reflection-conjured thoughts.

Thought 1: Microsoft.Data is a bad name for a namespace. It's too generic, and novice developers won't be able to find documentation via a simple google search.

Instead of "Data", a name prefixed by ADO might be better, as it would be much easier to search for, and would be more likely to inspire the "novice" developer to get better acquainted with the ADO technology that he's fiddling with. "Data" is too myopic, especially for a library that serves as a light ADO wrapper.

Thought 2: Microsoft's response to the outcry is misguided. The anger is cultural, not technical.

Yes; everyone knows that Microsoft constructed WebMatrix, Razor, and Microsoft.Data as part of a pointed campaign to entice novice developers (and stupid people) into flocking to the pricey Microsoft stack. And, yes; the Microsoft.Data library will surely be a helpful library for those developers who want to throw a website together without thinking too much about the architecture of what they're constructing. Technically (and commercially) speaking, Microsoft has a slew of perfectly legitimate reasons for splattering the landscape with these "watered down" technologies. But, culturally speaking, it's painful to the professional Microsoft developer. It is. Because the Microsoft developer's personal and professional identity is tied up in the Microsoft stack, and that stack is now catering to a bunch of cat ladies and acne-laden teenagers. That's the real issue here.

To put this point another way, let's talk about the nowNEVER-defunct band, Tool. Let's say that, out of the blue, Tool decided to write a song about the importance of loving lambs and feeling all "gushy inside". A "professional" Tool fan would surely be outraged--not because Tool had done something stupid on a functional (i.e. musical) level, but because Tool had lost its sense of direction, and had thus muddied the waters that once helped the Tool fan construct and reinforce his/her identity. And, all the while, Tool frontman, Maynard James Keenan, only had this to say:

I think there’s an important point that’s being missed here: It doesn’t matter how hard we work, as professional musicians, to create hardcore sounds and abstractions, there’s a whole world of teenie boppers who just don’t care about that.

Thought 3: Shakespeare had it right.

Every Shakespeare play operates on three levels. The first level is embodied in a jester, who entertains the onlookers (mostly children) who are ill-equipped to understand what's going on in the plot. The second level is the plot, which entertains the onlookers who are capable of longer spurts of self-guided attention. And the third level is metaphorical, which entertains the onlookers who are capable of extracting a bottomless stream of interesting, non-explicit symbolic themes from the play's unraveling. Now, here's the kicker of it all: each level entices the onlooker to "upgrade" to the next level.

To put this another way: Shakespeare didn't employ the jester just to let stupid people off the hook. The jester prods the stupid onlooker into deeper contemplation. Isaac Asimov chimes in with this tidbit of interest about the function of the Shakespearean jester:

Some have argued that the clowning in Shakespeare's plays may have been intended as "an emotional vacation from the more serious business of the main action". Clowning scenes in Shakespeare's tragedies mostly appear straight after a truly horrific scene: The Gravediggers in Hamlet after Ophelia's suicide; The Porter in Macbeth just after the murder of the King; and as Cleopatra prepares herself for death in Antony and Cleopatra. Nevertheless, it is argued that Shakespeare's clowning goes beyond just 'comic relief', instead making the horrific or deeply complex scenes more understandable and "true to the realities of living, then and now" by shifting the focus from the fictional world to the audience's reality and thereby conveying "more effectively the theme of the drama."

So, for me, that's the real question here--namely, is WebMatrix (and, by extension, Microsoft.Data) just a space for stupid people to clown around and be perpetually and bottomlessly stupid? Or is it a means to attempt to help new developers attain a better grasp of the fundamentals of software development? Judging by the defeatist attitude of some of the Microsoft bloggers thus far (with sentiments like "people who will never be x"), I fear that the answer might be the former.

Thought 4: This isn't the end of the world. There are people starving. There are wars. There are women being traded as sex slaves right outside my window in Honolulu. In sum, Microsoft.Data isn't responsible for the totality of all human suffering.

Look, I understand that it's painful to watch a company like Microsoft cater to developers (i.e. old ladies) who aren't as technically proficient as "professional" developers are, but that's really no reason to rant about how "stupid" the world is (my own hypocrisy is intended here) and how "Microsoft fucks everything up". The reality is: not everyone can do the things that you can do, or learn the things that you so easily learned. And you should be proud of that. No need to lash out. Your prowess makes you special. You don't need Microsoft.Data to make your websites hum. And you'll surely get paid a good salary to fix the websites that do. So spend your energies fixing a real problem, like your crumbling relationship with your wife, or world hunger, or your T.V. set.

Thought 5: As a Microsoft developer, you have to trust Microsoft. You have to give up the need for cultural affirmation. You have to believe that Jesus is a Microsoft employee.

Culturally, OSS will beat Microsoft any day of the week. Because OSS is like love (sex for free), and Microsoft is like prostitution (sex for money). Love is definitely nicer (or "gushier"), but prostitution is a stabler source of long-term sexual relations. And that's the trade off you're making as a Microsoft developer. In twenty years, you know that Microsoft will still be pimpin' something nerdy, but RoR might be an abandoned ghost town full of broken twitter-like applications. Probably not, but who knows. After all, when something's free, it's beautiful. But it's more likely to flee. Whether that's a good thing or a bad thing, that's up to you to decide.

So, those are my thoughts for now.

Play dramatic music here.

Close curtains.

Cue flaming comments.

Wrapped your head around the concept yet? Good. Let’s begin by taking a quick look at a simple example of prototypal inheritance in JavaScript. This example comes from Tim Caswell’s aptly named post, Prototypal Inheritance. If you’re familiar with JavaScript, this snippet of code should seem pretty trivial.

var Animal = {
  eyes: 2,
  legs: 4,
  name: "Animal",
  toString: function () {
    return this.name + " with " + this.eyes + " eyes and " + this.legs + " legs."
  }
}

var Dog = Animal.spawn({
  name: "Dog"
});

var Insect = Animal.spawn({
  name: "Insect",
  legs: 6
});

var fred = Dog.spawn({});
var pete = Insect.spawn({});

sys.puts(fred);
sys.puts(pete);

Using anonymous types in C# 3.0, we could almost recreate an Animal object in the exact same manner that we created the JavaScript Animal above–that is, with one glaring and obvious exception: the this in the toString function. C# 3.0 will have none of it:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Create_JavaScript_Ish_Object()
        {
            var Animal = new
            {
                eyes = 2,
                legs = 4,
                name = "Animal",
                toString = (Func<string>)(() =>
                    this.Name + " with " + this.Eyes + " eyes and " + this.Legs + " legs.")
            };
        }
    }
}

The compiler resolves the “this” to Protopal.Tests.Core.ProtoTest (as it should). And, since the ProtoTest class contains no definition for name, eyes, or legs, the compiler lets us feel its wrath:

In C# 4.0, the dynamic type offers us an interesting workaround. For starters, we can create the following delegates–each of which contains a dynamically typed first parameter. More on that in a second:

namespace Protopal.Core
{
    public delegate TR PFunc<TR>(dynamic me);
    public delegate TR PFunc<T1, TR>(dynamic me, T1 arg1);
    public delegate TR PFunc<T1, T2, TR>(dynamic me, T1 arg1, T2 arg2);
    public delegate TR PFunc<T1, T2, T3, TR>(dynamic me, T1 arg1, T2 arg2, T3 arg3);

    //and the allstars...
}

Okay. We’re getting closer. Let’s go ahead and rework our Animal object so it compiles. Notice that we’re now setting the toString property to a PFunc instead of a Func, and in our PFunc, by convention, we’re assuming that the first passed parameter will be resolved to our not-yet-defined anonymous type (i.e. the “this” we wanted all along):

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Create_JavaScript_Ish_Object()
        {
            var Animal = new
            {
                eyes = 2,
                legs = 4,
                name = "Animal",
                toString = (PFunc<string>)
                    (me => me.name + " with " + me.eyes + " eyes and " + me.legs + " legs.")
            };
        }
    }
}

Now, we can feed our Animal object back into the toString() function and retrieve the string that we’d expect. Granted, this initial solution is uglier than any woman that I’ve ever dated (only by a little), but at least it works. Don’t cringe yet, friend. We’ll make it much, much prettier in just a moment:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Create_JavaScript_Ish_Object()
        {
            var Animal = new
            {
                eyes = 2,
                legs = 4,
                name = "Animal",
                toString = (PFunc<string>)
                    (me => me.name + " with " + me.eyes + " eyes and " + me.legs + " legs.")
            };

            Assert.AreEqual("Animal with 2 eyes and 4 legs.", Animal.toString(Animal));
        }
    }
}

Yes, it works, but that kind of ugliness won’t do. We can definitely do better.

Let’s start by creating our own DynamicObject class. We’ll call our class Proto. Proto will be very similar to ExpandoObject (which also derives from the DynamicObject class). The main difference: when a user invokes a PFunc delegate on a Proto class, we’ll intercept the call and insert the Proto class as the first argument.

Before I reveal the Proto class, let me preface the following code with two important sentiments. First, I’m just screwing around here. I think that a Proto-ish class could really be useful in certain situations, but I don’t share Rob Conery’s inner desire to DuckDiaper and Rubify everything. Second, as you’ll hopefully notice, the DynamicObject class is amazingly and dangerously flexible–so flexible, in fact, that you can really force the dynamic type to do whatever the heck you want, even if the thing you want to do is really, really stupid. So, beware. And don’t blame me if your boss fires you.

using System;
using System.Linq;
using System.Collections.Generic;
using System.Dynamic;

namespace Protopal.Core
{
    public sealed class Proto : DynamicObject
    {

        Dictionary<string, object> members;

        object obj;

        public static dynamic Pal(object members)
        {
            return new Proto(members);
        }

        Proto(object members)
        {
            if (members == null)
            {
                this.members = new Dictionary<string, object>();
                this.obj = new object { };
            }
            else
            {
                this.obj = members;
                Type objType = this.obj.GetType();

                if (objType == typeof(Proto))
                {
                    Proto parent = (Proto)this.obj;
                    this.members = new Dictionary<string, object>(parent.members);
                }
                else
                {
                    this.members = objType
                        .GetProperties()
                        .ToDictionary(k => k.Name, v => v.GetValue(members, null));
                }
            }
        }

        public override bool TrySetMember(SetMemberBinder binder, object value)
        {
            members[binder.Name] = value;
            return true;
        }

        public override bool TryGetMember(GetMemberBinder binder, out object result)
        {
            if (members.TryGetValue(binder.Name, out result))
            {
                return true;
            }
            else
            {
                result = new Proto(new object { });
                members[binder.Name] = result;
                return true;
            }
        }

        public override bool TryInvokeMember(InvokeMemberBinder binder,
            object[] args, out object result)
        {
            object member;

            if (members.TryGetValue(binder.Name, out member))
            {
                Type memberType = member.GetType();

                if (memberType.IsGenericType)
                {
                    var genericType = memberType.GetGenericTypeDefinition();

                    if (genericType == typeof(PFunc<>) ||
                        genericType == typeof(PFunc<,>) ||
                        genericType == typeof(PFunc<,,>) ||
                        genericType == typeof(PFunc<,,,>))
                    {
                        var del = member as Delegate;

                        var delArgs = new List<object>();
                        delArgs.Add(this);
                        delArgs.AddRange(args);

                        result = del.DynamicInvoke(delArgs.ToArray());
                        return true;
                    }
                }
            }

            return base.TryInvokeMember(binder, args, out result);
        }
    }
}

Now, let’s reconfigure our test:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Create_JavaScript_Ish_Object()
        {
            var Animal = Proto.Pal(new
            {
                eyes = 2,
                legs = 4,
                name = "Animal",
                toString = (PFunc<string>)
                    (me => me.name + " with " + me.eyes + " eyes and " + me.legs + " legs.")
            });

            Assert.AreEqual("Animal with 2 eyes and 4 legs.", Animal.toString());
        }
    }
}

That works. Coolness. Cookies for all!

Okay, okay. Let’s not congratulate ourselves just quite yet. What about “spawning” all kinds of child classes from our Animal object–you know, like in good ol’ JavaScript? Hmm. Good question.

For starters, if we really want to accomplish this feat, we have to create an extension method for merging together dictionaries. I swiped this bit of code form StackOverflow:

using System.Collections.Generic;
using System.Linq;

namespace Protopal.Extensions
{
    public static class DictionaryExtensions
    {
        public static T MergeLeft<T, K, V>(this T me, params IDictionary<K, V>[] others)
            where T : IDictionary<K, V>, new()
        {
            T newMap = new T();
            foreach (IDictionary<K, V> src in
                (new List> { me }).Concat(others))
            {
                foreach (KeyValuePair<K, V> p in src)
                {
                    newMap[p.Key] = p.Value;
                }
            }
            return newMap;
        }
    }
}

Now, we can add a public Spawn method to our Proto class:

using System;
using System.Linq;
using System.Collections.Generic;
using System.Dynamic;
using Protopal.Extensions;

namespace Protopal.Core
{
    public sealed class Proto : DynamicObject
    {

        Dictionary<string, object> members;

        object obj;

        public static dynamic Pal(object members)
        {
            return new Proto(members);
        }

        Proto(object members)
        {
            if (members == null)
            {
                this.members = new Dictionary<string, object>();
                this.obj = new object { };
            }
            else
            {
                this.obj = members;
                Type objType = this.obj.GetType();

                if (objType == typeof(Proto))
                {
                    Proto parent = (Proto)this.obj;
                    this.members = new Dictionary<string, object>(parent.members);
                }
                else
                {
                    this.members = objType
                        .GetProperties()
                        .ToDictionary(k => k.Name, v => v.GetValue(members, null));
                }
            }
        }

        public dynamic Spawn(object members)
        {
            var pal = new Proto(members);
            pal.members = this.members.MergeLeft(pal.members);

            return pal;
        } 

        public override bool TrySetMember(SetMemberBinder binder, object value)
        {
            members[binder.Name] = value;
            return true;
        }

        public override bool TryGetMember(GetMemberBinder binder, out object result)
        {
            if (members.TryGetValue(binder.Name, out result))
            {
                return true;
            }
            else
            {
                result = new Proto(new object { });
                members[binder.Name] = result;
                return true;
            }
        }

        public override bool TryInvokeMember(InvokeMemberBinder binder,
            object[] args, out object result)
        {
            object member;

            if (members.TryGetValue(binder.Name, out member))
            {
                Type memberType = member.GetType();

                if (memberType.IsGenericType)
                {
                    var genericType = memberType.GetGenericTypeDefinition();

                    if (genericType == typeof(PFunc<>) ||
                        genericType == typeof(PFunc<,>) ||
                        genericType == typeof(PFunc<,,>) ||
                        genericType == typeof(PFunc<,,,>))
                    {
                        var del = member as Delegate;

                        var delArgs = new List<object>();
                        delArgs.Add(this);
                        delArgs.AddRange(args);

                        result = del.DynamicInvoke(delArgs.ToArray());
                        return true;
                    }
                }
            }

            return base.TryInvokeMember(binder, args, out result);
        }
    }
}

And, for the long-awaited finale, here’s some quasi-prototypal C#, which functions just as well (sans any possible issues of so-called “performance”) as Tim Caswell’s prototypal JavaScript code:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Create_JavaScript_Ish_Object()
        {
            var Animal = Proto.Pal(new
            {
                eyes = 2,
                legs = 4,
                name = "Animal",
                toString = (PFunc<string>)
                    (me => me.name + " with " + me.eyes + " eyes and " + me.legs + " legs.")
            });

            var Dog = Animal.Spawn(new
            {
                name = "Dog"
            });

            var Insect = Animal.Spawn(new
            {
                name = "Insect",
                legs = 6
            });

            var fred = Dog.Spawn(new {});
            var pete = Insect.Spawn(new {});

            Console.WriteLine(Animal.toString());
            Console.WriteLine(Dog.toString());
            Console.WriteLine(Insect.toString());
            Console.WriteLine(fred.toString());
            Console.WriteLine(pete.toString());
        }
    }
}

Looks like all of our animals are happy in their pens, which is nice:

Extra Credit

Interestingly enough, the Protopal class yields a couple of cool (and quasi-unintended) side benefits. For starters, we can “change” the values of properties in anonymous types. For example:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Try_To_Set_Anon_Type_Property()
        {
            var Animal = new
            {
                Name = "Animal"
            };

            //This is an error:
            //Animal.Name = "Manimal";

            var animalHijacked = Proto.Pal(Animal);
            animalHijacked.Name = "Manimal";

            Assert.AreEqual("Manimal", animalHijacked.Name);
        }
    }
}

Also, you can implement interesting IOC patterns, like this whopper:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Protopal.Core;

namespace Protopal.Tests.Core
{
    [TestClass]
    public class ProtoTest
    {
        [TestMethod]
        public void Proto_Sandbox_Reference_Property_That_Doesnt_Exist()
        {
            var evan = new
            {
                Name = "Evan"
            };

            var jaimie = new
            {
                Name = "Jaimie"
            };

            var sayer = Proto.Pal(new
            {
                Say = (PFunc<string, string>)
                    ((me, x) => me.Name + " says, '" + x + "'")
            });

            string jaimieSays = sayer.Spawn(jaimie).Say("wudup");
            string evanSays = sayer.Spawn(evan).Say("yo yo");

            Assert.AreEqual("Jaimie says, 'wudup'", jaimieSays);
            Assert.AreEqual("Evan says, 'yo yo'", evanSays);
        }
    }
}

And that’s really just the tip of an extremely precarious iceberg…

What Now?

Sleep. Then, breakfast.

I think that this is an interesting, if not a super-stupid, POC. Surely, with a little bit of elbow grease and a hefty dose of refinement, a class like Protopal could really serve some kind of useful purpose. Maybe? Eh, I don’t know. Maybe you have a better idea of what that “purpose” might be (if anything). For now, I’ll leave the iceberg as it is, and let you chime in.

The good news: in my last Big Boy post, we created a prettyish design-friendly EditorTemplate. That was fun. So, with our EditorTemplate completed, our FoodAdd page is looking all dolled up and decently man-spiffy:

The Bad News: I’m behind schedule. I wanted to finish this project in a month, and, if you’ve been paying close attention to the time I’ve wasted fiddling with the project, you’d know that I’m a week past my deadline. I’m not mad, or ashamed, or crying. Please don’t make fun of me. Of all the holdups, blogging has been the greatest hindrance (it takes me a couple of hours to write about a task that takes 3 – 5 minutes to accomplish), but blogging has also been the most beneficial restraint that I’ve imposed on myself–an even more beneficial restraint than the ol’ unit tests. And, as far as I’m concerned, the public documentation (and the public support/critique) is well-worth the holdup. So, it’s been a learning experience, and I want to keep learning. So, the blogging shall continue.

Anyways, I want to apologize for the quasi-failure (if you knew me better, you would’ve seen it coming), and I pray that, if you’re reading this series after I’ve completed writing it, you’ll still be able to create your website in a month–as a benefit of my slower process of meandering and divulging.

As a thank you for following along, I’m going to post the project on Codeplex sometime in the next couple of days. If the speed of my blogging is holding you up, you can download the project, look at the changes I’ve made, and be on your merry way. For those of you that are okay with the slower pace, never fear; I’ll keep chugging along in blog form. Until my arms fall off. And my legs. And until every last one of you is sick of my mouthwatering Yegge-like chops. Mmm.

Alright. Enough banter. Today is special. Why, you ask? Because, today, we’re going to tie up a bunch of loose ends. And, when those loose ends are, eh, so unloose it hurts, we’ll finally be able to experience an uber-desired form post. That’s right. A successful form post. It will be a truly fist-pump-worthy event in our otherwise banal and lonely lives.

Let’s start with an homage to Kazi Manzur’s List of MVC Best Practices. Before you read any further in this post, I recommend that you read Kazi’s recommendations. While reading, you’ll notice that Kazi recommends that you implement the PRG pattern (something I blogged about here). In laymen’s terms: when the user posts data, we’ll verify the data. If the data sucks (no Food Name, no Restaurant Name, bad Address that we can’t successfully geolocate), we’ll redirect right back to the FoodAdd page, and we’ll tell the user what he did wrong. If the data doesn’t suck, we’ll redirect to the FoodAdded page, and we’ll thank the user for not sucking.

We have one hurdle when we’re implementing the PRG pattern: when the user sucks, we’re going to redirect back to the FoodAdd page. When we redirect, MVC is going to destroy any/all of our ModelState errors. But, in this case, we need to preserve those precious ModelState errors because we’ll use those errors to show the user exactly why and how he sucks. So, in essence, ModelState is our mirror; our user is a fat ugly delusional mess, and we need to do the legwork to plop that mirror right in front of our fat, ugly user’s mess-of-a face.

Here’s where Kazi comes in. To pass our ModelState from one request to another, we’ll create two ActionFilters. The first attribute, called PassState, will insert our ModelStateDictionary into TempData. The second attribute, called GetState, will retrieve our ModelStateDictionary from TempData. If you’re new to ActionFilters, you might want to check out this msdn article before diving into deeper waters.

Here’s our PassState ActionFilter. Notice that we’re adding ModelState to TempData when our ModelState is invalid. This type of scenario is exactly why TempData exists: we can use it to pass data to an action when we redirect (Craig Stuntz goes so far as to call TempData “RedirectData” for this very reason). If you’re using TempData for any purpose other than passing data right before you redirect, you’re probably better off using ViewData. That said, here’s our PassState ActionFilter, which uses TempData appropriately:

using System.Web.Mvc;

namespace Big.Fat.Dish.Controllers.ActionFilters
{
    public class PassStateAttribute : ActionFilterAttribute
    {
        public const string TempDataTransferKey = "__Big.Fat.Dish.TempDataTransferKey";

        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            //Only export when ModelState is not valid
            if (!filterContext.Controller.ViewData.ModelState.IsValid)
            {
                //Export if we are redirecting
                if ((filterContext.Result is RedirectResult) || (filterContext.Result is RedirectToRouteResult))
                {
                    filterContext.Controller.TempData[TempDataTransferKey] = filterContext.Controller.ViewData.ModelState;
                }
            }

            base.OnActionExecuted(filterContext);
        }
    }
}

And here’s our GetState ActionFilter. We’re grabbing the ModelState object that we lodged into TempData, and we’re merging it with the current request’s ModelState. Here goes nothing:

using System.Web.Mvc;

namespace Big.Fat.Dish.Controllers.ActionFilters
{
    public class GetStateAttribute : ActionFilterAttribute
    {
        public override void OnActionExecuted(ActionExecutedContext filterContext)
        {
            string key = PassStateAttribute.TempDataTransferKey;
            ModelStateDictionary modelState = filterContext.Controller.TempData[key] as ModelStateDictionary;

            if (modelState != null)
            {
                //Only Import if we are viewing
                if (filterContext.Result is ViewResult)
                {
                    filterContext.Controller.ViewData.ModelState.Merge(modelState);
                }
                else
                {
                    //Otherwise remove it.
                    filterContext.Controller.TempData.Remove(key);
                }
            }

            base.OnActionExecuted(filterContext);
        }
    }
}

So, we stole this code from someone else. But that doesn’t mean that we shouldn’t test it. As you might imagine, testing ActionFilters can be a little tricky, because you have to mock out a bunch of classes that contain the word “Context” in their cozy little class names. As you’ll surely come to realize (if you haven’t already), “Context” is an MS keyword for “We’re doing some crazy unmockable shit in this hizzy!” Unfortunately, it’s these very “Context” hizzies that we really should mock up, because we’re way more likely to do something really stupid when we play with them.

Up to this point, I’ve been using RhinoMocks to mock out my objects. To be honest, I used RhinoMocks because I wanted to try it out. I don’t mind RhinoMocks, but, the reality remains: I’m an avid Moq fan. I love Moq like I love the ladies (and the Legos). And I’d be doing you a real disservice if I didn’t at least introduce you to Moq’s vibratory Mockgasms.

If you’ve never worked with Moq, you can read the QuickStart guide here. Once you’ve digested the basics, I suggest that you head over to StackOverflow and read some of the Moq-related posts there. Once you get the hang of it, I think you’ll enjoy Moq’s terser syntax. I think you’ll also notice that Moq is just as powerful as RhinoMocks, if not more so, especially when it comes to giving you undeniable and pleasurable mockgasms (did I already try that joke?).

So, let’s setup a couple tests to verify that Kazi’s ActionFilters are going to work properly in our project. (Never doubt Kazi; you might be struck by a heavy flash of Jesus-steered lightning). To begin, let’s go ahead and test PassState:

using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
using Big.Fat.Dish.Controllers.ActionFilters;
using Big.Fat.Dish.Controllers;

namespace Big.Fat.Dish.Tests.Controllers.ActionFilters
{
    [TestClass]
    public class PassStateTest
    {
        PassStateAttribute passState;
        FoodController controller;
        Mock<ActionExecutedContext> actionContext;

        [TestInitialize]
        public void TestInitialize()
        {
            actionContext = new Mock<ActionExecutedContext>();
            passState = new PassStateAttribute();
            controller = new FoodController();

            actionContext.Setup(m => m.Controller).Returns(controller);
        }

        [TestMethod]
        public void Controllers_ActionFilters_PassState_Inserts_ModelState_Into_TempData_If_ModelState_Is_Invalid_And_Result_Is_Redirect()
        {
            controller.ModelState.AddModelError("anyString", "anyError");
            actionContext.Object.Result = new RedirectResult("/");
            passState.OnActionExecuted(actionContext.Object);

            Assert.IsTrue(controller.TempData.ContainsKey(PassStateAttribute.TempDataTransferKey));
            Assert.AreEqual(controller.ModelState, controller.TempData[PassStateAttribute.TempDataTransferKey]);
        }

        [TestMethod]
        public void Controllers_ActionFilters_PassState_Does_Not_Insert_ModelState_Into_TempData_If_ModelState_Is_Invalid_And_Result_Is_Not_Redirect()
        {
            controller.ModelState.AddModelError("anyString", "anyError");
            actionContext.Object.Result = new ViewResult();
            passState.OnActionExecuted(actionContext.Object);

            Assert.IsFalse(controller.TempData.ContainsKey(PassStateAttribute.TempDataTransferKey));
        }

        [TestMethod]
        public void Controllers_ActionFilters_PassState_Does_Not_Insert_ModelState_Into_TempData_If_ModelState_Is_Valid()
        {
            actionContext.Object.Result = new RedirectResult("/");
            passState.OnActionExecuted(actionContext.Object);

            Assert.IsFalse(controller.TempData.ContainsKey(PassStateAttribute.TempDataTransferKey));
        }
    }
}

And, similarly, let’s test GetState:

using System.Web.Mvc;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Moq;
using Big.Fat.Dish.Controllers;
using Big.Fat.Dish.Controllers.ActionFilters;

namespace Big.Fat.Dish.Tests.Controllers.ActionFilters
{
    [TestClass]
    public class GetStateTest
    {
        GetStateAttribute getState;
        FoodController controller;
        Mock<ActionExecutedContext> actionContext;
        ModelStateDictionary passedDictionary;

        [TestInitialize]
        public void TestInitialize()
        {
            getState = new GetStateAttribute();
            controller = new FoodController();
            actionContext = new Mock<ActionExecutedContext>();
            passedDictionary = new ModelStateDictionary();
            passedDictionary.AddModelError("anyError", "anyMessage");

            actionContext.Setup(m => m.Controller).Returns(controller);
        }

        [TestMethod]
        public void Controllers_ActionFilters_GetState_Merges_ModelState_If_Result_Is_ViewResult_And_TempData_Contains_Key()
        {
            actionContext.Object.Result = new ViewResult();
            controller.TempData[PassStateAttribute.TempDataTransferKey] = passedDictionary;
            getState.OnActionExecuted(actionContext.Object);

            Assert.IsTrue(controller.ModelState.ContainsKey("anyError"));
        }

        [TestMethod]
        public void Controllers_ActionFilters_GetState_Does_Not_Merge_ModelState_If_Result_Is_Not_ViewResult()
        {
            actionContext.Object.Result = new RedirectResult("/");
            controller.TempData[PassStateAttribute.TempDataTransferKey] = passedDictionary;
            getState.OnActionExecuted(actionContext.Object);

            Assert.IsFalse(controller.ModelState.ContainsKey("anyError"));
        }

        [TestMethod]
        public void Controllers_ActionFilters_GetState_Does_Not_Merge_ModelState_If_TempData_Does_Not_Contain_Key()
        {
            actionContext.Object.Result = new ViewResult();
            getState.OnActionExecuted(actionContext.Object);

            Assert.IsFalse(controller.ModelState.ContainsKey("anyError"));
        }
    }
}

Now that we have our ActionFilters built and tested, we can move on (or return yet again) to our FoodController. Since we last visited our FoodController, we’ve done more than our fair share of work. For starters, we created the ViewModel layer (and mapped our ViewModel to our Model via AutoMapper). We also created a Geocoder, a Permalink generator, and, more recently, we created two ActionFilters (remember?). Let’s tie it all together:

using System;
using System.Web.Mvc;
using Big.Fat.Dish.Models;
using Big.Fat.Dish.ViewModels;
using Big.Fat.Dish.WebRequests.Geocoding;
using Big.Fat.Dish.Controllers.ActionFilters;

namespace Big.Fat.Dish.Controllers
{
    public class FoodController : Controller
    {
        IGeocoder lazyGeocoder;
        IGeocoder geocoder
        {
            get
            {
                if (lazyGeocoder == null)
                {
                    lazyGeocoder = new Geocoder();
                }

                return lazyGeocoder;
            }
        }

        IRepository lazyRepo;
        IRepository repo
        {
            get
            {
                if (lazyRepo == null)
                {
                    lazyRepo = new Repository();
                }

                return lazyRepo;
            }
        }

        public FoodController() : this(null, null) { }
        public FoodController(IRepository repo, IGeocoder geocoder)
        {
            this.lazyRepo = repo;
            this.lazyGeocoder = geocoder;
        }

        [HttpGet, GetState]
        public ViewResult Add()
        {
            return View("Add");
        }

        [HttpPost, PassState]
        public ActionResult Add(FoodAdd form)
        {
            if (!ModelState.IsValid)
            {
                return RedirectToAction("Add");
            }

            Food food = form.Map();
            food.Restaurant.Address = geocoder.GetAddressFromString(form.OneLineAddress);

            if (food.Restaurant.Address == null)
            {
                ModelState.AddModelError("OneLineAddress", "You provided an invalid Restaurant Address.");
                return RedirectToAction("Add");
            }

            this.repo.Foods.CreatePermalinksFor(food);
            this.repo.Add(food);
            this.repo.Save();

            return RedirectToAction("Added", new { id = food.Id });
        }

        public ViewResult Added(int id)
        {
            var model = new FoodAdded
            {
                Food = this.repo.Foods.WithId(id)
            };

            return View(model);
        }

        public ViewResult Details(int id)
        {
            var model = new FoodDetails
            {
                Food = this.repo.Foods.WithId(id)
            };

            return View(model);
        }
    }
}

So, let’s take a minute to reflect. When a user posts data in our food form, that data will get bound (via MVC’s DefaultModelBinder). If the user did anything stupid, we’ll redirect him back to the FoodAdd page (with ModelState errors intact). If the user didn’t screw anything up, we go ahead and geocode his OneLineAddress. If the geocoder can’t create an address, we’ll redirect the user back to the FoodAdd page (with a OneLineAddress error). If the geocoder successfully creates an address, we generate permalinks for all of our records (Food, Address, Restaurant), and we save our food in our good ol’ fashioned database.

You’ll notice that I’m not showing you everything here. For example, I created a ViewModel class for each of my ViewPages (FoodAdd, FoodAdded, FoodDetails, and HomeIndex). And I also extended my Foods pipe with the CreatePermalinks() method. And, prior to anything else, I created some more coveted unit tests for the new functionality. Since I’ve completed all of these tasks before (in some fashion or another), I’m hoping that you can take the initiative to do some work on your side of tracks, thus allowing me to conserve some of my “precious keystrokes”.

Extra Credit

If you’re a visual learner, I don’t blame you. Let’s take a look at the monster we’ve created. For starters, set a stopping point in your post method. It doesn’t matter where, really:

Start your project, and navigate to the “/Food/Add” page. Add some data into the form. Here’s my attempt at being user-like with my QAing:

Hit the huge-ass Add Food button. Your post method should get invoked, so your project should pause at the breaking point. So, VS should look (and feel) something like this:

Take a look at the FoodAdd parameter. You’ll notice that the data I posted has been property populated (i.e. “bound”) into my FoodAdd class:

Now, let’s check out the Map() method, which should convert our FoodAdd ViewModel into a Food class. Lo and behold, it does exactly what we had hoped and dreamed!

Now, the geocoder. I gave the geocoder a really crappy address to resolve, so I was hoping that we’d get a ModelState error. But, life is funny. And it looks like our geocoder is trying a little too hard to impress us. So, we get an Address returned to us after all (something we’ll definitely want to tweak at a later date [an easy fix]). Hey, at least we know that the geocoder is working, which is good:

The post succeeds, and we’re transported to the FoodAdded page. I’ve spruced this page up just a little bit, so don’t be afraid. Also notice that I’m still tinkering with the verbiage:

Now, to top it all off, take a look in your database. Everything should be fine and dandy:

Cool. So we have one successful (although unintentional) post under our belts. Let’s navigate back to the “/Add/Food” page and submit a blank form. Again, our project is paused at the breaking point. If you fish around, you’ll notice that ModelState is not valid. Then, you’ll notice that ModelState contains three errors. Then, if you do some serious digging, you’ll find the error messages that ModelState has created for us:

Now it’s time for our EditorTemplate to do its magic. The user is redirected to the FoodAdd page, which now displays all of the ModelState error messages (thanks to our PassStateAttribute, GetStateAttribute, and EditorTemplate):

Good times. More good times are surely ahead of us.

Move on to Part 26: It’s Codeplex Time!.

If you’re new to Chirpy, or if you need a refresher, or if you’re interested in learning about the new Chirpy functionality, this post is for you. I’m lifting my glass. I hope that you’re lifting yours, too.

Let’s start with the simplest part: download Chirpy at codeplex. Start fiddling around. If something doesn’t work complain about it. If something does work, tweet or blog about how awesome your life has become. Finally, if you’re feeling really frisky, download Chirpy’s source code and add something. I don’t care what it is. Just add something. Surprise me. I’ll probably love you forever. Or, I’ll throw something at you.

Speaking of contributors. I’d like to tip my hat to the main Chirpy contributors: Please send them money and flowers: Wayne Brantley, Francis Noel (aka ploufs), and Andy Edinborough. I owe them all a huge thank you. And many beers. And hugs.

This page contains everything (new and old) that you’d ever need to know about Chirpy. For all intents and purposes, you can navigate to the section that interests you most, follow the quasi-steps, and be on your merry way. Or, if you’re a sucker for pain, you can sludge through the entire document. Whatever makes you happiest. In sum, with Chirpy, you can:

• …minify javascript files
• …translate DotLess files into css files
• …minify css files
• …mash content files together
• …validate javascript and DotLess files
• …autorun T4 templates (incl. T4MVC)

Benefit 1: Minify the Crap Out of Your Javascript Files

Step 1: Install Chirpy. The latest version of Chirpy can be downloaded at Codeplex.

Step 2: Add a javascript file to your project. Name the file “woo.yui.js”. Adding the “.yui.js” suffix to our filename is Chirpy’s cue to look after the file. Right away, you’ll notice that Chirpy has adorned our new javascript file with a “codebehind” file:

Step 3: Type some javascript in the woo.yui.js file. Save your changes, and check out the codebehind file. Chirpy has created a minified version of your file (using YUI Compressor). Here’s my unminified file:

And here’s the codebehind file, which Chirpy generated for me:

Step 4: Use a different compressor. If you don’t like the YUI Compressor, that’s okay. Chirpy can also minify your file using Google Closure Tools. Currently, Chirpy will handle five different javascript extensions:

• file.yui.js – uses YUI Compressor to minify your file
• file.whitespace.js – uses Google Closure Tools to remove all of the extra spaces from your file
• file.simple.js – uses Google Closure Tools to minify your javascript file (with simple optimizations)
• file.gct.js – uses Google Closure Tools to minify your javascript file (with advanced optimizations)
• file.chirp.js – Chirpy picks the best minifier for the job, and minifies your javascript file accordingly

So, let’s go ahead and change woo.yui.js to woo.whitespace.js. Here’s the new codebehind file:

Step 5: Still not happy? Change the extension names. If you don’t like the extensions that Chirpy uses to manhandle files, click Tools >> Options >> Chirpy. Here, you can change the file extensions to whatever suits your fancy. For demoing purposes, I’ll change “.whitespace.js” to “.w.js”:

Now, when I change my “woo.whitespace.js” file to “woo.w.js”, Chirpy still performs its magic:

Benefit 2: Translate DotLess Files.

Step 1: Install Chirpy. The latest version of Chirpy can be downloaded at Codeplex.

Step 2: Add a DotLess file to your project.. Name the file “woo.chirp.less”. Adding the “.chirp.less” suffix to our filename is Chirpy’s cue to look after the file. Right away, you’ll notice that Chirpy has adorned our new DotLess file with two (that’s right, count ‘em, two) “codebehind” files:

Step 3: Add DotLess crap to our DotLess file.. If you’re new to DotLess, check out the documentation. Here’s a little taste of the DRYer-than-css DotLess syntax:

Chirpy translates this DotLess craziness into valid css. The unminified version of the css can be found in the “woo.css” file:

And the minified version of the css can be found in the “woo.min.css” file:

Step 4: Change the file’s extension. Like the javascript extensions, you can change the “.chirp.less” extension to whatever you like by fiddling with the configuration settings in the Tools >> Options >> Chirpy menu. By default, even without changing any of Chirpy’s configuration settings, Chirpy will convert files with the “.chirp.less” and the “.chirp.less.css” extensions.

Benefit 3: Minify the crap out of CSS Files.

Step 1: Install Chirpy. The latest version of Chirpy can be downloaded at Codeplex.

Step 2: Add a css file to your project.. Name the file “coo.chirp.css”. Adding the “.chirp.css” suffix to our filename is Chirpy’s cue to look after the file. Right away, you’ll notice that Chirpy has adorned our new css file with a “codebehind” file:

Step 3: Write some css in your chirp.css file. The codebehind file will contain a minified version of your madness.

Here’s my unminified css file:

And here’s the minified css file that Chirpy autogenerated for me:

Benefit 4: Mash files together.

Step 1: Install Chirpy. The latest version of Chirpy can be downloaded at Codeplex.

Step 2: Add a config file to your project.. Name the file “mash.chirp.config”. Adding the “.chirp.config” suffix to our filename is Chirpy’s cue to look after the file.

Step 3: Specify what files you want to mash together. Here’s the syntax:

<root>
    <FileGroup Name="group1.js">
        <File Path="jquery-1.4.1.min.js" Minify="false" />
        <File Path="jquery.json.js" />
        <File Path="MicrosoftAjax.js" />
    </FileGroup>

    <FileGroup Name="group2.js">
        <File Path="jquery-1.4.1.min.js" Minify="false" />
        <File Path="jquery.json.js" />
    </FileGroup>

    <FileGroup Name="group1.css">
        <File Path="../Styles/jquery-ui-1.8.custom.css" />
        <File Path="../Styles/colorbox.css" />
        <File Path="howdy.chirp.less" />
    </FileGroup>
</root>

Step 4: Save the config file. As a result, three codebehind files will be created:

Step 5: Add folders to your config file (if you’d like). If you have a folder full of files that you’d like to mash together, you don’t have to list out each file. Instead, you can do something like this:

<root>
    <FileGroup Name="main.scripts.js">
        <Folder Path="/" Type="*.min.js" Minify="false"/>
        <File Path="MicrosoftAjax.js" />
    </FileGroup>
</root>

Benefit 5: Validate Javascript and DotLess files

Step 1: Screw up some of your coveted javascript. Assuming that you followed the steps for creating a yui.js file, go ahead and add some stupid code into your file. Maybe, eh, something stupidly awesome like this:

Step 2: Save your screw-up. Upon saving, you’ll notice a pleasantly annoying error message:

Step 3: Screw up some css in your DotLess file. Upon saving, you’ll receive yet another annoyingly friendly error message:

Benefit 6: Autorun T4 Templates

Step 1: Install Chirpy. The latest version of Chirpy can be downloaded at Codeplex.

Step 2: In Visual Studio, go to Tools >> Options >> Chirpy. You can tell Chirpy to auto-update T4 templates whenever you build your project:

Step 3: Get to know T4MVC. Granted, this feature may feel a wee bit out of place. But there’s a special place in my heart (and Wayne Brantley’s heart) for David Ebbo’s labor-of-love, T4MVC. So, Chirpy can auto-update T4MVC when you make a change to a pertinent MVC file (as discussed by Wayne here). To smart-run the T4MVC template, just make sure that the Smart Run T4MVC checkbox is checked:

That’s it! Chirpy says: Happy Coding!

In a somewhat elderly article, Karl Seguin suggests that all programmers should know Linux. And C. And memory management. And pointers. Karl stops just short of requesting that you cease making love to other people. But, if abstinence helps you become pseudo (homonymical pun intended) good at Linux, well then so be it. Stop making love. That’s why I stopped making love, in fact. Not because the demand for my love-making skills plummeted. But because I wanted to learn.

When we talk about “improving” our skills as knowledge-hungry developers, I find it interesting that we rarely mention the people in our lives (not Karl Seguin, alas) who we inevitably and repeatedly injure with our sloppiness: namely, designers. Yes, those people, over there, cloaked in Urban Outfitter attire, crying, listening to Bon Iver (or, like, whatever). We’re responsible for 90% of their personal anguish, and yet, when it comes time to improving ouselves, we dive deeper and deeper into the black subhuman vortex of pure, unadulterated, unstyled nerdiness, all while ignoring the needs and desires of our poor (though good-looking and well-dressed) designer. It’s time to change that.

Today, we’re going to make eye-contact. We’re going to try to feel the pain of the designer. We’re going to hug. And, in the end, we’re going to harness the power of MVC to make the life of our designer (or, in this case, the lives of ourselves) as easy as possible.

Step 1: Create an EditorTemplate folder. Place this folder in the Views/Shared subfolder. A.K.A.:

Step 2: Avoid touching others. Learn more about EditorTemplates before doing something ill advised. There are two amazingly helpful resources that you should devour before continuing here. First, read Brad Wilson’s multi-post series about MVC templates here. Second, read Elijah Manor’s post about opinionated template helpers here. That should get you better acquainted with the technical aspects of our magical journey.

Step 3: Create a design-friendly EditorTemplate. As mindblowingly awesome as Brad and Elijah’s proclamations are, I encountered some real trouble when I started to style the rendered output. I decided that each of my EditorTemplates should double as a design module. That way, when I want to change the look and feel of a form, I can swap out one EditorTemplate for another. Hopefully, as we go along, you’ll begin to see why this approach will make the design process a bit more manageable for us.

For starters, we’ll place the following code into a MVC partial, and we’ll save it as Grid3-6.ascx. Place Grid3-6.ascx into the newly created EditorTemplates folder. Simple enough. If you read Elijah’s post, you’ll notice that I stole a sizable chunk of this code from his helpful code snippet:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>

<div class="template">
<% if (ViewData.TemplateInfo.TemplateDepth > 1) { %>
    <%-- outlet for a shallow dive in a deep pool --%>
    <%= ViewData.ModelMetadata.SimpleDisplayText %>
<%
    } else {
        var data = ViewData.ModelMetadata;
        var template = ViewData.TemplateInfo;
        var properties = data.Properties.Where(m => m.ShowForEdit && !template.Visited(m));
%>
    <% foreach (var property in properties) { %>
        <% if (property.HideSurroundingHtml) { %>
            <%-- no label, no validation message, no skirt --%>
            <%= Html.Editor(property.PropertyName) %>
        <% } else { %>
            <div class="field">
                <span class="label grid-3">
                    <label for="<%: property.PropertyName %>"><%: property.DisplayName %>:</label>
                    <span class="req <%: property.IsRequired? "visible" : "invisible" %>">*</span>
                </span>

                <span class="input grid-6">
                    <%: Html.Editor(property.PropertyName) %>
                </span>

                <% if (!ViewData.ModelState.IsValidField(property.PropertyName)) { %>
                    <span class="validation grid-6 prefix-3">
                            <span class="error icon"></span>
                            <%: Html.ValidationMessage(property.PropertyName) %>
                    </span>
                <% } %>
            </div>
        <% } %>
    <% } %>
<% } %>
</div>

Notice that we’re taking advantage of our 960 grid system. For starters, our label will be 3 grid-lengths long, and the wrapper around our input field will be 6 grid-lengths long. Below the label and the input field, we’ll display a validation error message (if it exists). That validation message should be left-aligned with our input field. Also, as an added (though possibly unnecessary touch), required fields will be marked with a visible red asterisk. Unrequired fields will also be marked with a red asterisk, but those asterisks will be set to visibility:hidden, thus maintaining easy alignment.

Step 4: Update the FoodAdd page. If you’ve been following along, we’ve already done a considerable amount of work on our FoodAdd page. Time now for another quick, painless iteration:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage<FoodAdd>" %> 

<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    Big Fat Dish - Add a New Food
</asp:Content> 

<asp:Content ID="Content3" ContentPlaceHolderID="MainContent" runat="server">
    <div class="container-16 wrap">
        <div class="block">
            <h1>Add a New Food to Big Fat Dish</h1>

            <% Html.BeginForm(); %>
                <div id="add-image" class="grid-4">
                    <div id="image-input" class="new">Click to Add an Image</div>
                </div> 

                <%: Html.EditorForModel("Grid3-6") %>               

                <div id="add-food" class="grid-14 submit">
                    <input type="submit" value="Add Food" />
                </div>
            <% Html.EndForm(); %>
        </div>
    </div>
</asp:Content>

Step 5: Style your EditorTemplate. If the process of styling your EditorTemplate isn’t easy, or if the resulting styles aren’t reusable, you should consider reworking your EditorTemplate. For the sake of your designer. Because the goal here is to make the design process as easy and as modularized as possible. Because your designer is sensitive. And the EditorTemplate should be his friend.

To style my EditorTemplate, I downloaded the overly extensive Fugue Icon Set. I also did some peripheral styling. I added some fades, some borders, some margins, and some much-need padding. You know, designer stuff. All in all, you can tell that I’m a bit of a fanboy of the Envato Technique:

/* generic */
html, body
{
	background-color:#2c2a29;
	font-family: Helvetica, Geneva;
}

.hide
{
	display:none;
}

.invisible
{
	visibility:hidden;
}

ul.no-list li
{
	list-style-type:none;
}

.no-decor
{
	text-decoration:none;
}

/* containers */
.container-16.wrap
{
	border:1px solid #bbb;
	overflow:hidden;
}

.block
{
	border:1px solid #fff;
	overflow:hidden;
	background-color:#f6f6f6;
	padding:40px 0px 20px 60px;
}

/* frame */
#header, #navigation, #content, #footer-top, #footer-bottom
{
	overflow:hidden;
}

#header, #navigation, #footer-top, #footer-bottom
{
	color:#86806b;
}

#header a, #navigation a, #footer-top a, #footer-bottom a
{
	color:#cdc0a9;
	text-decoration:none;
}

#header
{
	height:60px;
	padding:5px 0px 10px 0px;
	background:#3b3b3b url("images/fades/fade_3b3b3b_1x199.png") repeat-x;
}

#navigation
{
	background:#4a4439 url("images/fades/fade_4a4439_1x32.png") repeat-x top left;
}

#navigation ul li
{
	padding-top:17px;
	border-left:1px solid #5e5749;
	height:33px;
	text-align:center;
	margin:4px 0px 2px 0px;
}

#navigation ul li.last /* last nav tab */
{
	border-right:1px solid #5e5749;
}

#content
{
	padding:40px 0px 50px 0px;
	background:#d2d1cf url("images/fades/fade_d2d1cf_1x190.png") repeat-x top left;
	border-bottom:1px solid #efefef;
}

#footer-top
{
	height:200px;
	background:#3b3630;
	border-top:1px solid #010000;
	border-bottom:1px solid #4e4a44;
}

#footer-bottom
{
	background:#2c2a28;
}

#footer-bottom
{
	padding-top:10px;
	height:60px;
	border-top:1px solid #232220;
	font-size:11px;
}

/* form elements */
.field
{
	overflow:hidden;
	margin-bottom:10px;
}

.field input, .field .label
{
	font-size:16px;
}

.field input
{
	/* TODO: handle checkboxes, etc */
	width:100%;
	border:1px solid #ccc;
}

.field .label
{
	text-align:right;
}

.field .req
{
	color:#aa2c2c;
}

.field .validation
{
	margin-top:5px;
	font-size:13px;
	color:#aa2c2c;
}

.field-validation-error
{
	display:block;
	float:left;
}

.icon
{
	margin-right:10px;
	display:block;
	float:left;
	width:16px;
	height:16px;
}

.error.icon
{
	background:transparent url("images/icons/fugue/exclamation-red.png") no-repeat;
}

.submit
{
	height:70px;
	margin:40px 10px 10px 10px;
}

.submit input
{
	height:100%;
	width:100%;
}

.button, .submit input
{
	border:none;
	text-align:center;
	background:#ea6e4c;
	color:#fff;
	font-size:35px;
	cursor:pointer;
	padding:10px 0px;

	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
}

/* home index */
#foods
{
	float:left;
	margin-top:10px;
}

#add-food
{
	margin:40px 10px 30px 10px;
}

/* add food */
#image-input
{
	text-align:center;
	font-size:16px;
	background:#efefef;
	width:100%;
	height:180px;
}

#image-input.new
{
	padding-top:20px;
	border:1px solid #ccc;
}

Step 6: Test out your designer-friendly template. Make sure that it looks acceptable in all of the standard browsers (I tend to care less about Internet Explorer’s feelings). Once you’ve done that, you can bask in the glory of all of your hard, hard work:

My design could surely still use a real designer’s touch. But, when that touch finally comes, it should be a swift and painless one. Like chocolate-coated dreams.

At the very least, our newly created, quasi-modularized design is definitely an improvement over our original page style (if I don’t say so myself):

Now, with a little bit of elbow grease, we can easily create as many EditorTemplates as we desire.

But, first, it might not be a bad idea to buy your favorite designer some tropical flowers. Or a copy of Objectified. Or, that movie about Helvetica. Or, a firm manly hug. Or, a letter. Or, a copy of Linux for Designers.

Move on to The Big Boy MVC Series — Part 25, Going Postal: ActionFilters, Moq, ModelState, Oh My!

Whoo. It’s been awhile. Apologies for that. I’ve been looking for a new place to live in Honolulu, and the whole process has turned out to be an uphill battle (thanks for asking). It appears that real estate brokers don’t really like it too much when you fill in the “Sex: ___________” blank with “OFFENDER“.

Some of you might have died between Part 22 and Part 23. That’s okay. For those of you who are still sentient and coherent and death-free, you’ll remember that, in Part 22, we set up our ViewModel layer, and we mapped our FoodAdd ViewModel to our Model Food class (which was autogenerated by Linq 2 SQL). Remember? If not, go ahead and take a stroll down memory lane.

Today, we’re going to handle our first Http Post. Since, like cheese, you’ve aged (and learned some stuff) as we’ve trekked along on this journey of ours, I’m going to provide more code and less banter in this post. Or, maybe not.

Step 1: Make some small changes to your dbml file and your database. I destroyed the States table, I cleaned up the column names, I added permalink columns to each table, and I added a Points table. These small changes will help us keep our downstream code so fresh and so clean. Also, if you’re skillfully building your application, these minor tweaks should be super easy to implement. If they’re not, you’re probably suffering from a good ol’ case of spaghetti fever. Lasagna:

Step 2: Design a permalink generator. All the cool kids are doing it. And, like a cool kid, we want to be able to feed our permalink generator a stupid string like “Hub’s Hot Dog H3X##~~0rFest”, and, in turn, we want our permalink generator to spit out a clean url-friendly string like “hubs-hot-dog-h3x0rfest”. Easy enough, eh? Heck, if it’s that easy maybe you should try to create this permalink generator all by your big-boy self, eh? Your version might suck much less than mine. And, if it does, please e-mail it to me. Or, if it doesn’t, feel free to steal mine.

Already finished? Well, okay then. Let’s compare biceps.

Here are my unit tests:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.Tests.Models
{
    [TestClass]
    public class PermalinkTest
    {
        [TestMethod]
        public void Models_Permalink_For_Trims_Spaces()
        {
            string title = "    hello-there     ";
            string permalink = Permalink.For(title);
            Assert.AreEqual("hello-there", permalink);
        }

        [TestMethod]
        public void Models_Permalink_For_Delimits()
        {
            string title = "here is my title";
            string permalink = Permalink.For(title);
            Assert.AreEqual("here-is-my-title", permalink);
        }

        [TestMethod]
        public void Models_Permalink_For_Converts_To_LowerInvariant()
        {
            string title = "HeRe";
            string permalink = Permalink.For(title);
            Assert.AreEqual("here", permalink);
        }

        [TestMethod]
        public void Models_Permalink_For_Trims_Inner()
        {
            string title = "here  is    my      title";
            string permalink = Permalink.For(title);
            Assert.AreEqual("here-is-my-title", permalink);
        }

        [TestMethod]
        public void Models_Permalink_For_Removes_NonAlphanumeric_Chars()
        {
            string title = "Mr. Jim Lives in Room 1,209----ok?";
            string permalink = Permalink.For(title);
            Assert.AreEqual("mr-jim-lives-in-room-1209-ok", permalink);
        }

        [TestMethod, ExpectedException(typeof(ArgumentNullException))]
        public void Models_Permalink_For_Throws_Null_Argument_Error_When_Null()
        {
            string error = Permalink.For(null);
        }

        [TestMethod, ExpectedException(typeof(ArgumentNullException))]
        public void Models_Permalink_For_Throws_Null_Argument_Error_When_Empty()
        {
            string error = Permalink.For(string.Empty);
        }

        [TestMethod]
        public void Models_Permalink_For_Generates_Permalinks_For_NonalphaNames()
        {
            string name = Permalink.For("###", ifEmptyUse:"permalink");

            Assert.IsNotNull(name);
            Assert.AreEqual(name, "permalink");
        }
    }
}

And here is my Permalink Generator:

using System;
using System.Text.RegularExpressions;

namespace Big.Fat.Dish.Models
{
    public static class Permalink
    {
        static Regex nonAlphanumeric = new Regex(@"[^\w\d\s\-]+", RegexOptions.Compiled);
        static Regex spacesAndDashes = new Regex(@"[\s\-]+", RegexOptions.Compiled);

        public static string For(string value, string delimiter = "-", string ifEmptyUse = "#")
        {
            if (string.IsNullOrEmpty(value))
            {
                throw new ArgumentNullException("value");
            }

            string alpha = nonAlphanumeric.Replace(value, string.Empty).Trim().ToLowerInvariant();
            string delimitedAlpha = spacesAndDashes.Replace(alpha, delimiter);

            if (string.IsNullOrWhiteSpace(delimitedAlpha))
            {
                return ifEmptyUse;
            }
            else
            {
                return delimitedAlpha;
            }
        }
    }
}

Step 3: Design a server-side geocoder. A whaaaa?

This is a bit trickier. In fact, this might be the “trickiest” piece of code that we’ve written thus far, or that we’ll ever write in this measly little pea-brained application of ours. Hence, to accomplish this feat of strange brilliance, you’ll need to have a basic understanding of JSON Serialization. And you’ll also need to get pretty cozy with the Google Maps API. So, get cracking.

We’re going to make a WebRequest to Google. When we make our web request, we’re proverbially asking Google if we can come over, chat about soccer, and make sweet sweet love on the beige ottoman. e.g.:

I should stop here for a second and disclose an important legal disclaimer: since we’re grabbing and parsing geocoding data from grandfather Google, we can only use that data for Google Mapping purposes. And, as the TOS explicitly states, we’re legally obliged to regularly update this data such that the data, at any given point, is “temporary”. That should hopefully keep our project on the borderline of “non-prostitutory” and “legit”–and, thus, with any luck, we won’t find ourselves embroiled in a David/Goliath battle with the ol’ internet giant. If we do, we can always run. Like a girl. Or, we can just go ahead and start using Bing Maps.

Like always, let’s start with some unit tests. When building our geocoding unit tests, we need to make sure that we don’t make a real WebRequest. Google (long wind, sleeping giant) wouldn’t like that. So, instead, we’ll use RhinoMocks to mock out a fake WebRequest, which we’ll use to return a (fake) serializied JSON string that our geocoder can fiddle with.

using System.IO;
using System.Web.Script.Serialization;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Rhino.Mocks;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.Tests.WebRequests.Geocoding
{
    [TestClass]
    public class GeocoderTest
    {
        MockRepository mocks;
        IGeocoder geocoder;
        IWebRequestWrap request;
        JavaScriptSerializer serializer;

        const string anyString = "pointless";
        GeoAddress deserializedAddress = new GeoAddress
        {
            Status = new Status
            {
                Code = GeoResponse.Success,
                Request = "geocode"
            },
            Placemark = new Placemark[]
            {
                new Placemark
                {
                    AddressDetails = new AddressDetails
                    {
                        Country = new Country
                        {
                            AdministrativeArea = new AdministrativeArea
                            {
                                AdministrativeAreaName = "WA",
                                SubAdministrativeArea = new SubAdministrativeArea
                                {
                                    Locality = new Locality
                                    {
                                        LocalityName = "Seattle",
                                        Thoroughfare = new Thoroughfare
                                        {
                                            ThoroughfareName = "111 Seattle WA 98116"
                                        },
                                        PostalCode = new PostalCode
                                        {
                                            PostalCodeNumber = "98116"
                                        }
                                    }
                                }
                            }
                        }
                    },
                    Point = new GeoPoint
                    {
                        Coordinates = new float[]
                        {
                            100,
                            -100
                        }
                    }
                }
            }
        };

        [TestInitialize]
        public void Init()
        {
            mocks = new MockRepository();
            request = mocks.DynamicMock<IWebRequestWrap>();
            serializer = new JavaScriptSerializer();

            string serializedAddress = serializer.Serialize(deserializedAddress);
            request.Stub(m => m.GetResponseAsString(Arg<string>.Is.Anything)).Return(serializedAddress);

            geocoder = new Geocoder(request);
            mocks.ReplayAll();
        }

        [TestCleanup]
        public void TestCleanup()
        {
            mocks.VerifyAll();
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_Line1()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual("111 Seattle WA 98116", returnedAddress.Line1);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Line2_Is_Null()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.IsNull(returnedAddress.Line2);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_City()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual("Seattle", returnedAddress.City);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_State()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual("WA", returnedAddress.State);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_PostalCode()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual("98116", returnedAddress.PostalCode);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_Point_Longitude()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual(100, returnedAddress.Point.Longitude);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_Point_Lattitude()
        {
            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.AreEqual(-100, returnedAddress.Point.Latitude);
        }

        [TestMethod]
        public void WebRequests_Geocoder_GetAddressFromString_Returns_Null_On_Error()
        {
            deserializedAddress.Status.Code = GeoResponse.BadKey;
            Init();

            Address returnedAddress = geocoder.GetAddressFromString(anyString);
            Assert.IsNull(returnedAddress);
        }
    }
}

Alrighty. Let’s start building! First, we need to create a wrapper for our WebRequest. In a similar flash of passion, we spent some time a few days ago wrapping up our frisky DataContext. For now, with our WebRequestWrap class, we really only need to expose one method. He’s a lonely fellow:

namespace Big.Fat.Dish.WebRequests
{
    public interface IWebRequestWrap
    {
        string GetResponseAsString(string uri);
    }
}

And our implementation:

using System.Net;
using System.IO;

namespace Big.Fat.Dish.WebRequests
{
    public class WebRequestWrap : IWebRequestWrap
    {
        public string GetResponseAsString(string uri)
        {
            var request = WebRequest.Create(uri);
            var response = request.GetResponse();
            string responseAsString;

            using (var stream = response.GetResponseStream())
            using (var reader = new StreamReader(stream))
            {
                responseAsString = reader.ReadToEnd();
            }

            return responseAsString;
        }
    }
}

Next, let’s create our Geocoder class. Here’s the interface:

using Big.Fat.Dish.WebRequests.Geocoding.Deserialized;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.WebRequests.Geocoding
{
    public interface IGeocoder
    {
        Address GetAddressFromString(string address);
    }
}

And the Geocoder class:

using System.Web.Script.Serialization;
using Big.Fat.Dish.WebRequests.Geocoding.Deserialized;
using Big.Fat.Dish.WebRequests;
using Big.Fat.Dish.Models;

namespace Big.Fat.Dish.WebRequests.Geocoding
{
    public class Geocoder : IGeocoder
    {
        const string MapKey = "GetYourOwnMapKey,Buddy";
        const string MapUrl = "http://maps.google.com/maps/geo?q={0}&output=json&oe=utf8&sensor=false&key={1}";

        IWebRequestWrap webRequest;

        public Geocoder() : this(new WebRequestWrap()) { }
        public Geocoder(IWebRequestWrap webRequest)
        {
            this.webRequest = webRequest;
        }

        GeoAddress Geocode(string streetAddress)
        {
            //handle null address
            if (string.IsNullOrEmpty(streetAddress)) return null;

            //get json response
            string url = string.Format(MapUrl, streetAddress, MapKey);
            string response = webRequest.GetResponseAsString(url);

            //serialize response
            try
            {
                var serializer = new JavaScriptSerializer();
                var jsonAddress = serializer.Deserialize(response);

                return jsonAddress;
            }
            catch
            {
                return null;
            }
        }

        public Address GetAddressFromString(string streetAddress)
        {
            var geo = Geocode(streetAddress);
            if (geo == null || geo.Status == null || geo.Status.Code != GeoResponse.Success)
            {
                return null;
            }

            try
            {
                var placemark = geo.Placemark[0];
                var adminArea = placemark.AddressDetails.Country.AdministrativeArea;
                var locality = adminArea.SubAdministrativeArea.Locality;
                var coords = placemark.Point.Coordinates;

                return new Address
                {
                    Line1 = locality.Thoroughfare.ThoroughfareName,
                    Line2 = null,
                    City = locality.LocalityName,
                    State = adminArea.AdministrativeAreaName,
                    PostalCode = locality.PostalCode.PostalCodeNumber,
                    Point = new Point
                    {
                        Longitude = coords[0],
                        Latitude = coords[1]
                    }
                };
            }
            catch
            {
                return null;
            }
        }
    }
}

The only missing piece of this big, bad puzzle: the GeoAddress class (& crap), which our deserializer fills to the brim with spicy geocoding data. I’ve included all of the classes below, so hopefully you get the idea. Don’t blame me for the class-count here; blame Google:

GeoAddress

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class GeoAddress
    {
        public Placemark[] Placemark { get; set; }
        public Status Status { get; set; }
    }
}

Placemark

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class Placemark
    {
        public GeoPoint Point { get; set; }
        public AddressDetails AddressDetails { get; set; }
    }
}

Status

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class Status
    {
        public GeoResponse Code { get; set; }
        public string Request { get; set; }
    }
}

GeoPoint

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class GeoPoint
    {
        public float[] Coordinates { get; set; }
    }
}

AddressDetails

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class AddressDetails
    {
        public Country Country { get; set; }
    }
}

Country

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class Country
    {
        public AdministrativeArea AdministrativeArea { get; set; }
    }
}

AdministrativeArea

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class AdministrativeArea
    {
        public string AdministrativeAreaName { get; set; }
        public SubAdministrativeArea SubAdministrativeArea { get; set; }
    }
}

SubAdministrativeArea

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class SubAdministrativeArea
    {
        public Locality Locality { get; set; }
    }
}

Locality

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class Locality
    {
        public string LocalityName { get; set; }
        public Thoroughfare Thoroughfare { get; set; }
        public PostalCode PostalCode { get; set; }
    }
}

Thoroughfare

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class Thoroughfare
    {
        public string ThoroughfareName { get; set; }
    }
}

PostalCode

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public class PostalCode
    {
        public string PostalCodeNumber { get; set; }
    }
}

GeoResponse

namespace Big.Fat.Dish.WebRequests.Geocoding.Deserialized
{
    public enum GeoResponse
    {
        Success = 200,
        BadRequest = 400,
        ServerError = 500,
        MissingQuery = 601,
        MissingAddress = 601,
        UnknownAddress = 602 | 604,
        UnavailableAddress = 603,
        BadKey = 610,
        TooManyQueries = 620
    }
}

Step 4: Run the tests. Feel the Purple Rain. Our geocoder works. Our permalink generator works. Our hearts are almost completely mended (you may not realize it yet):

Move on to Part 24: Dear EditorTemplates, Are We Done Posting Yet?.