Infinities Loop

ASP.NET and .NET from a new perspective

  • Join the Dark Side of Visual Studio 2010

    Hard to believe it’s been so long, but it was almost 4 years ago when I published Join the Dark Side of Visual Studio. That was when a lot of people were still using VS2003, and importing and exporting environment settings required a custom add-in, VSStyler, which has since fallen off the planet and is hard to find (link, anyone? Let me know). Three versions of VS later, and I’m still using and loving the dark side. Pleased, I am (haha). In fact, that article for one reason or another is still one of my most popular blog entries, thanks in part to a link from Scott Hanselman and a commenter on Coding Horror. I will point out selfishly that my article predates both of these :) But, yes, it’s sad when one of your top referrers is from a link in a comment on another blog. Not even the first comment, either.

    Read more...

  • ASP.NET 4.0 ScriptManager Improvements

    .NET Framework 4 Beta 2 has been out for a little while now. There are some subtle improvements to the ScriptManager control in ASP.NET 4.0 that few have picked up on yet. Allow me to introduce you to them! First, let me say that this is strictly about features in the server-side ASP.NET ScriptManager control, not the Ajax library in general. Also – if you do not use the ASP.NET Ajax library but you are a WebForms developer, I assume you, this article is still for you!

    EnableCdn? Yes please.

    This one has been blogged about by ScottGu already, but for completeness, here it is. The ASP.NET Ajax scripts are now hosted in a Microsoft CDN, and you can tell ScriptManager to load them from there by simply enabling this property. For virtually no work you get better performance, less bandwidth usage, and a cleaner rendering due to those ScriptResource.axd urls going away from your HTML. Do read the linked post for details. But wait, there’s more!

    What has not really been blogged about is this: The EnableCdn property isn’t only for ASP.NET Ajax scripts. Even the scripts in System.Web.dll are on the CDN. So if you are using a GridView, TreeView, or Validators, for example – those scripts will load from the CDN, too. It wouldn’t have been the best experience if only only some scripts were affected by this setting, right?

    But what if you are using custom scripts, or 3rd party controls? How would that work? Here’s how.

    Normally, when you embed a script within an assembly for use by a WebForm (either via ScriptManager or the classic GetWebResourceUrl and RegisterScriptResource APIs), you have to define a WebResourceAttribute for it, which allows it to be accessed via the WebResource.axd or ScriptResource.axd handlers:

    [assembly: WebResource("Foo.js", "application/x-javascript")]

    Now, there’s a new property on WebResourceAttribute: CdnPath. Don’t get too caught up on the fact it’s a hard coded url. More on that later.

    [assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = "http://foo.com/foo/bar/foo.js")]

    ScriptManager looks for this property when the EnableCdn property is set to true, and simply uses that path instead of the ScriptResource.axd path to the assembly resource. Pretty simple. And this means that you too can provide your own CDN paths for your own assembly resource scripts. As for where to host your script, well, that’s up to you.

     

    AjaxFrameworkMode.Disabled

    ScriptManager does some interesting and useful things, like: script combining, serving scripts from assemblies, script localization, script globalization, removing of duplicate references, automatic switching between debug and release scripts, and now automatic switching to a CDN. Trouble is, it comes with a bit of a tax: It always includes the Microsoft Ajax library (MicrosoftAjax.js), and by default, MicrosoftAjaxWebForms.js (for partial rendering support with UpdatePanel). The partial rendering script could be removed by setting EnablePartialRendering=false, but there was no way to disable MicrosoftAjax.js. So if you wanted to use the useful features of ScriptManager without using MicrosoftAjax.js, well, you couldn’t (although Bertrand once blogged a way of hacking it by making use of it’s de-duping process).

    The AjaxFrameworkMode property adds two new modes to ScriptManager’s behavior. Enabled (the default, and the same behavior as before), Explicit (does not include any scripts by default but still assumes Microsoft Ajax is to be utilized), and Disabled (does not include any scripts by default and does not assume Microsoft Ajax will be used).

    So here I have a ScriptManager that is including a custom script, without also loading MicrosoftAjax.js or any of the inline script it normally produces.

    <asp:ScriptManager runat="server" AjaxFrameworkMode="Disabled">

        <Scripts>

            <asp:ScriptReference Path="~/scripts/foo.js" />

        </Scripts>

    </asp:ScriptManager>

    AjaxFrameworkMode.Explicit

    The client side script for ASP.NET AJAX 3.5 (the one baked into ASP.NET 3.5) is basically just MicrosoftAjax.js and MicrosoftAjax.debug.js. There are some others, but that’s the main part of the client-side framework. But more often than not, you don’t need the entire framework. It contains a lot of features, like support for WebServices, History management, and Globalization. In 4.0, we have split MicrosoftAjax.js into several parts. When you use Explicit mode, you include these scripts manually in order to ‘pick and choose’ what parts of the framework you need, thus reducing the overall size of the javascript your page requires.

    • MicrosoftAjaxCore.js (contains the type system like registerClass)
    • MicrosoftAjaxComponentModel.js (contains Sys.Application, Sys.Component, Sys.UI.Control, as well as DomEvent for event abstraction and DomElement helpers)
    • MicrosoftAjaxNetwork.js (contains WebRequest and WebRequestManager related classes)
    • MicrosoftAjaxWebServices.js (contains WebServiceProxy and is used to talk to asmx and wcf services, or any service that can serve JSON)
    • *MicrosoftAjaxApplicationServices.js (talks to the Profile, Role, and Authentication services)
    • MicrosoftAjaxSerialization.js (contains the JavaScriptSerializer class)
    • MicrosoftAjaxHistory.js (contains extensions to Sys.Application to add client-side history management support)
    • MicrosoftAjaxGlobalization.js (contains formatting and parsing logic for culture-aware Date, Number, String conversion)

    MicrosoftAjax.js still exists, too, which is now considered a composite script of all these scripts. The one (*) exception is that MicrosoftAjaxApplicationServices.js is now its own script, not part of MicrosoftAjax.js, and so must be included explicitly even if you don’t use Explicit mode and you want to use any of the application services.

    Keep in mind when using this mode that you are “on your own” with determining which parts of the framework you need. This is strictly for those of you who want to lower the footprint of your pages by a little bit. MicrosoftAjax.js in ASP.NET 4.0 is somewhere around 98kb, which is gzipped when served, which takes it down into the 30kb range (numbers from memory – and by the way, these numbers are lower in the recently announced ASP.NET Ajax Beta release on CodePlex by the CodePlex foundation). By comparison, jQuery is something like 20kb once gzipped. So it’s not going to make a big difference, but every bit counts! You can use the existing CompositeScript feature of ScriptManager to include the separate parts of the framework and yet still have them served as a single script.

    Oh – yes, these scripts are all also on the CDN and work with EnableCdn, of course.

    Replacing System.Web Scripts

    When a script component on the page requires an ajax script, it implements the IScriptControl interface, which allows it to tell ScriptManager what scripts it requires. Typically a component will ship with its scripts embedded in its own assembly. In previous versions, you could use a statically declared ScriptReference to override the script used by that component. For example, if a component used the ‘Foo.js’ resource from the ‘CustomControls’ assembly, you could replace the resource based script reference with a static (and possibly, customized) copy like so:

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="Foo.js" Assembly="CustomControls"

                Path="~/scripts/customfoo.js" />

        </Scripts>

    </asp:ScriptManager>

    (In red to indicate this is not a new feature)

    One problem with this feature was that it only worked for scripts that were registered via ScriptReferences or through the IScriptControl interface. But some components still use ClientScript.RegisterClientScriptResource or ScriptManager.RegisterClientScriptResource. The controls in System.Web for example, like the TreeView, GridView, etc. If you wanted to replace one of those scripts with a static copy, you couldn’t (actually for System.Web scripts there was a way, but as a legacy feature I won’t go into). Now in 4.0, you can. So for example – if you find a bug in WebUIValidation.js for a Validator control in System.Web, or there’s just something about it you don’t like – or even, you want to customize it for some reason, just override the reference:

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="WebUIValidation.js" Assembly="System.Web"

                Path="~/scripts/customWebUIValidation.js" />

        </Scripts>

    </asp:ScriptManager>

    An interesting benefit to this is that it is now possible to ScriptManager’s CompositeScript capabilities to combine System.Web scripts! If you are using a GridView and a Validator, for example, you will by default get two WebResource.axd’s to Gridview.js and WebUIValidation.js. Most likely you will also get WebForms.js which has some postback logic in it. Now you can combine them into one:

    <asp:ScriptManager runat="server">

        <CompositeScript>

            <Scripts>

                <asp:ScriptReference Name="WebForms.js" Assembly="System.Web" />

                <asp:ScriptReference Name="GridView.js" Assembly="System.Web" />

                <asp:ScriptReference Name="WebUIValidation.js" Assembly="System.Web" />

            </Scripts>

        </CompositeScript>   

    </asp:ScriptManager>

    Now, that is still going to render as an 'AXD' script -- to ScriptResource.axd. The scripts still live in an assembly, after all. But a feature you probably didn't know about with CompositeScripts (and has been there since ASP.NET 3.5 SP1) is that you can point them at static paths just like regular ScriptReferences. For ultimate in performance and a clean HTML rendering, you can not only combine all those scripts into one, but have them referenced via a simple static script block too. No more 'AXD' with a long, encrypted query string.

    <asp:ScriptManager runat="server">

        <CompositeScript Path="~/scripts/combined.js">

            <Scripts>

                <asp:ScriptReference Name="WebForms.js" Assembly="System.Web" />

                <asp:ScriptReference Name="GridView.js" Assembly="System.Web" />

                <asp:ScriptReference Name="WebUIValidation.js" Assembly="System.Web" />

            </Scripts>

        </CompositeScript>   

    </asp:ScriptManager>

    Simple Assembly Names

    A small but welcomed addition. Previously, if you wanted to reference a script embedded in an assembly via a static script reference, you had to include the full assembly name in the ‘assembly’ attribute. If the assembly is a strong named one, that meant including the fully qualified named, including the publicKeyToken which you undoubtedly would have to lookup somewhere (although I have a friend who has memorized his company’s publicKeyToken! LOL). Something like this:

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="Foo.js"

            Assembly="CustomAssembly, Version=1.2.3.4, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

        </Scripts>

    </asp:ScriptManager>

    Now you can just use simple assembly name. The caveat to this is you do at least need to have the assembly in your bin, or it must be referenced in the <assemblies> section of your web.config. Otherwise, the simple name could be ambiguous to multiple versions in the GAC. In the previous example, notice I used only ‘System.Web’ when overriding WebUIValidation.

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="Foo.js" Assembly="CustomAssembly" />

        </Scripts>

    </asp:ScriptManager>

    ScriptResourceMapping

    This is definitely my favorite new feature, so I saved it for last. Normally, ScriptManager determines where to get a script from by looking at the Name, Assembly, and Path properties. Name and Assembly go together to indicate an embedded resource in the assembly, and Path is just a path to a static script in your application. Since the beginning, you could override an assembly-based reference with a path-based reference. For example, to get MicrosoftAjax.js to load from a path in your site rather than from an assembly, you could declare a script reference like so:

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="MicrosoftAjax.js" Path="~/scripts/MicrosoftAjax.js" />

        </Scripts>

    </asp:ScriptManager>

    The assembly is assumed to be System.Web.Extensions if not specified. With this script reference, now even if script controls on the page registered a requirement for MicrosoftAjax.js, this one would be recognized as the same script thanks to the Name being the same. A static reference on ScriptManager trumps all, so your custom path wins, thus replacing the assembly reference with a path one (and worth noting – it still supports auto switching to the debug version and to localized versions).

    Great – there are some problems to consider:

    1. What if I want every page in my app to do this? If you’re using a Master Page, you may only have a few ScriptManager’s to deal with, so that may not be so bad. But even then, there’s a maintenance factor here.
    2. What if I am using a 3rd party component and it does not define a CdnPath? Is there any way to make it work with EnableCdn if I can host it somewhere myself?
    3. What if I want to change which CDN is used for a particular resource (remember, we hard coded the path earlier)?
    4. How can I get the benefits of automatically switching between debug and release scripts for a non assembly-based resource?
    5. How can I get the benefits of automatically switching between debug and release scripts for a script like jQuery that does not use the “.debug.js” naming convention?

    To be fair, #4 was already possible by explicitly setting the ScriptMode property on the script reference – but we’ll see a better way now.

    ScriptResourceMapping to the rescue. Think of ScriptResourceMapping as a static/global location into which you can describe all the details about a particular script resource: a logical name for the script, it’s debug and release locations, what assembly it lives in (if any), and what it’s debug and release CDN paths are. With all that information, ScriptManager can make smarter choices about how to handle a script reference and makes your life easier.

    For example, let’s say you want to include jQuery via a ScriptReference.

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Path="~/scripts/jQuery-1.3.2.js" />

        </Scripts>

    </asp:ScriptManager>

    But wait – what about jQuery-1.3.2.min.js? You should definitely be using the minimized version in production. But in a debugging environment, it’s better to use the non-minimized version so if you ever need to step into jQuery code, you can actually understand what is going on.

    And what about EnableCdn? That’s not going to work with this since ScriptManager doesn’t know about this script. It’s just some script in your project. Yes, you could just put the full ‘http://...’ path in there. But having to remember that path every time you need it is not very nice.

    No problem – we’ll just create a mapping that fully describes the resource. Mappings are static, so let’s create them from the Application_Start event in Global.asax:

    void Application_Start(object sender, EventArgs e) {

        // map a simple name to a path

        ScriptManager.ScriptResourceMapping.AddDefinition("jQuery", new ScriptResourceDefinition {

            Path = "~/scripts/jquery-1.3.2.min.js",

            DebugPath = "~/scripts/jquery-1.3.2.js",

            CdnPath = "http://ajax.microsoft.com/ajax/jQuery/jquery-1.3.2.min.js",

            CdnDebugPath = "http://ajax.microsoft.com/ajax/jQuery/jquery-1.3.2.js"

        });

    }

    Three big wins here.

    1. Now I can simply reference jQuery by name, just like MicrosoftAjax.js (only I don’t even need the ‘.js’ part).
    2. Because ScriptManager knows the path to jQuery’s release and debug versions, it switches automatically just like it does for MicrosoftAjax.js.
    3. Because ScriptManager knows jQuery’s CdnPath, the EnableCdn feature will toggle using it on/off just like it does for MicrosoftAjax.js.

    Using this mapping is simple – just reference the script by name:

    <asp:ScriptManager runat="server">

        <Scripts>

            <asp:ScriptReference Name="jQuery" />

        </Scripts>

    </asp:ScriptManager>

    Beautiful. You can use this to redefine the CdnPath for an existing script, too. For example, say you don’t like the fact that MicrosoftAjax.js loads from the ajax.microsoft.com Cdn. Or, say you are using some 3rd party controls, and they don’t define a CdnPath, but you happen to know of one that uses it (or even, the 3rd party published a Cdn after they shipped the product). Just create a mapping and set the CdnPath. Done. For the entire application.

    But wait, there’s even more. The jQuery example shows how you can map a simple name to a static script. But a script resource mapping can also be used to map a name to an assembly resource.

    // map a simple name to an assembly

    ScriptManager.ScriptResourceMapping.AddDefinition("Foo", new ScriptResourceDefinition {

        ResourceName = "FooResource.js",

        ResourceAssembly = MyAssembly

    });

    Or, map an existing assembly resource to a static path.

    // map assembly resource to a path

    ScriptManager.ScriptResourceMapping.AddDefinition("SomeScript.js", SomeAssembly,

        new ScriptResourceDefinition {

            ResourceName = "SomeScript.js",

            ResourceAssembly = SomeAssembly,

            DebugPath = "~/scripts/somescript.debug.js",

            Path = "~/scripts/somescript.js"

    });

    Or, map an existing assembly resource to a different assembly resource.

    // map an assembly resource to another assembly resource

    ScriptManager.ScriptResourceMapping.AddDefinition("SomeScript.js", SomeAssembly,

        new ScriptResourceDefinition {

            ResourceName = "SomeOtherScript.js",

            ResourceAssembly = MyAssembly

        });

    Don’t forget you can also use this to change where the MicrosoftAjax*.js scripts come from.

    This gives you a lot of control over where scripts come from. Now your pages can utilize ScriptManager’s advanced features, without necessarily depending on MicrosoftAjax.js, and without having to hard code paths to scripts or to assembly resources. Now your pages can be a semantic definition of the scripts your page requires – and the details are all in one location. And when the need arises, you can change where those scripts come from, no matter where they came from originally.

    Bringing it all together: De-AXD’ifying

    Not really a feature of it’s own – but a consequence of the others worth noting. Because ScriptManager can now deal with System.Web scripts or any scripts regardless of which API is used to register them, it is now possible – for the first time – to get rid of all WebResource.axd and ScriptResource.axd urls from the HTML rendering. And you can do it without touching your pages due to the ScriptResourceMapping feature. And what’s more – because of the CompositeScript feature, you can also get them all combined into a single, static script file, with a simple, beautiful url. Or better yet – let Microsoft handle the bandwidth, and use the CDN!

    Read more...

  • Microsoft Ajax 4 Preview 5: The DataView Control

    Preview 5 of the Microsoft Ajax 4.0 library has been released. Some quick background – this the next version of the client-side ajax framework you have probably already heard of, the one that ships along with ASP.NET 3.5 (but is also available in script form). The fact it ships with ASP.NET has sometimes led to it being called the ASP.NET AJAX Framework. Technically, that name is a superset – it encompasses “Microsoft Ajax” and it’s ASP.NET specific, server-side features, like the ScriptManager. But “Microsoft Ajax” always has and always will be an ajax framework that is not tied to any specific server-side technology. Also noteworthy is that this 4.0 library can run on top of ASP.NET 3.5, replacing the 3.5 version it normally uses.

    In previous previews of Microsoft Ajax 4, we introduced the DataView control. It’s a simple but powerful control that takes advantage of the client templating engine we built for it. You point it at a template, and some data, and it instantiates the template for each item in the data. The templating engine lets you use ‘placeholders’ and create ‘live bindings’ between the rendered DOM elements and the data, as well as allow you to attach other ajax components and controls.

    I want to focus on one of the new features added to the DataView in preview 5, but first, I feel obliged to introduce the DataView control from a basic level, since most of you probably don’t know about it yet.

    Simple DataView Example

    As a simple example – lets make up some data. Normally this would come from a web service or some other source, not hard coded, of course.

    var stockData = [
        { symbol: "DJIA"  , change: 79.88, value: 9627.48 },
        { symbol: "NASDAQ", change: 23.63, value: 2084.02 },
        { symbol: "AAAA"  , change: -0.22, value: 27.56 },
        { symbol: "BBBB"  , change: -1.46, value: 82.12 },
        { symbol: "CCCC"  , change: 0.67 , value: 7.56 }
    ];

    We want to show this stock data in a table, and probably do some formatting to show the values as currency, etc. Without a templating engine, you’d basically either have to painstakingly create DOM elements by hand, or build up a string and use innerHTML. Neither technique is easy to maintain, or are designable by designer tools. Worse, building a string and using innerHTML could net you some XSS vulnerabilities. This is where the templating engine in Microsoft Ajax 4 comes in.

    <table id="stocks" class="stocks sys-template">
        <tr>
            <td>{{ symbol }}</td>
            <td>{{ value.localeFormat("c") }}</td>
            <td>{{ change.localeFormat("c") }}</td>
            <td>{{ (change/value).format("p2") }}</td>
        </tr>
    </table>

    In the simple form, {{ foo }} represents a placeholder where the value of a field named ‘foo’ from the data items will be. What language is this stuff? Just javascript. So as you can see, this take advantage of the formatting methods in Microsoft Ajax to convert the values to currency. You could write any ole javascript here, of course (unobtrusive javascript alert: yes, you can do it that way too, more on that later).

    The class “sys-template” is setup to have display:none, so that this chunk of HTML doesn’t actually show up in the markup.

    That’s the template – it represents what each item should look like. Now to put it to use with the DataView control:

    function pageLoad() {
        $create(Sys.UI.DataView, {
            data: stockData
        }, null, null, $get("stocks"));
    }

    That’s it. The DataView control is given the data, and the template. Everything is hooked up. Here is the result (css not shown):

    image 

    One obvious improvement we could make to this sample is to dynamically style the rows so that stocks going up are green, down, red. You can in fact do that, but I digress. This is just the most basic use of a DataView. I haven’t even mentioned live bindings. And even in preview 4 you could reuse templates across multiple dataviews, and set the placeholder to be something other than the default. Here is an excellent article by Jim Wang which covers some of the other things you could do in Preview 4, including selecting items, and integrating with an ADO.NET DataService.
    http://weblogs.asp.net/jimwang/archive/2008/11/05/working-with-ado-net-data-services-in-ajax.aspx

    Preview 5 – Dynamic Templates and Dynamic Placeholders

    Preview 5 introduces a new feature to the DataView control that allows you to dynamically determine the template used for each data item, as well as dynamically determine the placeholder that anchors where it will be inserted. This means each data item can potentially render completely differently, and render into completely different areas of the page, all the while being under the control of a single DataView!

    What does this mean? Well, say you have a single set of data returned by a service of some kind. But you don’t want to simply list this data all in one place. Some needs to go there, and some over there, depending on the state of each item. A typical example of this might be a data set of forum posts, where some of them are marked as ‘sticky’, and so should be listed first, but the sticky ones aren’t necessarily first in the list of data. How would you normally deal with that? Separate the sticky items into their own data set, or query for them separately? If you are using stored procedures, maybe that means creating a new one or modifying an existing one to support the filtering. Why go through such hoops and database-level manipulations when this is purely a UI problem? If it can’t be solved by your UI tools, perhaps you’re blurring your separation of concerns.

    So as an experiment, I imagined a list of bloggers. Each blogger may or may not be on Twitter, right? But I want the tweeting and non-tweeting bloggers to be listed separately. Furthermore, the way I display a tweeting blogger and a non-tweeting blogger may be very different. For one, I want to display some of the latest tweets from the tweeting bloggers, and display their Twitter avatar.

    Mind you, it is certainly possible to use dynamically determined css classes, and to dynamically show/hide regions of content within a template, based on the data item. But that only gets you so far. Sometimes, the differences are too much to neatly define a single template that can represent either kind of data item. This particular example could have been done either way. Maybe I just wasn’t creative enough :)

    First – let’s define our bloggers.

    var bloggerList = [
        { name: "InfinitiesLoop", author: "Dave Reed",
            uri: "http://weblogs.asp.net/infinitiesloop", twitter: "infinitiesloop" },
        { name: "Computer Zen", author: "Scott Hanselman",
            uri: "http://www.hanselman.com/blog", twitter: "shanselman" },
        { name: "Random Thoughts", author: "Bob",
            uri: "http://myblog.com" },
        { name: "Tales from the Evil Empire", author: "Bertrand Le Roy",
            uri: "http://weblogs.asp.net/bleroy", twitter: "bleroy" },
        { name: "The Gu", author: "Scott Guthrie",
            uri: "http://weblogs.asp.net/scottgu", twitter: "scottgu" },
        { name: "Some blog", author: "Mr. IDontTwitter",
            uri: "http://weblogs.asp.net/donttwitter" },
        { name: "Jim Wang's Blog", author: "Jim Wang",
            uri: "http://weblogs.asp.net/jimwang/", twitter: "turanuk" },
        { name: "James Senior", author: "James Senior",
            uri: "http://www.jamessenior.com/", twitter: "jsenior" }
    ];

    Each blogger has a blog name, author name, uri, and if they have one – a twitter id. Important to note – the non-twittering bloggers are not at the beginning of the array, they are mixed in with the others.

    For brevity I’m going to show the declarative way of attaching a DataView control, even though we feel most developers would prefer to keep this stuff separated from their markup. Everything you see here can be done in pure code (imperatively). And we are actively working on some very interesting improvements that make the imperative ways much, much easier than they are in Preview 5, so stay tuned, you won’t want to miss it. Both declarative and imperative approaches are in the sample download at the end of this post.

    Let’s first define the overall structure we want:

    <div id="bloggers" class="bloggers"
        sys:attach="dv" dv:data="{{ bloggerList }}"
        dv:onitemrendering="{{ itemRendering }}">
        <div class="notwitter">
            Non-twittering Bloggers
            <ul>
                <li id="normalph"></li>
            </ul>
        </div>
     
        <div class="hastwitter">
            Twittering Bloggers
            <ul>
                <li id="twitterph"></li>
            </ul>
        </div>
    </div>

    Two divs, one for each kind of blogger. And placeholders for where each should be rendered. A DataView is attached declaratively with sys:attach=”dv” (the ‘dv’ comes from an xml namespace declared on the documents body tag and maps the namespace ‘dv’ to the Sys.UI.DataView class, ‘dv’ is not magical). As each blogger is processed, the ‘itemRendering’ event is fired before anything is instantiated for it. We’ve hooked up a handler for it:

    function itemRendering(dv, args) {
        var blogger = args.get_dataItem();
        if (blogger.twitter) {
            args.set_itemTemplate("twitterblogger");
            args.set_itemPlaceholder("twitterph");
        }
        else {
            args.set_itemTemplate("normalblogger");
            args.set_itemPlaceholder("normalph");
        }
    }

    If the blogger has a Twitter id, we set the template to the ‘twitterblogger’ template and tell it to render where the ‘twitterph’ element is. Otherwise, we use the ‘normalblogger’ template and render them where the ‘normalph’ element is. For a ‘normal’ blogger, we just want to render a link to their blog and their name:

    <ul class="sys-template" id="normalblogger">
        <li>
            <a sys:href="{{ uri }}">{{ name }}</a>
            <span>author: {{ author }}</span>
        </li>
    </ul>

    Pretty simple. For a tweeting blogger, we want to do something slightly different, plus we want to show their last 5 tweets for good measure.

    JSONP

    Another feature in Microsoft Ajax 4, I should mention, is JSONP support. And good thing too, because it makes this demo way cooler. Twitter happens to have a JSONP service, and the DataView integrates nicely with the networking support in Microsoft Ajax, giving it JSONP support, too. So getting tweets for someone is just a matter of creating a DataView with the JSONP address as the ‘dataProvider’. So our Blogger DataView is going to actually contain a nested DataView. Here is the ‘twitterblogger’ template:

    <ul class="sys-template" id="twitterblogger">
        <li>
            <a sys:href="{{ uri }}">{{ name }}</a>
            <span>{{ author }}</span>
            <ul class="tweets sys-template" sys:attach="dv" dv:autofetch="true"
                dv:dataprovider="{{ getTwitterUrl(twitter) }}">
                <li>
                    <img class="avatar" sys:src="{{ user.profile_image_url }}" alt="" src="" />
                    {{ text }}
                </li>
            </ul>
        </li>
    </ul>

    So, our blogger entry has a nested UL, to which we attach another DataView with the JSONP Twitter url as the target provider. The data returned from Twitter also has information about the Twitter user, like their avatar, so we may as well show that, too. The ‘getTwitterUrl’ call demonstrates that you aren’t limited to just data – you can do stuff with it too. That method simply takes the blogger’s Twitter id and constructs the JSONP service url for their last 3 tweets.

    That’s it! Here it is in action:

    image

    Download the sample code here.

    Also, be sure and check out these other awesome posts about Microsoft Ajax 4.

    These are based on previous preview releases.

    Read more...

  • ASP.NET WebForms: Taking Back the HTML

    There’s a lot of debate these days about the ASP.NET WebForms model vs. the newer ASP.NET MVC model. There are advantages to both. Disadvantages to both. Pick the one that best fits your needs. Nuff said. But sometimes that choice isn’t so obvious.

    MVC for example essentially gives you much more control over the generated HTML for the page. Well, complete control. But sometimes you don’t really need complete control, and the lack of an encapsulated control kind of sucks. HTML Helpers help, but they have no design time experience. Hence, there are the MVC Controls in the MVC Futures project on CodePlex and an interesting compromise between the two models, at least when it comes to the rendering part of the application.

    But then there’s the other side of the equation – you’ve got a WebForms application, and you need a little more control over the HTML. What’s the compromise there? Well, server controls try to give you control over the markup. Some of them do a pretty good job at it, like the ListView control added in ASP.NET 3.5. Others, not so good. If a control doesn’t let you do what you need, you are pretty much stuck – either abandon the control and all its usefulness, or write your own control.

    What’s in a control anyway?

    If you think about it, controls at the highest level are really two very different things.

    1. Controls abstract the rendering of HTML.
    2. Controls provide client-server integration by managing data between client and server.

    Take the CheckBox control. It renders an input and label, and connects them with the ‘for’ attribute, so clicking the text also checks and unchecks the checkbox. That’s it’s HTML abstraction. It provides client-server integration by allowing you to dynamically read and write to the checked property on a server-side proxy.

    A simple example of #2 is the TextBox control. Double meaning, uh, not intended. Type some text into the box and submit the form – magically, the server-side instance knows what its Text property should do. The control can also push data back to the client. Set the Text property, and magically the value is reflected in the rendered page. This can be much more complex though – the control might manage a hidden field, or rely on data stored in that catch-all hidden field we love to hate, ViewState.

    The thing is, HTML abstraction is useful, but a lot of the time it doesn’t provide a ton of benefit. Client-server integration, however, is usually much more useful. If you don’t need that there’s a good chance you don’t need a control to begin with.

    Html Controls

    I would be wrong not to point out that there’s a whole namespace of controls in ASP.NET that are largely underused. HTML controls allow you to add a runat=”server” to an HTML element and get reasonable client-server integration with it. So if you don’t like how the CheckBox control renders, just use the HtmlCheckBox instead. But what if you’re using a more complex control that has no HTML equivalent?

    What if you could control the HTML for any server control without losing the client-server interaction?

    Wouldn’t that be nice?

    Taking Control

    Introducing the CustomRender control. This control suppresses the rendering of any control(s) you put in it, while allowing you to define your own, replacement HTML. It gets a little nicer than that, though. One step at a time – first, lets choose the enemy. A Button control that sets the text of a Label control.

    <script runat="server">
        private void ButtonClick(object sender, EventArgs args) {
            Label1.Text = "You clicked Button1";
        }
    </script>
    <asp:Button ID="Button1" runat="server" Text="Go" OnClick="ButtonClick" />
    <asp:Label ID="Label1" runat="server" />

    You’re going down, Button1. Bring on the CustomRender:

    <i88:CustomRender runat="server">
        <ControlTemplate>
            <asp:Button ID="Button1" runat="server" Text="Go" OnClick="ButtonClick" />
            <asp:Label ID="Label1" runat="server" />
        </ControlTemplate>
    </i88:CustomRender>

    That’s step 1. Now how do we get our own HTML in here? As this stands, the button and label will not render anything. They still participate in the page lifecycle and all that goodness. But nothing renders. So we could just put the HTML next to the CustomRender control. But it would be nice if this control helped me out a little by giving me what these controls would have rendered, wouldn’t it? Lets swap over to Design View.

    If you’re one of the types that never uses Design View – it’s that button that says ‘Design’ on the lower left, or Shift-F7.

    image

    Click on “Update HtmlTemplate”, then switch back on over to Source view. Voila…

    <i88:CustomRender runat="server">
        <ControlTemplate>
            <asp:Button ID="Button1" runat="server" Text="Go" OnClick="ButtonClick" />
            <asp:Label ID="Label1" runat="server" />
        </ControlTemplate>
        <HtmlTemplate>
            <input ID="Button1" name="Button1" type="submit" value="Go" /> <span ID="Label1">
            </span>
        </HtmlTemplate>
    </i88:CustomRender>

    The designer for the control has rendered its ControlTemplate and put the result into the HtmlTemplate. And just to prove it works, modify the HTML a little. Lets change the ‘value’ of the input from ‘Go’ to ‘Gone’.

    image

    And now lets click the button and see if the server control still works. Remember, it’s supposed to set the text of the label to “You clicked Button1.”. Hmmmm.. nothing. It broke!!! No… remember, when you do this, you take complete control over the HTML. That text doesn’t just come from no where. The code is running, but you haven’t put it into your HTML.

    How do you do that? No problem – think of the HTML template like a mini-MVC View.

    <HtmlTemplate>
        <input ID="Button1" name="Button1" type="submit" value="Gone" />
        <span ID="Label1"><%= Label1.Text %></span>
    </HtmlTemplate>

    Now when we click the button, it works:

    image

    Show Off – The Challenge

    “Okay,” you say, “but that’s just a button and a label. What about a real world scenario,” you spout in disbelief? I dunno if you said that, but it’s more interesting to pretend like you are challenging me to put this technique to the test. I accept your pretend challenge.

    Way back in ASP.NET 1.x there was the DataGrid control. As great as it was at the time, it’s limitations eventually led to the GridView control. As great as that was, you still didn’t get enough control over the markup and CSS, so the ListView control was born (I often wonder what we’d call the next iteration – running out of two-word data-like combinations aren’t we? No, there already is a DataList control!). My point being that in the current set of databound controls, the DataGrid control is probably the oldest and most set in its ways, and most known for its lack of customizability. It renders as a <Table>, and that’s that. How 1990’s of it.

    A perfect target for the challenge – let’s do the unthinkable. Get a DataGrid to render as <UL> and <LI> and be styled with 100% CSS, while maintaining the server-side features like SelectedIndex.

    First, lets take a look at a DataGrid utilizing the SelectedIndex feature.

    <asp:DataGrid ID="dg1" runat="server" 
        AutoGenerateColumns="false" SelectedIndex="1" SelectedItemStyle-CssClass="selected"
        DataSource='<%# DummyData %>'>
        <Columns>
            <asp:BoundColumn DataField="Name" />
            <asp:ButtonColumn DataTextField="Price" DataTextFormatString="{0:c}" CommandName="Select" />
        </Columns>
    </asp:DataGrid>

    It shows two columns – a product name, and a price, formatted as currency. You can click on the price to select the item, which then has a different CSS class. The DummyData property is just returning an ArrayList with a few sample items. Let’s not forget how you databind this thing… you may be using a DataSource control. For this purpose we’ll just do it the old fashioned way.

    protected override void OnLoad(EventArgs e) {
        if (!Page.IsPostBack) {
            dg1.DataBind();
        }
        base.OnLoad(e);
    }

    Now lets take a look at the rendering.

    <table cellspacing="0" rules="all" border="1" id="dg1" style="border-collapse:collapse;">
        <tr>
            <td>&nbsp;</td><td>&nbsp;</td>
        </tr><tr>
            <td>Widget</td><td><a href="javascript:__doPostBack('dg1$ctl02$ctl00','')">$19.95</a></td>
        </tr><tr class="selected">
            <td>Horn</td><td><a href="javascript:__doPostBack('dg1$ctl03$ctl00','')">$2.99</a></td>
        </tr>
    </table>

    image

    A few things of note going on here. For the SelectedIndex feature to work, the ButtonColumn has rendered an <A> tag which does a postback. The ID it passes to the __doPostBack function is the UniqueID of a link button it has added to the control tree. The LinkButton raises a bubble command named “Select”, which the DataGrid picks up and sets its SelectedIndex property. While rendering, the DataGrid applies a different style to the selected item.

    Translating this into your own custom HTML is pretty easy actually. The trick is to do rendering only – you could in theory use a Repeater to bind over the same items. We’re trying to leverage the existing features of the DataGrid, so rather than grab the data directly we’re enumerate the DataGrid’s Items collection and try to reuse as much as we can.

    Again, think of this template as a mini-MVC view, and the actual control we are targeting is like our ViewData. That way, changes to the DataGrid don’t require changes to the custom rendering.

    <i88:CustomRender runat="server" ID="c1">
        <ControlTemplate>
            <asp:DataGrid ID="dg1" runat="server" SelectedItemStyle-BackColor="Red"
                AutoGenerateColumns="false" SelectedIndex="1"
    SelectedItemStyle-CssClass="selected"
                DataSource='<%# DummyData %>'>
                <Columns>
                    <asp:BoundColumn DataField="Name" />
                    <asp:ButtonColumn DataTextField="Price"
    DataTextFormatString="{0:c}" CommandName="Select" />
                </Columns>
            </asp:DataGrid>
        </ControlTemplate>
        <HtmlTemplate>
            <% for (int i = 0; i < dg1.Items.Count; i++) {
                   // enumerate the DataGrid's items so we can choose how to render them
                   var item = dg1.Items[i];
                   // the ButtonColumn is rendering a LinkButton or Button 
                   var priceLink = (IButtonControl)item.Cells[1].Controls[0];
                   %>
            <ul class="item<%= dg1.SelectedIndex == i ? " selected" : "" %>">
                <li><%= item.Cells[0].Text %></li>
                <li class='price' 
    onclick="<%= Page.GetPostBackEventReference((Control)priceLink) %>">
    <%= priceLink.Text %>
    </li>
            </ul>
            <% } %>
        </HtmlTemplate>
    </i88:CustomRender>

    A for loop enumerates the DataGrid.Items collection. For the first column we just repeat the cell’s text. The 2nd column is more complex as it contains a LinkButton with a postback reference. Even so, it’s not too complex – get a reference to the LinkButton and use Page.GetPostBackEventReference() to generate the necessary postback script. We are now free to apply CSS in anyway we like. Watching for the the SelectedIndex, we apply a ‘selected’ class, for example.

    I’ve just quickly put together these styles to make each ‘item’ float left, so the “grid” isn’t even a grid anymore, just to show how it can be totally different.

    <style type="text/css">
        ul.item {
            float: left;
            list-style-type: none;
            padding: 0px 10px 0px 10px;
        }
        ul.selected {
            border: solid 1px red;
        }
        li.price {
            cursor: pointer;
            color: Blue;
            text-decoration: underline;
        }
    </style>

    And here it is running.

    image

    Mission Accomplished

    Perhaps you are thinking that is pretty ugly and difficult. If you are, remember that is why controls abstract that stuff away for you, so it’s easy and expressive. This is by no means “the end” of control rendering. It’s a tool you should keep in your toolbox. If you have a difficult to fix rendering issue for a specific control, now you don’t have to say goodbye to the whole thing.

    How does it work?

    It’s actually pretty simple! All controls create their HTML in the Render() method. To control the HTML, you just need a way of injecting your own HTML while suppressing the stuff it’s Render() method produces. Ok – so, don’t call Render(). The Render method unfortunately does not only produce HTML. Sometimes it produces script references or “startup” scripts. Sometimes it registers with the ASP.NET Event Validation feature for security purposes. So this control still calls Render, but it throws away the resulting HTML. It instantiates the ControlTemplate like any other template, adding it to its own control tree so they particulate in the lifecycle. It just chooses to actually render the HTML template instead. That is, unless it is design time. Then it renders the control template – allowing you to use the controls in the designer like you normally could.

    Gotchas

    Controls will not necessarily take kindly to being rendered “for reals” at Design Time. The page isn’t real, and the other controls on the page don’t necessarily exist or are in their proper hierarchy. So the “Update HtmlTemplate” designer action may not always work. It might even cause an exception to be thrown. It depends on the control.

    Also, I find that although the correct HTML is being rendered internally, VS gets it’s hands on it and makes a few modifications to the persistence of it for some reason. It seems mostly benign, like reordering element attributes. But one bad thing it does is capitalize the ‘id’ attribute, which is supposed to be in lower case if you care about XHTML compliance. Easy enough to fix once you get the HTML bootstrapped. I’m trying to find out from someone on the team why this happens and if we can fix it. If all else fails, you can always run the page and use the actual source to get the HTML rather than use the designer trick.

    Download & Discuss

    It’s up on code gallery, including the sample of the world’s first cannibalized DataGrid.

    http://code.msdn.microsoft.com/aspnetcustomrender

    Read more...

  • Professional ASP.NET 3.5 AJAX Released

    Looking for an ASP.NET AJAX book? This one has been massively updated from its 2.0 version, to cover in detail the features added in 3.5, and not to be forgotten, 3.5 SP1. For example, Script Combining was a new feature in 3.5 SP1, and so was History support, so it's an important distinction! The 2.0 book was 307 pages, and this one is 552. History support, by the way, has a dedicated chapter. Script combining is a major portion of the chapter on the ScriptManager.

     Another important difference between the 2.0 and 3.5 versions -- this time, I'm a contributing author. :) My first major technical publication, hopefully more to come. I'm that weird guy on the right.

    http://www.amazon.com/Professional-ASP-NET-AJAX-Bill-Evjen/dp/0470392177

    Read more...

  • The Event Handler That Cried Wolf

    I ran into an interesting and unexpected behavior in ASP.NET AJAX event handling the other day. Once I figured out what was going on, I was almost positive it was a bug, so I started looking into what a solution would be. But just out of curiosity, I looked at what the behavior was for a server-side event. Much to my surprise, the behavior was the same. The behavior then was consistent with the server-side behavior, not a bug. But is it the "correct" behavior? Tell me what you think...

    Read more...