Wait!? Ignore It!?

You heard that right! I prefer to ignore my own site as much as possible. I've learned over the years that if I have to babysit my own servers and services, then I am doing things wrong. This is simple economics. I don't get paid directly for operating The BrainDonor Network. Whenever I write new posts, compose tweets, or push commits I am spending my personal time. System administration is unfortunately not something that I enjoy—so I prefer to avoid it whenever possible and whenever I'm confident that it will not expose me to significant risks.

What pushed me to this attitude for my own site was the "War on Spam". There was a time when I took great pride in having the hardware that hosted The BrainDonor Network sitting in my office at home. Everything was hosted here: web, email, chat, games, music, etc. This was a ton of fun and a great way for me to keep up to date on how to run an online presence for other businesses. Unfortunately, it was getting harder every year to keep in touch with those businesses. I was spending a couple hours a month just making sure that my email would go through. At this point, I finally had enough and decided to host my email someplace where I knew it wouldn't be blocked lightly—Google. With email already offloaded to the cloud, I was quick to take advantage of affordable virtual private server hosting that rolling out.

What Did Slicehost Do Wrong?

Slicehost really didn't do anything wrong. They're parent company—Rackspace—also didn't really do anything wrong. No matter the hype and marketing, Rackspace excels at provided managed dedicated hosting. Their cloud offerings have continued to be a secondary service. Up until recently, Rackspace even had separate support teams. This caused me all kinds of professional hilarity when trying to deploy solutions to their hybrid hosting. You literally had to demand a conference call to get everyone on the phone to get things fixed—wasting an enormous amount of everyone's time.

Another significant reason for me to make the switch was to refresh the infrastructure. I've replaced Apache with nginx and mod_php with FastCGI. I've also cut out a lot of technology pieces that I wasn't using: phpmysql, postgres, mod_python, etc. Sure, all of the old data is backed-up and stored...but I'm confident that I won't need it operational any time soon. I've always found it infinitely easier to just start fresh than to actually clean up a server. I also wanted to switch away from Ubuntu.

Why Amazon Web Services?

Amazon offers an absolutely dizzying array of services on their cloud platform and their prices are continually setting the bar for cloud computing. I'm also not all that afraid of vendor lock-in with them. I know I can get everything here set up and restored on a new cloud provider in just a matter of hours—even if Amazon were to go completely dark.

Installing MongoDB

There is no lack of information on how to get MongoDB up and running on a windows machine. The main MongoDB website has a great quickstart guide. This guide will enable you to get MongoDB installed and running locally and provides the necessary information to run MongoDB as a service. I prefer to start up MongoDB manually and avoid running it as a service on my development machine.

Starting Your Website Project

Now that you have MongoDB up and running on your machine, you can launch Visual Studio and create a new empty ASP.NET MVC3 project. Once Visual Studio has created and opened the new project, launch NuGet and install FluentMongo. FluentMongo will also install the mongo-csharp-driver.

We are installing FluentMongo because the core mongo-csharp-driver does not have LINQ support just yet. It will be coming in the next major version which should happen in a couple of months. Once this new version is out, this guide will still be relevant—I'll just update everything to make sure that everything works with the new LINQ support. FluentMongo isn't a perfect solution, but it does give you enough of a familiar environment that you can ease into MongoDB without introducing the query language running under the hood until you are ready.

Create an Initial Skeleton

We can put this project together quickly with just a single model, controller and view. We'll start with the model, Models\Record.cs. We're giving this object three fields: the primary key (_id), a text field, and a datetime field. Each document of a MongoDB collection is assigned an ObjectId in the _id field. This key will be randomly generated when a record is inserted into MongoDB.

using MongoDB.Bson;

public class Record
{
    public ObjectId _id { get; set; }
    public string SomeRandomText { get; set; }
    public DateTime RecordDate { get; set; }
}

Our controller initially just needs two actions: an index to list all of the records, and an action to create a new record based on text supplied by the user. We'll fill in the details of Controllers\HomeController.cs later.

using MongoDB.Bson;
using MongoDB.Driver;
using MongoDB.Driver.Builders;
using FluentMongo.Linq;

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult CreateRecord(string SomeRandomText)
    {
        return RedirectToAction("Index");
    }
}

Finally, we'll add our view, Views\Shared\Index.cshtml. This view will include the form to create a new record. As the controller will create the record and redirect back to the index action, we don't need more than this initial view.

<h2>List of Records</h2>

<p>placeholder</p>

<h2>Insert New Record</h2>

@using (Html.BeginForm("CreateRecord", "Home"))
{
    <label>Some Random Text:</label>
    @Html.TextBox("SomeRandomText")
    <input type="submit" value="Create New Record" />
}

With that done, we can go ahead and start our web application:

Creating Data in MongoDB

Our interaction with MongoDB will start with populating the CreateRecord action. This method is pretty straightforward: we connect to mongo, create a new record, and save the record. I'm sure you will notice that I have not performed two actions that would have been absolutely necessary if we were using SQL Server: create the FluentMongoExample database and the Record table. MongoDB will create all databases and collections as they are are required by queries. Seeing this for the first time really drives home the full impact of using a schema-less database.

public ActionResult CreateRecord(string SomeRandomText)
    {
        MongoDatabase database = MongoDatabase.Create("mongodb://localhost/FluentMongoExample");
        MongoCollection collection = database.GetCollection("Record");

        Record record = new Record();

        record.SomeRandomText = SomeRandomText;
        record.RecordDate = DateTime.Now;

        collection.Save(record);

        return RedirectToAction("Index");
    }

Now that we are able to create new records, we can start listing all records. Querying our records with Fluent Mongo is virtually identical to how we would normally select records using LinqToEntities or LinqToSQL.

public ActionResult Index()
    {
        MongoDatabase database = MongoDatabase.Create("mongodb://localhost/FluentMongoExample");
        MongoCollection collection = database.GetCollection("Record");

        IQueryable records = from r in collection.AsQueryable() select r;

        return View(records);
    }

With the controller updated, we just need to update the Index view so that it uses the IQueryable<Record> model that our index controller is passing. I'm just using a simple for loop in a table for this example. Most of the WebGrid are supported by FluentMongo—but not all.

@model IQueryable<Record>

<h2>List of Records</h2>

<table cellspacing="3" cellpadding="3">
<tr>
    <th>_id</th>
    <th>SomeRandomText</th>
    <th>RecordDate</th>
</tr>
@foreach (Record record in Model)
{
    <tr>
        <td>@record._id</td>
        <td>@record.SomeRandomText</td>
        <td>@record.RecordDate</td>
    </tr>
}
</table>

With everything updated, we can rebuild or application and enter some records:

Deleting Data in MongoDB

Deleting data from MongoDB gets a touch more complicated. To illustrate th issue, we'll add the stubs to delete a record from our MongoDB collection.

In Controllers\HomeController.cs:

    public ActionResult DeleteRecord(ObjectId record_id)
    {
        return RedirectToAction("Index");
    }

In Views\Shares\Index.cshtml:

    <tr>
        <td>@record._id</td>
        <td>@record.SomeRandomText</td>
        <td>@record.RecordDate</td>
        <td>
            @Html.ActionLink("Delete", "DeleteRecord", new { record_id = record._id })
        </td>
    </tr>

If we click our new delete button, we get the following exception:

We get this exception because the ASP.NET MVC framework does not understand how to properly convert a BSON ObjectId to and from a string. We need to provide a model binder for the ObjectId.

In Models\Record.cs:

using System.Web.Mvc;

public class ObjectIdBinder : IModelBinder
{
    public object BindModel(ControllerContext controller_context, ModelBindingContext binding_context)
    {
        ValueProviderResult result = binding_context.ValueProvider.GetValue(binding_context.ModelName);
        return new ObjectId(result.AttemptedValue);
    }
}

In Global.asax.cs:

        protected void Application_Start()
        {
            ModelBinders.Binders.Add(typeof(ObjectId), new ObjectIdBinder());

            AreaRegistration.RegisterAllAreas();

            RegisterGlobalFilters(GlobalFilters.Filters);
            RegisterRoutes(RouteTable.Routes);
        }

With the binder added, we are able to successfully trigger our delete action and be redirected back to the index.

Documents are deleted from a mongo collection by providing a query that will match the documents to be deleted. This is not something that is provided by FluentMongo—we must use a native MongoDB query. Luckily, this is very easy to do. The native MongoDB queries provide a much more controlled and robust means of interacting with MongoDB, but we're interested in quick and simple for this tutorial.

    public ActionResult DeleteRecord(ObjectId record_id)
    {
        MongoDatabase database = MongoDatabase.Create("mongodb://localhost/FluentMongoExample");
        MongoCollection<Record> collection = database.GetCollection<Record>("Record");

        Record record = (from r in collection.AsQueryable() where r._id == record_id select r).FirstOrDefault();

        if (record != null)
        {
            collection.Remove(Query.EQ("_id", record._id));
        }

        return RedirectToAction("Index");
    }

With the delete action finished, we have a working data-driven application.

I have added my project to GitHub so that you can download and start tinkering yourself. Enjoy!

Is a jQuery Object an Array?

For any selection that you make, such as $('.button'), a jQuery object is returned. This allows you to do a variety of tasks based on what is returned in the selector.

if ($('.button').length > 0) {
...
}

You can also iterate through the contents of the jQuery object:

var selection = $('.button');
foreach(i = 0; i < selection.length; ++i) {
    selection[i].html('button #' + (i+1));
}

Despite all of this behavior, the jQuery object cannot be treated as a true JavaScript array. It is missing the first-class functions that we expect from a true array such as .push() or .pop(). The jQuery documentation often refers to this object as the matching set. I prefer this technology as it follows the behavior of sets and functions in abstract math—that sets are immutable and functions return new sets.

Starting a Chain

To understand the importance of this array-like behavior, we can look at the jQuery API documentation for .addClass(). This function returns a jQuery object—which contains the set of elements on which we called it. Unless the jQuery function modifies the matched set it was called against, returning a jQuery object implies that it is returning the original set. Even functions such as .first() or .last() return a set—it just contains a single object.

I typically define a chain as linking two or more jQuery functions together in a single statement as defined by the semicolon. In Part 1, I used this chaining to select elements from the scope I passed to my jQuery function:

scope.find('.button')
    .click(function(){
        alert("You Clicked The Button!");
    });

I will place any chained function on a new, indented line when one of the following conditions have been met:

1. The function being chained has a functioned embedded as one of the arguments.
2. The function being chained would create a line that would wrap in my editor.
3. Another function in the chain is on a new, indented line.

I'm sure you'll notice that I did not give an explicit number of characters to a long line of code. I have used far too many tools and editors to give you a 'best' number. This number should already be something that your team is aware of in the rest of the development for a project.

Putting it Into Practice

I am a firm believer that this can, and should be taken further. Take this example, where the same set of selections need multiple event handlers:

scope.find('div.vehicle-button a').hover(
    function(){
        $(this).parent().addClass('vehicle-button-hover');
        $(this).parent().find('div.button').addClass('button-hover');
    },
    function(){
        $(this).parent().removeClass('vehicle-button-hover');
        $(this).parent().find('div.button').removeClass('button-hover');
    }
);
scope.find('div.vehicle-button a').mousedown(function(){
    $(this).parent().find('div.button').addClass('button-click');
});
scope.find('div.vehicle-button a').mouseup(function () {
        $(this).parent().find('div.button').removeClass('button-click');
});

I find the above code disorganized and inefficient. We are making multiple calls to .find() and $(this). Further, you can remove any single statement from the above and alter the behavior of the code dramatically. I can organize the above int a single, chained statement:

scope.find('div.vehicle-button a')
    .hover(
        function () {
            $(this).parent()
                .addClass('vehicle-button-hover')
                .find('div.button')
                .addClass('button-hover');
        },
        function () {
            $(this).parent()
                .removeClass('vehicle-button-hover')
                .find('div.button')
                .removeClass('button-hover');
        }
    )
    .mousedown(function () {
        $(this).parent()
            .find('div.button')
            .addClass('button-click');
    })
    .mouseup(function () {
        $(this).parent()
            .find('div.button')
            .removeClass('button-click');
    });

Each line after the chain begins indents to illustrate the depth and links of the chain. Instead of 3 statements, we have a single statement with the top line furthest to the left. If we pick any line in the code, we can quickly and easily identify what is happening and all other related events by looking up and to the left.

One thing I must mention is that while I find the above code much easier on the eyes, it is space-inefficient. Properly structured JavaScript code will always be space-inefficient. If you want space-efficient JavaScript, you had better start looking at minifiers and not trying to optimize things on your own. As most of my web development is on the .NET platform, Chirpy to minify and bundle my JavaScript files.

Keeping the Chain from Breaking

Any time we need to perform certain operations, the chain can come to a halt. Say for instance we want to increase the height of all of the vehicle buttons by 5 pixels. This is where we use .each() to keep the chain alive.

scope.find('div.vehicle-button a')
    .each(function(){
        $(this).height($(this).height() + 5);
    })
    .hover (
    ...

For the fully informed, this could have been done with .css('height', '+=5'). I just couldn't think of another example off the top of my head.

One caveat with using .each() is that you still must pay close attention to the scope you are working in—the same as in any other anonymous function that you pass into a jQuery function. This could potentially be another piece of my jQuery Best Practices guide, but won't be visited again for a while. The next chapter of my guide will be how to handle insert elements into the DOM.

I currently have a huge crush on Twitter's Bootstrap project. It's the first "grid system" that I have used that felt like it was created by a developer instead of a designer. Even more importantly, it provides a very application-centered set of components that can be leveraged in a web application. I have been leveraging that last aspect in custom back-ends for some of the websites I build during the day. It was only natural that I begin using it in my personal projects—and now to start including it on the front-end.

The new look isn't just aesthetic…it is responsive as well. This website will now reform itself to accomodate mobile devices and older browsers seamlessly! This is yet another offering of Bootstrap—the responsive layout. I think it does a great job except for some font issues. I read a lot of RSS-aggregated news on my mobile devices and wanted to make sure I could read my own blog easily from my phone. There is also the added benefit of having implemented a responsive layout and being able to do so for others. I can't say that I understand everything that is going on under the hood…but I'm getting there.

There are quite a few rough edges in the theme—with the comments first-and-foremost on my mind. I'll keep working on everything and should have everything smoothed out in a week or so.

The primary reason I started looking at NoSQL do to it being an emerging trend. I've used 'alternative' data stores previously, such as memcached...but that was always in support of an RDBMS. All it took was the right project to come past my desk, and I knew I had to take a crack at it. I'm just finishing up a project at my day job geared towards event messaging. Without disclosing any real details (and I can't...sorry) I can say that the platform needs to be able to process high volume, have the ability to scale up, and even the ability to scale down. This platform is ASP.NET MVC3 on the front-end and MongoDB on the back-end.

Why MongoDB?
I've actually been following MongoDB since version 1.4 and playing around with its interactive shell and seen it grow considerably. The community of professionals using MongoDB has grown even more so. Best-practices in operations and architectures have been established and documented and the commercial company behind MongoDB, 10gen, is growing strong. What sealed the deal for me was the push to ensure that MongoDB was a dependable backend for almost any development language. Just take a peek at the Drivers page.

Enough of the soft reasons! Those just help me sell it to my partners in crime. Here are some of the features of MongoDB and why I find them valuable. If it's not listed, it's not that I don't care. All features are coming from the MongoDB website.

• Document-Oriented Storage
  In my development, this feature is all about code-first. My domain objects are simply serialized and stored in MongoDB. I don't have to worry about updating tables, constraints or relationships. I've included the repository model I'm using in my BrainDonor.Mongo project.
  
  
• Replication & High Availability
  For me, this feature is all about being able to scale both up and down quickly, and easily. A replication set can actually be entirely replaced without taking the databases offline. I'm also looking forward to trying out some of the WAN replication on AWS between different zones.
  
  
• Fast In-Place Updates
  Updating a document can be done two different ways. You can update the entire document or you can update only a single field. Updating a document is not an atomic operation--but updating a single field is. The single field operation that caught my attention immediately was the increment operation and how I could use it in a data reporting application.
  
  
• GridFS
  I want to build/use a CMS that uses this! Even better, I want to be able to sync everything with a CDN.

For what I am building right now, MongoDB is a great fit. And if trends continue, I'm confident that I will be using more NoSQL storage engines in the coming years. They are definitely not one-size-fits-all solutions.

Why ASP.NET MVC3?
I get asked this question a lot even without the addition of NoSQL. With all my experience with Open Source tools, why am I continuing to use C#?

• Web Development is Polyglot Development
  Any rich web application will have JavaScript, HTML, and CSS regardless of the underlying platform. This is compounded when you start introducing tools such as SASS, LESS, CoffeeScript, etc. These applications are also not running in isolation. How many external services did your last application integrate with? There are countless reasons to integrate with social media, ecommerce, advertising and CRM systems. How many of those are well documented for the back-end language you are developing with?
  
  
• ASP.NET Finally Understands Open Source
  With packages such as NuGet, I have a rich collection of libraries and utilities at my fingertips. Microsoft is also not reinventing the wheel with their MVC framework. It is very clear that the development team has been using and following other languages and MVC frameworks. I am constantly using new, open source utilities as I build applications.
  
  
• I Am Not Locked In
  My application most definitely is locked into the Microsoft stack...but I am not. I have built and launched web applications in C#, Perl, PHP, Python, C++, C, and even an old Bash CGI powered site in my history. Java and Ruby aren't in that list...but how long would it take me to get up to speed building an MVC application with either of those? Java maps very closely to C# and Ruby maps very closely to Python. In fact, I have only had one job that used a single stack exclusively.
  
  Wait...is this a worthy business reason? Yes! I'm a firm believer that mono-culture web development teams are a recipe for disaster. Teams of polyglot developers aren't just agile with how they build a single application—they are agile in how they even think about building web applications. These teams will usually program in one stack at a time, but switching stacks is never off the table.

Back to coding with me!

The Problem of Scope

Every developer I have talked to uses the following standard $(document).ready() invocation:

$(document).ready(function()
    $('.button').click(function(){
        alert("You Clicked The Button!");
    });
});

This invocation assumes one very significant behavior: You will only be altering your DOM at page load...ever. I cannot stress enough how nasty of an assumption this is. In almost any modern web application, the DOM is going to be changing after the page load. I see countless developers encounter this when they first start looking at AJAX interactions using jQuery. Their first reaction is almost always the same: run the $(document).ready() again...and hilarity ensues. Not the good kind of hilarity...but the kind where it honestly feels like the browser itself is laughing at you.

The next step that many people take is to execute the necessary jQuery as part of the AJAX success handler like so:

$.ajax({
    type: 'POST',
    url: 'http://mysite.com/ajaxurl',
    success: function(data) {
        $('.data-target').html(data);
        $('.data-target .button').click(function(){
            alert("You Clicked The Button!");
        });
    }
});

Everything is now behaving as expected. Unfortunately this behavior has come at the cost of a blatant DRY(Don't Repeat Yourself) violation.

How To Manage Scope

How I manage the scope of my jQuery scripts is founded on the following jQuery statements being equivalent:

$('.button').click(function(){
    alert("You Clicked The Button!");
});

$(document).find('.button').click(function(){
    alert("You Clicked The Button!");
});

In the first, I added the click handler in the standard manner. In the second, I searched for the button class in the document. These form the basis for my best practices because the second allows you to control the scope of the DOM that is being altered. You can explicitly focus the scope of your jQuery by wrapping your script in the a function:

function my_button_jquery(scope){
    scope.find('.button').click(function(){
        alert("You Clicked The Button!");
    });
}

Given this function, we can quickly rewrite the document ready from the first example script like so:

$(document).ready(function()
    my_button_jquery($(this));
});

And rewrite the ajax call in a similar manner:

$.ajax({
    type: 'POST',
    url: 'http://mysite.com/ajaxurl',
    success: function(data) {
        $('.data-target').html(data);
        my_button_jquery($('.data-target'));
    }
});

If you are one of the dozen people or so that ready my post on jQuery and ASP UpdatePanel Integration you will recognize what I am doing here.

When to Break Scope

Now that we have additional control over the primary scope of our jQuery script, we need to understand where things are going to break. The scope variable will only be reliable within the my_button_jquery function. You must assume that this scope will be broken any time you enter into an anonymous function. The reason for this is the asynchronous nature of the JavaScript event model.

This is why the above ajax call is not written with a scope inside the success handler:

    success: function(data) {
        scope.find('.ajax-form-wrapper').html(data);
        my_button_jquery(scope.find('.ajax-form-wrapper'));
    }

Notes on Efficiency

You should always invoke the jQuery object outside of your function to improve efficiency:

$(document).ready(function () {
    my_button_jquery($(this));
});

Not:

$(document).ready(function () {
    my_button_jquery(document);
});

Invoking a variable through jQuery is an expensive task that should only be performed once. Many other bloggers have mentioned storing the result of $(this) in a variable to avoid repeated and unnecessary calls to the jQuery object. I'm not a strict follower of that pracitice—because I am more than willing to knowingly introduce inefficiencies into executing to improve maintainability. Instead I go for the low-hanging fruit such as invoking jQuery outside of my scoped initializer.

The other area where scoping can be inefficient is in the number of jQuery selections that will not perform any action. Consolidating all of you script into a scoped initializer means that they will all be executed if an AJAX call updates the DOM. I will cover this in my next post—which will cover chaining and flow control.

I built the example administration pages in my MongoDB membership provider project as shown here. It is a small, three controller area in the project that uses Bootstrap for all of its look and feel. I am using all of the standard Razor html controls for the form elements with the form styled according to the Bootstrap Base CSS.

Here is the CSHTML source for the username field:

        <div class="control-group">
            @Html.LabelFor(x => x.Username)
            <div class="controls">
                @Html.TextBoxFor(x => x.Username)
                @Html.ValidationMessageFor(x => x.Username)
            </div>
        </div>

And the corresponding HTML that has been generated:

        <div class="control-group">
            <label for="Username">Username</label>
            <div class="controls">
                <input data-val="true" data-val-required="Username is required" id="Username" name="Username" type="text" value="" />
                <span class="field-validation-valid" data-valmsg-for="Username" data-valmsg-replace="true"></span>
            </div>
        </div>

If I skip entering in a username when I submit the form, the unobtrusive validation will change the validation <span> class from field-validation-valid to field-validation-error. When using the provided CSS and HTML templating in a new MVC3 project, this will style the error message so that it is clearly marked. However, this is not the desired marking for Bootstrap. Bootstrap expects the error class name to be added to the <div class="control-group"> element. We can emulate this in the browser using Firebug, resulting in clear indication of the fields with errors. We add the error class to the control group div and the help-inline class to the validation span.

The first part of the solution is to add jQuery selections to our document ready routine to add the help-inline class to all validation spans:

    $('span.field-validation-valid, span.field-validation-error').each(function () {
        $(this).addClass('help-inline');
    });

The next piece requires some understanding of how the jquery.validate event model works. We actually do not need to worry about the unobtrusive portion of of the validation as it is only used to configure jquery.validate. When you first submit the form, control passes to jquery.validate functions submitHandler and invalidHandler. Once those are called, jquery.validate will still call any existing submit handlers for the form and prevent the form from being submitted. Inside the submit handler you can get the validation state of the form with the valid() function.

    $('form').submit(function () {
        if ($(this).valid()) {
            $(this).find('div.control-group').each(function () {
                if ($(this).find('span.field-validation-error').length == 0) {
                    $(this).removeClass('error');
                }                
            });
        }
        else {
            $(this).find('div.control-group').each(function () {
                if ($(this).find('span.field-validation-error').length > 0) {
                    $(this).addClass('error');
                }                
            });
        }
    });

Now we are adding and removing the necessary classnames so Bootstrap displays the error fields perfectly! That is until we encounter a server-side validation error. One more update and we'll be good to go

    $('form').each(function () {
        $(this).find('div.control-group').each(function () {
            if ($(this).find('span.field-validation-error').length > 0) {
                $(this).addClass('error');
            }
        });
    });

Have fun building with MVC3 and Bootstrap!

Why is this a problem? If I wish to make a simple change such as modifying colors in Bootstrap, the most consistent way to do this is in the .less sources. In theory, I should be able to just include the bootstrap.less file in my Chirpy bundle and let it build everything. The .less compiler included with Chirpy just isn't able to handle it. I'm a lazy developer who to eat his cake, so how do I get a work-around in place quickly?

Going back to using dotless is the key. I previously used it for some clients to parse .less files on the server as they are requested by browsers. This dependence on server-side parsing of less files is one of the main reasons that I moved to Chirpy.

To solve this, I have created folders named /Content/css and /Content/less. I have downloaded the .less source files for bootstrap and placed them in the /Content/less folder. The top level files for Bootstrap are bootstrap.less and responsive.less. Next, I created the following pre-build task for my web project:

$(SolutionDir)packages\dotless.1.2.2.0\tool\dotless.compiler.exe $(ProjectDir)Content\less\bootstrap.less $(ProjectDir)Content\css\bootstrap.css
$(SolutionDir)packages\dotless.1.2.2.0\tool\dotless.compiler.exe $(ProjectDir)Content\less\responsive.less $(ProjectDir)Content\css\responsive.css

Please notice that I have removed the -m option so that dotless is not attempting to minimize the less files. I prefer to only do that only once--and Chirpy has continued to compress .css files as expected. Unfortunately, I do have to include the dotless version in the path...so this needs to be updated anytime I upgrade dotless.

Now, with just a quick build, dotless will compile the css files and Chirpy will bundle the css files as needed!

This CSS and JS on my blog is admittedly inefficient. I'm here to write about code, not spend all my time coding so that I can write about code. However, it is a great example of how NOT to keep your JavaScript and CSS files organized: 10 individual CSS requests and 15 individual JavaScript requests. If all of the JavaScript files were being called at just before the end of the body tag and if all of the CSS files are part of the same media type they can be combined into a single file. I try to follow the YSlow conventions where possible.

Chirpy allows for this to be done in a Visual Studio project at build time. If you have already gone through the tutorial and are starting to work through adding your own chirp files into Visual Studio. You need to start maching files together with Chirpy using *.chirp.config files. I've included a quick screenshot that I am using on a project to illustrate how I've organized things. This is an ASP.NET MVC3 project. I have included folders for css and javscript inside ~/Content/. The Bundle.chirp.config file is pulling everything from there and generating five virtual files...and that is all of the content required for the entire site!

I have to mention that the ~/Scripts folder has been left alone as that is where the conventions dictate that JavaScript files should go. I break this convention and say that only Library JavaScript files that are provided by NuGet reside. In my projects, NuGet loads script files into ~/Scripts/, I load script files into ~/Content/js/. I also have to note that my less files are not *.chirp.less files. As we are using the FileGroup to bundle everything together, Chirpy will parse those files when it compiles the group! You can also mix-and-match CSS, LESS and SESS files to your hearts content.

So what does my Bundle.chirp.config look like?

<?xml version="1.0" encoding="utf-8" ?>
<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="style.css">
        <File Path="css/fontface.less" />
        <File Path="css/reset.less" />
        <File Path="css/base.less" />
        <File Path="css/fonts.less" />
        <File Path="css/mixins.less" Minify="false" />
        <File Path="css/layout.less" Minify="false" />
        <File Path="css/homepage.less" Minify="false" />
        <File Path="css/registration.less" Minify="false" />
    </FileGroup>
    <FileGroup Name="ie.css">
        <File Path="css/ie.less" />
    </FileGroup>
    <FileGroup Name="script.js">
        <File Path="../Scripts/jquery-1.5.1.min.js" Minify="false" />
        <File Path="js/ui.js" Minify="false" />
    </FileGroup>-->
    <FileGroup Name="ielt9.js">
        <File Path="js/html5.js" Minify="false" />
    </FileGroup>
    <FileGroup Name="ie.js">
        <File Path="js/PIE.js" Minify="false" />
        <File Path="js/selectivizr-min.js" Minify="false" />
    </FileGroup>
</root>

Now i have the 5 files that I am ready to include. Why 5 files? I need to support IE 7,8,9. The labels on the bundle give some hints to the logic, but looking at the HTML in the template should clear it all up.

Header HTML:

    <link rel="stylesheet" media="all" href="/Content/style.css" />
    <!--[if lt IE 9]>
        <script src="/content/ielt9.js"></script>
    <![endif]-->
    <!--[if lte IE 9]>
        <link rel="stylesheet" media="all" href="/Content/ie.min.css" />
    <![endif]-->
</head>

Footer HTML:

    <script src="/Content/script.js"></script>
    <!--[if lte IE 9]>
        <script type="/Content/ie.js"></script>
    <![endif]-->
</body>
</html>

Now I have 13 files being reduced to 5. I'm confident that I will be adding more files as I complete the project—and I am even more confident that 5 files are all that I will be including in my HTML pages.

Scoping jQuery Rewrites
The first step is to scope all of the jQuery rewrites. The typical method of integrating jQuery rewrites into a website is to add a document.ready function like so:

$(document).ready(function() {
    $('.content_tab_button').click(function(){
        $('.content_tab_container').load('/newcontent.html');
    });
});

Because the rewrites are only called when the document.ready event fires, integrating with new content pulled in from AJAX needs to be done differently. By placing our rewrites in a new function that recieves the scope being updated, we can have a single initialization handle all of the updating:

function my_initializer(data){
    data.find('.content_tab_button').click(function(){
        $('.content_tab_container').load('/newcontent.html');
        my_initializer($('.content_tab_container').html());
    });
}
$(document).ready(function() {
    my_initializer($(document));
});

Everything is now scoped cleanly. The rewrites are applied to the document when the page is loaded, and the new content when the tab button is clicked. Even if you are not an ASP.NET developer, please take the above scoping strategy with you!

How The UpdatePanel Works
At the highest level, an UpdatePanel refreshes its entire contents when a specificied event occurs within the panel. Server-side, the event triggering the refresh is processed, and the entire page-stae is regenerated. Then, only the content inside the UpdatePanel is pushed out. This is important for any developer using UpdatePanel to understand: UpdatePanel is much more convenient than it is efficient. As a result, our solution must follow that model.

With that in mind, we look to javascript class that is already managing the UpdatePanel, the Sys.WebForms.PageRequestManager class. In this class, we see an event handler for the pageLoad event. In the documentation, you can see that we are able to fetch the update panels that were just updated. In the example, they are looking for a panel with a specific ID. In our case, we are looking at having our rewrites applied to any panel that was updated:

var panels = args.get_panelsUpdated();
if (panels.length > 0) {
    for (i = 0; i < panels.length; i++) {
        my_initializer($(panels[i]));
    }
}

Because we have already scoped our jQuery code, this will work like a charm.

Putting It All Together
We can put all of the code together now, and we'll have a script that will play cleanly with the UpdatePanel:

function my_initializer(data){
    data.find('.content_tab_button').click(function(){
        $('.content_tab_container').load('/newcontent.html');
        my_initializer($('.content_tab_container').html());
    });
}
function my_pageloaded_initializer(sender, args) {
    var panels = args.get_panelsUpdated();
    if (panels.length > 0) {
        for (i = 0; i < panels.length; i++) {
            my_initializer($(panels[i]));
        }
    }
}
$(document).ready(function() {
    my_initializer($(document));
    Sys.WebForms.PageRequestManager.getInstance()
        .add_pageLoaded(my_pageloaded_initializer);
});

All of our rewrites are called once—and only once—during page load and UpdatePanel refresh. Enjoy!