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!