Tales from the Evil Empire : ASP.NET

Orchard team looking for a new developer

Bertrand Le Roy — Mon, 23 Nov 2009 19:24:19 GMT

My team is looking for a new full-time developer. The project is to build a completely new open-source CMS based on ASP.NET MVC 2. It’s a lot of fun :)

https://careers.microsoft.com/JobDetails.aspx?ss=&pg=0&so=&rw=1&jid=9434&jlang=EN

Enabling the ASP.NET Ajax script loader for your own scripts

Bertrand Le Roy — Mon, 23 Nov 2009 15:00:00 GMT

In previous posts, I’ve shown different ways to build a client-side class browser, using the ASP.NET Ajax Libary and jQuery.

In this post, I’ll focus on a few lines of code from the latest version of that sample. Those few lines of code enable my custom script to benefit from the script loader’s features such as lazy and parallel loading and dependency management.

An important feature of the script loader is the separation of the script meta-data from the script code itself. The meta-data can include the name of the script, its dependencies, instructions on how to figure out if it’s already loaded, its debug and release URL patterns and a declaration of the lazy components and plug-ins it introduces. The script loader can also handle composite scripts but I won’t cover that in this post.

The name of the script is what will be used to reference it from other scripts and to generate the URL from a pattern. It shouldn’t include the “.js” extension.
The dependencies and executionDependencies are each a simple array of script names that the script depends on. I’ll explain the difference in a minute.
The is loaded criterion is a JavaScript expression that returns true if the script is already loaded. This is usually a test on an object that the script file defines. For example, the “templates” script uses !!(Sys.UI && Sys.UI.Templates). It can assume Sys because it’s defined by start.js.
Debug and release patterns are expressions that enable the framework to map script names into debug and release URLs. The ASP.NET Library uses “%/MicrosoftAjax{0}.debug.js” and “%/MicrosoftAjax{0}.js” where % gets replaced with the path where the script loader was downloaded from (this can be CDN or local) and {0} gets replaced with the script name. You can create your own pattern or just provide fixed URLs if you have only one script file. The debug pattern is optional.
Lazy components and plug-ins are helpers that the script loader can create for you and that enable developers to start using your components before they are even loaded and hide the script loading aspects as much as possible. For example, it’s that feature that enables you to write this while still having only start.js loaded:
```
Sys.create.dataView("#myDataView", {
    data: myData
});
```
The code that needed to be written for this helper to be created was this:
```
behaviors: ["Sys.UI.DataView"]
```
This gets automatically transformed by the script loader into the Sys.create.dataView method, before it even tries to load the actual script that defines Sys.UI.DataView. And if you have jQuery loaded as well, you’ll also get a jQuery plug-in out of it for free, which means that you can do:
```
$(".data").dataView({data: myData});
```
and instantiate DataView controls over the results of a selector query in one operation. Groovy. Of course, you can do the same with the behaviors and controls that you write in your own scripts, with lots of options to customize names, add parameters, etc.

In the case of the class library code, here’s the meta-data declaration code that I had to write:

Sys.loader.defineScript({
  name: "classBrowserTree",
  releaseUrl: "%/TreejQuery.js",
  executionDependencies:
    ["jQuery", "Templates", "ComponentModel"],
  isLoaded: !!(window.jQuery &&
    window.jQuery.fn.classBrowserTreeView)
});

This declares that my script, named “classBrowserTree”, can be found at the URL TreejQuery.js relative to the base URL of the script loader, that it depends on jQuery, Templates and ComponentModel (which themselves have their own dependencies) and that the loader can determine whether it’s already loaded by evaluating the classBrowserTreeView jQuery plug-in.

Now, loading that script and all its dependencies is as simple as writing this:

Sys.require(Sys.scripts.classBrowserTree);

Notice that as you’re typing this, you actually get full IntelliSense in Visual Studio on the name of the script, which is great for speed and to avoid typos:

One of the things that enable the script loader to do its job is a special way to write your script that makes it possible to separate the loading and parsing of the code from its execution.

Don’t freak out (yet) though as the code you have to introduce is very lightweight and it doesn’t prevent your script from being loaded without the script loader (with a plain old script tag for example).

Reversely, a script that doesn’t have the special script loader code can be handled by the script loader but its dependencies must be declared using “dependencies” instead of “executionDependencies” in the meta-data declaration code, which will in effect disable the more advanced features of the script loader such as parallel loading.

The special code in question is the following:

(function() {
  function execute() {
    // Your code goes here.
  }
  if (window.Sys && Sys.loader) {
    Sys.loader.registerScript(
      "classBrowserTree", null, execute);
  }
  else {
    execute();
  }
})();

What you see here is a (function() {…})(); wrapper, which is standard practice to isolate code from the global namespace (essentially, it’s a local scope); we also have another named scope in there that we arbitrarily call “execute” (but the name doesn’t matter). This is where you’ll typically put your actual code. Then we have the bootstrapping code that looks for the script loader. If it isn’t found, the code in the execute function is immediately run. If it is found, the execute function is registered with the script loader but is not immediately executed.

This wrapper code is what enables the script loader to do its magic. Thanks to this little bit of code, it doesn’t care at all in what order the scripts are being loaded, because it can delay the time when any script actually gets executed until all its dependencies have been successfully loaded.

This also allows the script loader to load scripts in parallel, even if one depends on another. Normally a script loader would have to download a dependent script first and wait for it to completely load before loading the next script. This ‘serializes’ the loading process and is not good for performance. Modern browsers can download 6 to 8 scripts simultaneously. Separating the loading of a script from its execution allows the loader to take advantage of that, and in most cases, even complex dependency trees can be downloaded completely in parallel, meaning the total time is not the sum of each script, but only the longest one.

Of course, in order to be wrappable, your code needs to be able to run in a non-global scope. This is good practice anyways and is relatively easy to achieve in most cases, so if it can’t, it may be a good idea to try to determine why and fix it.

And this is it. I hope I’ve convinced you that the script loader can help you to improve the performance of your applications at a really low cost. It also provides a very worthy client-side equivalent of the server-side ScriptManager that ASP.NET has been providing to developers for years: switching the whole application between debug and release scripts is a breeze, which minimizes the risk of deploying debug scripts in production; dependencies are being handled automatically; script combination is handled.

(many thanks to Dave Reed for helping with this post and of course for implementing an awesome script loader)

PDC week! Panel on OSS + ASP.NET

Bertrand Le Roy — Mon, 16 Nov 2009 22:13:48 GMT

I’ll be at PDC tomorrow, Wednesday and Thursday. If you are attending and want to say hi, you’re most likely to find me in the Web Pavilion (in the big room, next to the Surface lounge).

Please also join us for a panel discussion on Wednesday about Open Source on ASP.NET. We’ll have the following people on the panel to answer your questions, and ask you a few too:

Scott Hanselman
Shaun Walker
Sara Ford
Glenn Block
Clemens Vasters
Myself

The discussion will be between 2PM and 3PM, in the Web Pavilion.

Metrics in software and physics

Bertrand Le Roy — Sat, 14 Nov 2009 07:32:00 GMT

Every so often, somebody points out how bad of a metric code coverage is. And of course, on its own, it doesn’t tell you much: after all, it’s a single number. How could it possibly reflect all the subtlety (or lack thereof) of your designs and of your testing artillery? Of course, within all the various *DD approaches, some better than others enable you to know whether or not your code conforms to its requirements, but I thought I’d take a moment to reflect on the general idea of a software metric and how it relates to the mothers of all metrics: physical ones, cause you know, I used to be a scientist. Proof: the lab coat on the picture.

The theory of measurement is at the center of all experimental physics. This comes from the realization that any observation of the natural world is ultimately indirect.

For example, when you look at a red ball, you don’t directly perceive it. Rather, photons hit it, some of them are absorbed by the surface of the ball (violet, blue, green and yellow ones, but not red ones) and some of them bounce back (the red ones if you’ve been following). Those red photons that bounced back then hit your eyes, where a lens distorts their paths so that all those photons that came from a specific point on the ball converge to roughly the same spot on your retina. Then, the photoreceptor cells on the retina transform the light signal into electric impulses in your optic nerve, which conveys all that information into your brain and then, only then the complex mechanisms of conscience give you the wonderful illusion of seeing a red ball in front of your eyes.

The brain reconstructs a model of the universe, but what it really ever perceives is a pattern of electric impulses. Everything in between is a rather elaborate Rube-Goldberg contraption that can be trusted most of the time but that is actually rather easy to fool. That it can be fooled at all is the simple consequence that what you observe is an indirect and partial measure of reality rather than reality itself.

When we measure anything in physics, we build our own devices that transform objective reality into perceivable quantities. For example, when physicists say they have “seen” a planet around a faraway sun, they don’t (always) mean that they put their eyes on the smaller end of a telescope and perceived the shape of that planet with their own eyes like I saw the red ball of the previous paragraph. No, what they saw is something like this on a computer monitor:This shows the very small (1.5%) variation of the light coming from the star as the planet transits in front of it. All this really tells them is that something dark that takes about 1.5% of the area of the star passed in front of it. By repeating that observation, they can see that it happens every 3.5 days. That’s it. No image, just measures of the amount of light coming out of a powerful telescope aimed at a star against time.

But just from that minimal data and our centuries old knowledge of celestial mechanics, researchers were able to deduce that a planet 1.27 times the size of Jupiter but 0.63 times its mass and a surface gravity about the same as Earth’s was orbiting that star. That’s an impressively precise description of a big ball of gas that is 150 light years away (that’s 1.4 million billion kilometers in case you’re wondering or 880 thousand billion miles if you insist on using an archaic unit system).

The Rube Goldberg device that enables us to see that big ball of gas from so far away is a mix of optics, electronics and knowledge, the latter being the really awesome part. Science is awesome. The bottom line of all this is that although it seems less “direct” than seeing the red ball with our own eyes, it does just as well deserve to be described as “seeing” it. The only difference is that we’re not seeing with our eyes but more with our brains. How awesome is that?

Where was I?

Yes, you might be wondering what this has to do with software. Well, all that long digression was to show that little data is necessary to infer a lot about the object you’re observing. So code coverage? Sure, it’s just a number, but combined with a few other numbers, it can help get a reliable picture of software quality.

Another point I’d like to make is that a lot of resistance to software metrics comes from the illusion that we know a lot more about our own code than any tool can tell us. But as anyone who has ever tried to read code he wrote only five years ago knows, that is delusional. What you know about your code is a combination of what you remember and what you intended to write, neither of which is particularly reliably representative of what your code is doing. Tools give us a much more reliable picture. Sure, it’s a narrow projection of the code and it doesn’t capture its full reality, but that is exactly the point of a measure: to project a complex object along a scale of our choosing. What set of projections you choose to make is what determines their relevance.

The conclusion of all this is that we should assume that our code is an unknown object that needs to be measured, like that big ball of gas 150 light years away, if we want to get an objective idea of its quality without having our judgment clouded by our own assumptions.

And probably the best tool you can use to do exactly this by the way is NDepend by Patrick Smacchia.

JavaScript class browser: once again with jQuery

Bertrand Le Roy — Fri, 30 Oct 2009 17:43:00 GMT

I’ve already posted twice about that little class browser application. The first iteration was mostly declarative and can be found here:
http://weblogs.asp.net/bleroy/archive/2009/09/14/building-a-class-browser-with-microsoft-ajax-4-0-preview-5.aspx

The second one was entirely imperative and can be found here:
http://weblogs.asp.net/bleroy/archive/2009/10/15/entirely-unobtrusive-and-imperative-templates-with-microsoft-ajax-4-preview-6.aspx

This new version builds on top of the code for the imperative version and adds the jQuery dependency in an attempt to make the code leaner and simpler. I invite you to refer to the imperative code (included in the archive for this post) and compare it with the jQuery version, which shows a couple of ways the Microsoft Ajax Library lights up when jQuery is present.

The first thing I want to do here is convert the plain function I was using to build the browser’s namespace and class tree into a jQuery plug-in:

$.fn.classBrowserTreeView = function (options) {
  var opts = $.extend({},
    $.fn.classBrowserTreeView.defaults,
    options);
  return this;
};

That plug-in will have two options: the data to render (which will default to the root namespaces in the Microsoft Ajax Library), and the node template selector (which will default to “#nodeTemplate”):

$.fn.classBrowserTreeView.defaults = {
  data: Type.getRootNamespaces(),
  nodeTemplate: "#nodeTemplate"
};

For the moment, as you can see, this plug-in does nothing. We want it to create a DataView control on each of the elements of the current wrapped set. We will do this by calling into the dataView plug-in.

You may be wondering where this plug-in might come from. Well, that’s the first kind of lighting up that the Microsoft Ajax Library’s script loader (start.js) will do in the presence of jQuery: every control and behavior will get surfaced as a jQuery plug-in, and components will get added as methods on the jQuery object. This is similar to what I had shown a while ago in this post, only much easier:
http://weblogs.asp.net/bleroy/archive/2009/05/04/creating-jquery-plug-ins-from-microsoftajax-components.aspx

For example, we can write this in our own plug-in to create DataView components over the current jQuery wrapped set:

return this.dataView({
  data: opts.data,
  itemTemplate: opts.nodeTemplate,
});

Now we can wire up the itemRendered event of the data view and start enriching the markup that the DataView control rendered for each data item. First, let’s get hold of the nodes in the rendered template and wrap them:

var elt = $(args.nodes);

Then, if the current node is representing a namespace, we want to hook up the expansion button’s click event so that it toggles visibility of the list of children, and we want to “unhide” the button itself (it has a “hidden” class in the default markup):

if (Type.isNamespace(args.dataItem)) {
  elt.find(".toggleButton").click(function (e) {
    e.preventDefault();
    return toggleVisibility(this);
  }).removeClass("hidden");
}

You can see here that we’re taking advantage of chaining.

Next thing is to set-up the node link itself. We start by inhibiting the link’s default action. Then we set the text for the link, and finally we set the command that will bubble up to the DataView when the link gets clicked:

elt.find(".treeNode").click(
  function (e) {
    e.preventDefault();
    return false;
  })
  .text(getSimpleName(args.dataItem.getName()))
  .setCommand("select");

Here, I’m using a small plug-in to set the command:

$.fn.setCommand = function (options) {
  var opts = $.extend({},
    $.fn.setCommand.defaults, options);
  return $(this).each(function () {
    $.setCommand(this,
      opts.commandName,
      opts.commandArgument,
      opts.commandTarget);
  });
}
$.fn.setCommand.defaults = {
    commandName: "select",
    commandArgument: null,
    commandTarget: null
};

I’m using $.setCommand here, which does get created by the framework for me, but I still need to create that small plug-in to make it work on a wrapped set instead of a static method off jQuery. I’ve sent feedback to the team that setCommand and bind should get created as plug-ins by the framework and hopefully it will happen in a future version.

The last thing we need to do here is to recursively create the child branches of our tree:

elt.find("ul").classBrowserTreeView({
    data: getChildren(args.dataItem)
});

This just finds the child UL element of the current branch and calls our plug-in on the results with the children namespaces and classes as the data.

And this is it for the tree, we can now create it with this simple call:

$("#tree").classBrowserTreeView();

The details view rendering will only differ in minor ways from the code we had in our previous imperative version. The only differences is the use of jQuery to traverse and manipulate the DOM instead of the mix of native DOM APIs and Sys.get that we were using before. For example,

args.get("li").innerHTML =
  args.dataItem.getName ?
    args.dataItem.getName() :
    args.dataItem.name;

becomes:

$(args.nodes).filter("li").text(
  args.dataItem.getName ?
    args.dataItem.getName() :
    args.dataItem.name);

Notice how jQuery’s text method makes things a little more secure than the innerHTML we had used before.

Updating the details view with the data for the item selected in the tree is done by handling the select command of the tree from the following function:

function onCommand(sender, args) {
  if (args.get_commandName() === "select") {
    var dataItem = sender.findContext(
      args.get_commandSource()).dataItem;
    var isClass = Type.isClass(dataItem) &&
                 !Type.isNamespace(dataItem);
    var childData =
      (isClass ? getMembers : getChildren)(dataItem);
    var detailsChild =
      Sys.Application.findComponent("detailsChild");
    detailsChild.onItemRendering =
      isClass ?
        onClassMemberRendering :
        onNamespaceChildRendering;
    detailsChild.onItemRendered =
      onDetailsChildRendered;
    detailsChild.set_data(childData);
    $("#detailsTitle").text(dataItem.getName());
    $(".namespace").css(
      "display",
      isClass ? "none" : "block");
    $(".class").css(
      "display",
      isClass ? "block" : "none");
    $("#details").css("display", "block");
  }
}

Not much change here from the previous version, again, except for the use of jQuery and some chaining.

And that is pretty much it. I’ve made other changes in the script to make use of the new script loader in the Microsoft Ajax Library but that will be the subject of a future post.

Hopefully, this has shown you how the Microsoft Ajax Library can light up with jQuery. The automatic creation of plug-ins feels very much like native jQuery plug-ins and brings all the power of client templates to jQuery. Once we have bind and setCommand plug-ins as well, the Microsoft Ajax Library may become a very useful tool to jQuery programmers just as much as jQuery itself is a very useful tool to Microsoft Ajax programmers.

The code can be found here:
http://weblogs.asp.net/blogs/bleroy/Samples/ClassBrowserWithjQueryUpdated.zip

Update: fixed a problem in Firefox & Chrome.

How to render the same template on the server and client with minimal redundancy

Bertrand Le Roy — Mon, 19 Oct 2009 08:50:00 GMT

Last week, I wrote a post about how the new Microsoft Ajax Library Preview 6 made it a lot easier to write unobtrusive and imperative data-driven applications. Because for the previous preview, I had written a cool little class browser using a declarative style, I thought it would be nice to rewrite this in a completely imperative way. The mistake I made though was to call it unobtrusive. Never mind that ‘unobtrusive’ is a perfectly well-defined word that actually existed way before JavaScript. ‘Unobtrusive JavaScript’ has a very specific meaning that people feel strongly about. To be worthy of that label, an application must basically conform to (at least) those two requirements:

Markup and behavior are strictly separated. That means no DOM-0 event handlers, no custom attributes or tags, and even no microformats imo.
Graceful degradation / progressive enhancement. This means that the application’s script is only used to improve what would work without script, in other words that the application is entirely usable without script.

While my little sample strictly conformed to (1), it didn’t conform to (2). Not because I’m too dumb or ignorant, mind you, but because for this application, it didn’t make any sense at all: the application’s whole point is to display client-side script objects. The server does not have the first clue about the data that needs to be rendered. Which makes it impossible for anything to render without script. Which in turn triggered some unpleasant comments on the post: this was not really unobtrusive JavaScript in the full sense of the term. Not the library’s fault though, just my own for using the wrong example.

The right example

So I thought the best thing to fix this is to provide a more relevant example, one where the server could actually be a fallback scenario.

The new sample code is a fairly simple master-details view on a silly data set: jedi data. We have a WCF web service that is returning a list of jedis and their associated data, which the application can render on the server-side or on the client-side. Once you have data that is available from both the server and client sides, your best and simplest tool to achieve progressive enhancement is the plain <a> tag. You can build the links in your application so that without script, they do something meaningful:

<a href="?jedi=all" id="expandButton">+</a>

What you see above is the + link on the top-left of the screen that will expand the list of jedis. To make it work client-side instead of the server-side, you use script to add a click handler that suppresses the default behavior of the link and replaces it with the equivalent client-side action:

Sys.UI.DomEvent.addHandler(
  Sys.get("#expandButton"), "click", function(e) {
    e.preventDefault();
    jediList.fetchData();
    return false;
  });

That’s fairly easy and has been possible since, well, I’m not sure but it’s been a looong time.

Now there’s the templated rendering. Rendering the same thing from the server and the client without repeating oneself too much is not as simple. The key to it is to render the server template with an empty data item and then to use the result of that as the client template.

<ul id="jediList"
<%if (!isDetails) { %> class="sys-template"<% } %>>
<%var jedis = !isDetails ?
    new List<Jedi>() {new Jedi()} :
    new JediService().GetJedis();
  foreach (var jedi in jedis) { %>
    <li>
      <a href="?jedi=<%= jedi.Name %>">
        <%= jedi.Name%>
      </a>
    </li>
<%} %>
</ul>

This way, there is only one template, only one version of the markup, that we are using on both the server and client sides. When rendered from the server with the actual data set, we get the list right away, and the browser just displays it (and search engines can see the list as well, something you can’t achieve with pure script). When rendered with the dummy dataset, we get the following:

<ul id="jediList" class="sys-template">
  <li><a href="?jedi=all">all</a></li>
</ul>

This markup can be used as a template on the client-side by this code:

var jediList = Sys.create.dataView("#jediList", {
  dataProvider: "JediService.svc",
  fetchOperation: "GetJedis",
  autoFetch: false,
  itemRendered: function(sender, args) {
    var link = args.get("a");
    var dataItem = args.dataItem;
    link.innerHTML = dataItem.Name;
    Sys.UI.DomEvent.addHandler(
      link, "click", function(e) {
        e.preventDefault();
        details.set_data(dataItem);
        return false;
      });
  }
});

The details view is built on pretty much the same principle. The main difference is that it does have additional markup to delimit the fields that we’ll want to set dynamically. Here’s how it renders with the dummy data:

<div id="details" class="sys-template">
    <span id="jediName"></span>
    owns a
    <span id="jediLightSaber"></span>
    lightsaber and is on the
    <span id="jediSide"></span>
    side.
</div>

All the itemRendered handler has to do then is fill in the blanks:

var details = Sys.create.dataView("#details", {
  itemRendered: function(sender, args) {
    args.get("#jediName").innerHTML =
      args.dataItem.Name;
    args.get("#jediLightSaber").innerHTML =
      args.dataItem.LightsaberColor;
    args.get("#jediSide").innerHTML =
      args.dataItem.DarkSide ? "dark" : "light";
  }
});

So what do you think?

Here’s the code (by the way, I’m using the Microsoft CDN in there):
http://weblogs.asp.net/blogs/bleroy/Samples/ServerClientTemplate.zip

Entirely unobtrusive and imperative templates with Microsoft Ajax Library Preview 6

Bertrand Le Roy — Thu, 15 Oct 2009 09:12:00 GMT

Today is the release of the sixth preview of Microsoft Ajax Library. Don’t get fooled by the somewhat silly and long name: this is a major release in many ways. The scripts have been majorly refactored since preview 5. Check out the other posts out there (links at the bottom of this post) to see just some of the many new features that are in there. Some of my favorite are all the small improvements that have been made to make imperative instantiation of components and templated contents easier than ever. Many of you have told us that you preferred to do things imperatively and this release makes it a lot better.

When Preview 5 came out, I built a simple class browser using the declarative syntax. The class browser shows the hierarchy of namespaces and classes in a tree view on the left side of the page, and the details of whatever’s selected in the tree on the right side of the page:http://weblogs.asp.net/bleroy/archive/2009/09/14/building-a-class-browser-with-microsoft-ajax-4-0-preview-5.aspx

It still works (and an updated version is attached to this post), but I thought I would demonstrate how you can take that same sample and re-implement it in a completely imperative way. Of course, you never have to go all the way one way or another, and it’s always possible for example to use the nice declarative syntax for bindings but instantiate your components imperatively if you choose to do so. In this post, I’m deliberately going imperative all the way. Just keep in mind this is rather extreme.

The first thing to notice in the new version is that the markup is perfectly clean and contains no weird extension, namespace or custom binding syntax whatsoever. It’s 100% pure HTML 5. Here is for example the complete markup for the tree view on that page:

<ul id="tree" class="tree"></ul>

<ul id="nodeTemplate" class="sys-template">
    <li>
        <a class="toggleButton" href="#">+</a>
        <a class="treeNode" href="#"></a>
        <ul></ul>
    </li>
</ul>

The script that builds the dynamic contents is bootstrapped by the following code:

<script type="text/javascript"
        src="Scripts/start.js"></script>
<script type="text/javascript">
Sys.loadScripts(["Scripts/Tree.js"], function() {
  Sys.require([Sys.components.dataView], function() {
    createTreeView("#tree",
                   Type.getRootNamespaces(),
                   "#nodeTemplate");
    Sys.create.dataView("#detailsChild", {
      itemRendered: onDetailsChildRendered
    });
  });
});
</script>

We’re making use of the new script loader here: we first include the bootstrapper file, start.js, and then we declare that we need one custom script, “tree.js” and everything necessary to instantiate a DataView. The script loader will figure out on its own the set of scripts it needs to download for that. Once those scripts have been downloaded, we call createTreeView, which is custom code that we’ll look at in a moment that creates nested DataView controls over the markup. We also create a second DataView to display the details of what’s selected in the tree.

Notice that we set some properties to a selector string here (for example “#nodeTemplate”). This is actually a breaking change from the previous preview, which only understood id strings. Microsoft Ajax does not include a full selector engine but it does understand the most basic of selectors (.class, tagName and #id). But where it gets really interesting is that if you had included jQuery on the page, the framework would detect it and enable you to use full selectors everywhere. Isn’t that sweet?

So how does the imperative approach compare with the declarative one? Well, for instantiating components, you already have an example above, where we use Sys.create.dataView. But what about wiring up events, setting text contents and attribute values, instantiating components over the markup inside the template?

All those are done by post-processing the template instances after they’ve been instantiated, by handling the itemRendered event:

itemRendered: function(sender, args) {
  // do magic
}

Wiring up events is as simple as getting a reference to an element and calling addHandler:

var toggleButton = args.get(".toggleButton");
Sys.UI.DomEvent.addHandler(toggleButton, "click",
  function(e) {
    toggleVisibility(this);
  }, true);

The args.get function, which you will use a lot, takes a selector and returns the first element that matches it inside the template. Here, we are looking for an element with class “toggleButton”, but a local id would work just as well.

To set text contents and attribute values is trivial once you know how to get references to elements from local selectors (remember, jQuery also works here transparently or even explicitly when and if you need it).

Finally, instantiating components is also quite easy. For example, here is the code that creates an inner DataView for the child nodes of a node in the tree, recursively:

var childView = args.get("ul");
createTreeView(childView,
               getChildren(args.dataItem),
               nodeTemplate);

The args.get funtion is used once more to get a reference to the first UL element within the template, and it is then easy to do a recursive call into our tree creation function and build the new branch of the tree.

The command bubbling feature that makes it so easy to wire up custom commands into a template is still usable in imperative code:

var treeNode = args.get(".treeNode");
Sys.setCommand(treeNode, "select");

Finally, there is one feature that I’m not using in that sample, but that’s immensely useful, and I’m talking of course of live bindings. Those work too, all you have to do is call the Sys.bind function and give it the target object, the name of the target property to bind, the source object and the source property name.

To render the details view, I decided to not use a single item DataView like I did with the declarative version: since I’m going to use imperative code instead of declarative bindings, it is just as easy to directly manipulate the DOM that already exists, and do some hiding and showing of elements:

function onCommand(sender, args) {
  if (args.get_commandName() === "select") {
    var dataItem = sender.findContext(
      args.get_commandSource()).dataItem;
    var isClass = Type.isClass(dataItem) &&
                 !Type.isNamespace(dataItem);
    var childData =
      (isClass ? getMembers : getChildren)(dataItem),
      namespaceElementsDisplay = 
        isClass ? "none" : "block",
      classElementsDisplay =
        isClass ? "block" : "none",
      detailsChild =
        Sys.Application.findComponent("detailsChild");
    detailsChild.onItemRendering =
      isClass ?
        onClassMemberRendering :
        onNamespaceChildRendering;
    detailsChild.set_data(childData);
    Sys.get("#detailsTitle").innerHTML =
      dataItem.getName();
    Sys.get("#namespacesColumn").style.display =
    Sys.get("#classesColumn").style.display =
      namespaceElementsDisplay;
    Sys.get("#propertiesColumn").style.display =
    Sys.get("#eventsColumn").style.display =
    Sys.get("#methodsColumn").style.display =
    Sys.get("#staticMethodsColumn").style.display =
      classElementsDisplay;
    Sys.get("#details").style.display = "block";
  }
}

We do have a DataView to render the contents of the currently selected object though. The nice trick we used with the declarative version to dynamically switch the target place holder where the template gets rendered is still there, which enables a single DataView control to dispatch the data into two to four separate lists (or however much you want for that matter):

function onNamespaceChildRendering(args) {
    args.set_itemPlaceholder(
        Type.isClass(args.get_dataItem()) ?
            "#classPlaceHolder" :
            "#namespacePlaceHolder"
    );
}

I think all this is pretty cool and I hope the comparison between the declarative version and the imperative version of this little application gives you a sense of the flexibility that the Microsoft Ajax library now offers, and of how much you can choose your own development style and do pretty much anything with the same ease.

Download the code for this post here:
http://weblogs.asp.net/blogs/bleroy/Samples/Preview6ClassBrowser.zip

Microsoft Ajax Library Preview 6 can be downloaded from here:
http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34488

Here are a few links about this release:
http://weblogs.asp.net/scottgu/archive/2009/10/15/announcing-microsoft-ajax-library-preview-6-and-the-microsoft-ajax-minifier.aspx
http://channel9.msdn.com/posts/jsenior/Announcing-Microsoft-Ajax-Library-Preview-6/
http://www.jamessenior.com/post/How-the-Script-Loader-in-the-Microsoft-Ajax-Library-will-make-your-life-wonderful.aspx

HTML now a data format

Bertrand Le Roy — Sat, 10 Oct 2009 06:54:00 GMT

About a year ago, I asked the question on this blog whether HTML could and should be used as a data format:

http://weblogs.asp.net/bleroy/archive/2008/11/26/should-html-be-considered-as-a-data-format.aspx

After all, it actually already has semantic constructs appropriate for tabular data, for collections, for hierarchical data and for object graphs of any kind.

Well, apparently I wasn’t the only one to think that (not that I expected I was):

http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html

Ajax Control Toolkit: new controls, bug fixes

Bertrand Le Roy — Thu, 01 Oct 2009 00:28:00 GMT

And we have a new release of Ajax Control Toolkit. I didn’t work on this one but there are some nice things in there nonetheless :)

First, new controls!

SeaDragon: I’ve blogged before about Seadragon, the JavaScript-only way to do Deep Zoom. It became a lot easier to use a few month ago when the need for tools disappeared and you can just point to any image on the web and immediately get the URL and script tag to put on your page:

Now with this release of Ajax Control Toolkit, including and controlling Deep Zoom from an ASP.NET page is also very easy:

<ajaxToolkit:Seadragon ID="Seadragon"
    CssClass="seadragon" runat="server"
    SourceUrl="sample.xml"/>

James Senior just released a screencast on how to create Deep Zoom contents for the new Seadragon control:
http://channel9.msdn.com/posts/jsenior/Seadragon-Ajax-Control-Quick-Start-Guide/

AsyncFileUpload: This is by far one of the most requested controls for ACT. File upload fields, while a part of HTML, do not work with Ajax/XHR requests (for security reasons, JavaScript can’t access the contents of the field). The only way to use them is to get the browser to do a real form post.

This new control makes it a lot easier to handle file uploads from your Ajax applications by providing an abstraction on top of the form posting:

<ajaxToolkit:AsyncFileUpload
    OnClientUploadError="uploadError"
    OnClientUploadComplete="uploadComplete" 
    runat="server" ID="AsyncFileUpload1"
    Width="400px" UploaderStyle="Modern" 
    UploadingBackColor="#CCFFFF"
    ThrobberID="myThrobber"/>

It works pretty much as advertised: just drop the control on the page, and you can upload files without a full postback. It looks just like Ajax and requires no plug-in of any kind.

The control has client and server-side events that get triggered when the file has been uploaded. On the server-side, you have access to the uploaded file’s byte stream, which you can save to disk (or database, or whatever).

Bug fixes: This release also has some new bug fixes (courtesy of Obout) for some of the top-voted issues.

Download the new release here:
http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=33804

Try the live demos here:
http://www.asp.net/ajax/ajaxcontroltoolkit/samples/

Stephen's in-depth post about this release:
http://stephenwalther.com/blog/archive/2009/10/01/new-ajax-control-toolkit-release.aspx

Fun with C# 4.0’s dynamic

Bertrand Le Roy — Thu, 17 Sep 2009 07:50:29 GMT

There’s been some debate recently on the new “dynamic” keyword in C# 4.0. As has been the case with many features before it, some love it, some hate it, some say it bloats the language, yadda yadda yadda. People said that about lambdas. Me, I’ll just use it where I see a use case, thank you very much.

In the case of dynamic, another frequent comment is that a statically-typed language should not try to look like a dynamic language. Well, I just don’t believe in that distinction.

Being dynamic is a trait that a language can have, and some have it more than others. But as soon as a language has a dictionary type or indexers, and most modern languages do, it starts having dynamicity. What people call a dynamic language is just one where it’s the only available type.

Now there is type safety of course, but to me that’s a different feature that is not as coupled with “statically-typed-ness” as we usually tend to think. Case in point, many modern JavaScript engines analyze the code in order to apply many of the optimization techniques that static languages have been applying at compile-time.

So just how dynamic was C# before 4.0? Well, there are dictionaries and indexers, as I’ve said, but there are also other interesting and less known features such as custom type descriptors. Go look them up if you don’t know about them. Type descriptors are for example used to provide a level of indirection between a design surface and the components being edited.

But type descriptors can also be built completely dynamically and decide to expose a completely virtual object model that is entirely built at runtime. Of course, the client code for that object has to go through the right APIs to make use of that quasi-dynamic model. And of course those APIs are not simple. Implementing a custom type descriptor in itself is not exactly trivial.

If anything, the dynamic keyword is going to provide a friendlier syntax for this sort of thing. One problem is that it has no relationship whatsoever with custom type descriptors.

So I thought I’d try to bridge that gap. How can we take a type that exposes a custom type descriptor, such as DataRowView, and transform that into something that plays nice with the dynamic keyword? What we want to be able to write is something like the following:

var table = new DataTable("People");
table.Columns.Add("FirstName", typeof(string));
table.Columns.Add("LastName", typeof(string));
table.Columns.Add("Children", typeof(int));
table.LoadDataRow(
    new object[] {"Bertrand", "Le Roy", 2},
    LoadOption.OverwriteChanges);
var tableView = new DataView(table);

dynamic dynRecord = 
    new TypeDescriptorDynamicWrapper(tableView[0]);
Console.WriteLine("{0} {1} has {2} children.", 
    dynRecord.FirstName, 
    dynRecord.LastName, 
    dynRecord.Children);

To do that, I built the TypeDescriptorDynamicWrapper that you see being used above. What is does is pretty simple, as it just inherits from DynamicObject and implements TryGetMember as follows:

public override bool TryGetMember(
    GetMemberBinder binder, out object result) {

    var name = binder.Name;
    var property = _properties.Find(
        p => p.Name.Equals(name,
            binder.IgnoreCase ?
            StringComparison.OrdinalIgnoreCase :
            StringComparison.Ordinal));
    if (property == null) {
        result = null;
        return false;
    }
    result = property.GetValue(
        _descriptor.GetPropertyOwner(null));
    return true;
}

As you can see, the method just finds the right property on the type descriptor and delegates to it if it finds it. I didn’t implement the setting of properties but it would be fairly easy to do so.

Using that simple wrapper, the program above just works and displays:

Bertrand Le Roy has 2 children.

That was easy. Now what about the reverse, getting any dynamic object to expose a custom type descriptor?

Well, that’s where things get tricky.

The dynamic capabilities of C# 4.0 are targeted at two things:

Providing syntactic sugar for getting to dynamic members that looks like accessing statically-defined ones.
An easy way to create dynamic types by implementing a form of method_missing.

But there is one thing that exists in DLR but didn’t make it to C# yet, which is the ability to easily reflect on dynamic objects (other than by using the #1 syntactic sugar above).

For example, in JavaScript, a.foo and a[“foo”] are exactly the same thing, which enables easy reflection: you can enumerate the members of an arbitrary object and do stuff like a[someStringVariable].

Doing the same thing with C# on dynamic objects is much more difficult. The equivalent of a.foo is easy, but not the equivalent of a[someStringVariable].

Forget about using reflection, it doesn’t work on dynamic objects because dynamic really is a compiler trick. There is no such thing as a “dynamic” type to reflect on. It’s a keyword that tells the compiler to relax type-checking and generate code to access those dynamic members at runtime. If you try to reflect on an instance of one of the dynamic-friendly type, such as ExpandoObject, you’ll see the statically-defined members of that type, but not the dynamic ones. In a way, you’re looking at the messenger instead of the message.

This is a problem because in order to wrap an arbitrary dynamic object into a custom type descriptor, we need to be able to reflect on the dynamic members of that object.

To solve the problem, and with some help from the nice folks who are building the DLR, I compiled a simple program that sets and gets a property on a dynamic object, an then I looked at the generated code from Reflector (“luckily”, Reflector is not yet aware of dynamic and shows the generated code instead of something closer to the actual code you wrote).

I was then able to refactor that code and replace the string constants for the accessed member with a method parameter, thus creating a generic way to access dynamic object properties:

public static object GetValue(
    object dyn, string propName) {

    // Warning: this is rather expensive,
    // and should be cached in a real app
    var GetterSite = 
        CallSite<Func<CallSite, object, object>>
        .Create(
          new CSharpGetMemberBinder(propName,
            dyn.GetType(),
            new CSharpArgumentInfo[] {
              new CSharpArgumentInfo(
                  CSharpArgumentInfoFlags.None, null)
            }));
    return GetterSite.Target(GetterSite, dyn);
}

public static void SetValue(
    object dyn, string propName, object val) {

    // Warning: this is rather expensive,
    // and should be cached in a real app
    var SetterSite = 
      CallSite<Func<CallSite, object, object, object>>
      .Create(
        new CSharpSetMemberBinder(propName,
          dyn.GetType(),
          new CSharpArgumentInfo[] {
            new CSharpArgumentInfo(
              CSharpArgumentInfoFlags.None, null),
            new CSharpArgumentInfo(
              CSharpArgumentInfoFlags.LiteralConstant |
              CSharpArgumentInfoFlags.UseCompileTimeType,
              null)
          }));
    SetterSite.Target(SetterSite, dyn, val);
}

Once we have that, implementing the custom type provider is relatively straightforward. The only part that is not immediately obvious is how to enumerate the properties of the dynamic object.

This is done as follows. Dynamic objects implement IDynamicMetaObjetProvider, which has a GetMetaObject method, which returns a DynamicMetaObject object on which you can call GetDynamicMemberNames to get the list of members.

We can now take any dynamic object and for example present it in a property grid, which is one of those components that know how to handle custom type descriptors but not the new dynamic objects:

dynamic person = new ExpandoObject();
person.FirstName = "Bertrand";
person.LastName = "Le Roy";
person.Children = 2;
propertyGrid1.SelectedObject = 
    new DynamicTypeDescriptorWrapper(person);

And here’s what the results look like:

In conclusion, I’d say that although we are having a healthy debate on the dynamic keyword (and we should have that debate), I’m confident that in one or two years, we’ll have some incredibly imaginative uses of the feature that will simply blow us away and will make the current conversation a little sillier than it seems today. The feature itself is also in its infancy and not only will the use cases emerge way beyond what even its designers envisioned, it will also grow and become more usable with future versions of the language, as is made clear by the gap in functionality that still exists today with the full DLR project.

You can download the code for this article here:
http://weblogs.asp.net/blogs/bleroy/Samples/Bleroy.Sample.Dynamic.zip

Building a class browser with Microsoft Ajax 4.0 Preview 5

Bertrand Le Roy — Mon, 14 Sep 2009 07:29:37 GMT

The Microsoft Ajax Library 4.0 Preview 5 is the first release of Microsoft Ajax that I didn’t participate in: I left the team a few months ago. But that doesn’t mean I don’t love what’s in there, and I really do. And by the way I’ve also seen what’s in Preview 6 too and man that will seriously rock.

So I thought I’d write a little something to celebrate the new preview. The new features include recursive templates, which is pretty much begging us to implement a treeview with it, and we’ll do just that in this post.

There is also an intriguing capability, which enables you to dynamically set what template to render for each data item, and where to render it. At first, this doesn’t look like the most useful thing in the world, but it actually opens up some very interesting possibilities, which we’ll also show in this post.

The sample code that I’m going to write for this post is a rudimentary class browser. It will render a treeview representing the hierarchical structure of namespaces and classes in Microsoft Ajax, and clicking one of the tree nodes will render a details view for it: a list of classes and subnamespaces for namespaces, and a grouped list of members for classes.

Let’s start with the tree. It will be rendered as nested unordered lists by a simple recursive DataView:

<ul id="tree" class="tree"
    sys:attach="dataview"
    dataview:data="{{ Type.getRootNamespaces() }}"
    dataview:itemtemplate="nodeTemplate"
    dataview:oncommand="{{ onCommand }}">
</ul>

<ul id="nodeTemplate" class="sys-template">
  <li>
    <a href="#" onclick="return false;"
       sys:command="select">
      {{ getSimpleName($dataItem.getName()) }}
    </a>
    <ul sys:attach="dataview"
        dataview:data="{{ getChildren($dataItem) }}"
        dataview:itemtemplate="nodeTemplate"
        dataview:oncommand="{{ onCommand }}"></ul>
    </li>
</ul>

On the first UL, which is the outer DataView for the tree, you can see that we set the data property to Type.getRootNamespaces(), which returns the set of root namespaces currently defined.

We also set the template to point to the “nodeTemplate” element, which has to be outside the DataView itself when doing recursive templates. Note that the outer node of the template, the UL, won’t actually get rendered into the target ul (tree). It is only a container.

The command event of the DataView is hooked to the onCommand function, and we’ll get back to that when we couple the tree with the detail view.

In the template itself, you can see we have a link with the select command so that clicking it will trigger the nearest onCommand event up the DOM.

The text of that link is the results of a call to getSimpleName, which will extract the last part of the fully-qualified name of the namespace or class.

After that link, we find another DataView control. The data property of that control points to an array of namespaces and classes under the current object. But the nice part here is that the template property points to “nodeTemplate”, its own parent, enabling the recursive nature of the tree.

In other words, we’ve morphed a simple DataView control into a tree, with minimal effort and code.

There is just one thing missing to the tree, and that is the +/- buttons that will collapse and expand the tree nodes. This is actually very easy to set-up using CSS and some simple script. First, let’s collapse the tree by default. This is done by defining the style of the tree as follows in our stylesheet:

.tree ul 
{
    padding: 0;
    display:none;
}

This has the effect of collapsing all unordered list nodes under the tree.

The +/- button is created by adding the following to the template, right before the existing link:

<a class="toggleButton" href="#"
   sys:if="Type.isNamespace($dataItem)" 
   onclick="return toggleVisibility(this);">+</a>

The button is a simple link whose rendering is conditioned by whether the current data item is a namespace: only namespaces can be expanded, classes are leaf nodes.

The toggling function itself is fairly simple:

function toggleVisibility(element) {
    var childList = element.parentNode
                     .getElementsByTagName("ul")[0],
        isClosed = element.innerHTML === "+";
    childList.style.display =
        isClosed ? "block" : "none";
    element.innerHTML = isClosed ? "-" : "+";
    return false;
}

This just toggles the display style of the first child UL between none and block, and the text of the link between + and –.

So there it is, we have built a simple tree by simply making use of the recursive capabilities of DataView and some very simple script.

Before we look at the details view, let’s look at the code that gets called when the user selects a node in the tree:

function onCommand(sender, args) {
    var dataItem = sender.findContext(
        args.get_commandSource()).dataItem;
    $find("details").set_data(dataItem);
}

That code gets a reference to the data item for the selected node from the template context that we can get from the sender of the event (the inner DataView that contains the selected node) using the command source as provided by the event arguments (that source is the element that triggered the command). We can then set the data of the details DataView to that data item, which will trigger that view to re-render.

Now let’s build the details view. The details view will display the child namespaces and classes if a namespace is selected in the tree, and the properties, events and methods (instance and static) in the case of a class.

For each case, we’ll use a different template: “namespaceTemplate” for namespaces, and “classTemplate” for classes, but we’ll do so from the same DataView. This dynamic template switching is done by handling the onItemRendering event of the DataView:

function onDetailsRendering(sender, args) {
    var dataItem = args.get_dataItem();
    args.set_itemTemplate(Type.isNamespace(dataItem) ?
        "namespaceTemplate" : "classTemplate");
}

This code gets the data item from the event arguments and sets the itemTemplate property depending on its type.

Each of these two templates will have to display the contents of the selected object. But, and that will be the tricky part, we want all those to be neatly grouped into separated lists.

One way to do that would be to have one DataView per list but where would the fun be in that? Here, we are going to enumerate only once through the data items to display and dispatch them dynamically to this or that placeholder depending on their nature.

Once more, the key to doing that will be handling the onItemRendering event:

function onNamespaceChildRendering(sender, args) {
    if (Type.isClass(args.get_dataItem())) {
        args.set_itemPlaceholder("classPlaceHolder");
    }
}

This code is simply changing the rendering place holder for the curent item from the default (the DataView’s element) to “classPlaceHolder” if the current data item is a class (instead of a namespace). The template itself looks like this:

<div id="namespaceTemplate" class="sys-template">
   <h1>{{ $dataItem.getName() }}</h1>
   <div class="column">
     <h2>Namespaces:</h2>
     <ul sys:id="namespacePlaceHolder"
         sys:attach="dataview"
         dataview:data="{{ getChildren($dataItem) }}"
         dataview:itemtemplate="namespaceChildTemplate"
         dataview:onitemrendering=
           "{{ onNamespaceChildRendering }}">
     </ul>
   </div>
   <div class="column">
   <h2>Classes:</h2>
     <ul><li sys:id="classPlaceHolder"></li></ul>
   </div>
</div>

<ul id="namespaceChildTemplate" class="sys-template">
  <li>{{ $dataItem.getName() }}</li>
</ul>

As you can see, there really is only one DataView in there, and thanks to the code above, it can dispatch its rendering to different places if necessary. The template for the items of that DataView happens to be the same in all cases (namespaceChildTemplate) but it could be easily different, as it was for the parent details view.

The template for displaying classes is essentially the same thing, but with four placeholders instead of two.

So here’s what it looks like in the end:

Key takeaways of this post are that it’s now super-easy to render hierarchical data structures with DataView, and that you can do some interesting grouping of data on the fly by handling the item rendering event.

You can play with the class browser live here:
http://boudin.vndv.com/AjaxPreview5Tree/default.htm

And you can download the code here:
http://weblogs.asp.net/blogs/bleroy/Samples/AjaxPreview5Tree.zip

Microsoft Ajax 4.0 Preview 5:
http://aspnet.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=32770

Jim and Dave’s posts on Preview 5:
http://weblogs.asp.net/jimwang/archive/2009/09/11/asp-net-ajax-preview-5-and-updatepanel.aspx
http://weblogs.asp.net/infinitiesloop/archive/2009/09/10/microsoft-ajax-4-preview-5-the-dataview-control.aspx

querySelectorAll on old IE versions: something that doesn’t work

Bertrand Le Roy — Tue, 01 Sep 2009 01:03:13 GMT

In today’s post, I’m going to show an interesting technique to solve a problem and then I will tear it to pieces and explain why it is actually useless. I believe that negative results should also be published so that we can save other people from wasting time trying the same thing. So here goes…

A few days ago, a post on Ajaxian proposed a new version of a somewhat old technique to implement querySelectorAll on old versions of IE, using the browser’s native CSS engine. That sounds like a great idea at first, and the hack is quite clever. The idea is to dynamically add a CSS rule to the document that has the selector that you want to evaluate, and an expression that adds the matched elements to a global array.

When I read this, it reminded me of a similar approach that I had tried a few years ago. At the time, we were considering implementing our own selector engine (we had not yet decided to integrate jQuery to our Ajax offerings, which in the end made the whole effort moot) so we explored a number of approaches.

My idea was different in that it doesn’t use expressions at all. It does dynamically create a style rule, but instead of an expression, it just sets a non-existing “foo” style property to the equally arbitrary value of “bar”. It then scans the whole document (using the much decried and IE-specific but very fast document.all) and gets the computed style for each of the elements. We then look for the foo property on the resulting object and check whether it evaluates as “bar”. For each element that matches, we add to an array.

Here’s the code:

(function() {
    var style = document.styleSheets[0] ||
                document.createStyleSheet();
    window.select = function(selector) {
        style.addRule(selector, "foo:bar");
        var all = document.all, resultSet = [];
        for (var i = 0, l = all.length; i < l; i++) {
            if (all[i].currentStyle.foo === "bar") {
                resultSet[resultSet.length] = all[i];
            }
        }
        style.removeRule(0);
        return resultSet;
    }
})();

or, in minimized form:

(function(){var d=document;var a=d.styleSheets[0]||
d.createStyleSheet();window.select=function(e){
a.addRule(e,"f:b");var l=d.all,c=[];
for(var b=0,f=l.length;b<f;b++)if(l[b].currentStyle.f)
c[c.length]=l[b];a.removeRule(0);return c}})()

That’s 235 characters, which is not too bad (although not quite #twitcode small).

The first problem with that approach though is that because it’s using the native CSS selection engine in IE, it has the same limitations and quirks. That means no fancy CSS 3 (or even 2) selectors. It also means any IE bug will surface into the result set.

In other words, if you want more selectors than that, you will need to parse the selector string and branch off the code to another, more complete engine whenever something not supported is used. It also means that you need to know what is supported and what isn’t. That could be done through some dynamic discovery but doing so, we are getting into much complexity.

So limited as it is, how does it perform?

I ran the code in a SlickSpeed test (where I removed the selectors that it couldn’t handle) on IE6 and the good news is that despite the document.all scan and the current style computation, it’s more than three times faster than Paul Young’s implementation that got featured on Ajaxian.

But the bad news is that it’s also six times slower than jQuery:

I’m afraid a hack to use the native CSS selection engine of the browser is always going to be slower than an optimized pure JavaScript implementation (to be clear, I’m not talking about native implementations of querySelectorAll, but about hacks such as this which try to surface the feature on older IE versions that don’t have querySelectorAll). Somewhat counter-intuitive, but true.

End of story. Just use jQuery. :)

How to install and configure Visual Studio Team Explorer

Bertrand Le Roy — Fri, 28 Aug 2009 21:24:04 GMT

One of the challenging aspects of working with TFS as your source control system is very unfortunately the installation of the client software.

Over the past few years, I’ve been managing a number of small and large projects on CodePlex, and while the Subversion bridge has provided a much needed simple choice of client software, TFS remains its native protocol, which makes it still very much relevant to people who do a lot of work there.

But as I said, installing the client software may be challenging.

The first and main problem here is that Team Explorer, while free, comes in a very unfriendly format: an ISO image of the DVD. I asked the team why they made that weird and less than optimal choice, and apparently there are some technical reasons why a simple msi wouldn’t work. I wasn’t completely satisfied with the explanation (it’s still a bad customer experience) but at least there is hope as the plan is to make it a lot smoother with Visual Studio 2010.

So let’s download that thing. It can be found here:

http://www.microsoft.com/downloads/details.aspx?familyid=0ed12659-3d41-4420-bbb0-a46e51bfca86&displaylang=en

Just click on the “Download” button and store the file in a local temporary folder. At 387.4 MB it’s a pretty big download (especially when compared with this) but it does contain the Visual Studio shell, which explains it, kind of. So you probably have time for a cup of coffee or two, trip to Seattle’s Best included.

Oh, by the way, to be clear, you do *not* need a version of Visual Studio on the box to install Team Explorer, it is a standalone application, but if you do have one, it will integrate with it.

Now that you have the IMG file, we can extract it. There are several options to extract or burn an ISO, but I’ll use a free one here. We won’t burn the image to a DVD (the only reason I could see why you’d want to do that is if you want to make multiple installs, but you might as well extract the ISO to a network share).

The free option I’ve selected is ExtractNow, which you can download from here:

http://www.extractnow.com/

Click on the “Download ExtractNow!” link on the bottom of the page and run the installer. When it asks you if you want to run it, say yes. The UI is a little weird: what you need to do now is right click on the white surface on the ExtractNow window and select “Add archive”:Then, navigate to wherever you downloaded the VS2008TeamExplorer.iso file, select it and click the “Open” button. Now click the “Extract” button and wait for the extraction to complete. You should now have a VS2008TeamExplorer folder next to the iso file. You can close ExtractNow and maybe even uninstall it until the next time you need it…

Open that folder and double-click “Setup”. Follow the instructions (the default settings should be fine) and wait for the install to complete. Fortunately, it doesn’t take nearly as long as installing the full VS.

Once this is done, you should be up and running. Let’s launch the shell and connect to a CodePlex project. From the Team Explorer window, click the “Add existing team project button:

Click on the “Servers” button and then on the “Add” button to add the relevant CodePlex server. The data that you need to enter there can be found on the “Source Code” tab of your project’s site on CodePlex by clicking on Source Control Setup / Visual Studio Team Explorer (right side of the page).

You can copy the server, port and protocol information into the Team Explorer add server window:

You can now close that window by clicking OK. You will then get prompted for your username and password. CodePlex also gave you that (notice the “snd\” domain prefix and “_cp” postfix) but let’s make sure that we only have to do this once. To that effect, let’s cancel and go to the Windows user account control panel and click on “Manage your credentials”:

Then click on “Add a Windows Credential”. Copy there the server name, your username and your password:

Click OK, then switch back to Visual Studio and click OK again. This time, you shouldn’t be prompted for credentials unless you made a typo in the above dialog. You may now click close and then select any number of projects you want to work with:

The team explorer window now shows the available projects:

If you then double-click “Source Control” under any of the projects, you can explore the contents of the project and map them to a local folder. To do that, first create the target directory from Windows Explorer, then right click a project in the Visual Studio Source Control Explorer and select “Get Latest Version”:

You will then be prompted for a local directory to which you want to map the source-controlled remote directory. Select the directory that you just created and click OK.

And… that’s it, you’re all set. You can now open any file or project from the locally mapped folder, check out code, modify it and then check it back in using the Pending Changes window.

I hope this helps.

Walking the tight rope

Bertrand Le Roy — Thu, 27 Aug 2009 22:40:00 GMT

I think today is an appropriate time to write this post, as Rob Conery is leaving Microsoft tomorrow. “Who?”, you might ask. Rob is the author of the excellent MVC Storefront and Kona series where he explored the challenges in building an MVC-bound storefront application. I’ve been working with Rob for a few months on the continuation of that, which will be the subject of this post.

This is challenging for a number of reasons.

First, Rob’s are large shoes to fill (he’s a 12, I’m an 11). That’s fine, I’m just going to do things my way and try to have as much fun as possible (and communicate that if I can).

Second, the focus of the application has changed and that is a much more important challenge. Rob built this as a learning tool, as much for him as for his readers.

In the team that I’m now a part of, we have taken that Kona code as the basis to build something that will hopefully be more like a real world application. We are still very much in an exploratory mode (hence our attempts at migrating the application to NHibernate and SQLite) but our ultimate goal is to provide an application that people can download and build a business on, with a focus on simplicity and extensibility.

Fine, you may say, but why build something new instead of contributing to existing applications? Well, the very short answer is that we are also going to do that. One of the things we are already doing is to work with various application developers on reusing things like the plug-in engine and what sharing opportunities that brings.

But I can already hear some of you saying “oh so you’re not just building an application, what you’re really doing is building yet another framework”. To which I’m tempted to answer with another question: what do you mean “another”? Where is my Django-style application-level framework for ASP.NET? But that may sound like I’m downplaying the great efforts that many people are putting towards exactly that. I clearly am not. Actually, if you are working on something like that and we’re not already talking, I would love to know about it. I want to know how we can help.

A total n00b’s guide to migrating from a custom data layer to Nhibernate: so many choices

Bertrand Le Roy — Thu, 20 Aug 2009 21:05:00 GMT

One of the great things about NHibernate is its vibrant community and ecosystem. So many people are using it or building other libraries on top of it that you can be pretty sure that there is always a reasonable solution to any problem you might face. Or several.

This means of course that there are lots of choices you can make about how you use NHibernate. While this is essentially a good thing, too many choices can be intimidating when starting to use a technology.

In this post, I’ll present some of the first choices you are going to have to make for your NHibernate code. I’ll explain the choices that our team made for our own migration and an attempt at explaining why you would make different choices depending on the particular context of your application.

1. Database first or object first?

That’s an easy one.

If you already have a database, it’s database first.

If you already have both, all you have to do is build the mappings.

If you already have an object model, it depends how much you care about the shape of your database. NHibernate has reasonable defaults so you might be able to get away with object first and reasonably fuzzy mappings (or even a generated mapping). The obvious advantage of that approach is that you’ll be able to easily move database engines without having to rewrite anything but your web.config.

If you need more control over the shape of the database, you might be able to achieve just that by making your mappings more explicit but still keep generation of the database from NHibernate.

If that’s still not enough control, just don’t generate the database, and instead manually maintain database, objects and mappings.

In our own project, we had the database already, but we want to abstract ourselves of a particular engine eventually, so we are moving from a database first approach to an object first approach. Extensions to the application will have to work independently of the database engine (because the app itself is), so it will have to be object first for them.

2. To lazy-load or not to lazy-load?

Lazy loading is the practice of delaying the loading of an object until the moment when it is actually used for the first time. If you have a collection of blog post objects for example, and those objects each have a property that is their collection of comments, you won’t want those comments to be queried from the database unless you are actually going to use them.

Lazy loading is obviously a good thing, but you also must know that it can get you in trouble. So it can be a dangerous tool, but its usefulness far outweighs the danger.

I’ve also mentioned in the previous post that lazy loading requires the use of dynamic proxies and that these in turn require that you run in higher trust than medium. Well, several commenters pointed out that this isn’t exactly true.

Lazy loading of collection properties does not require the generation of dynamic proxies at all because NHibernate can set the value of those properties directly to a list type that already implements lazy loading. It is only in the case of lazy loading of properties or 1-1 associations that the proxy generation will be necessary. In other words, if your database schema only has 1-N and N-N associations or if you don’t mind eager loading on your 1-1’s, NHibernate can run in medium trust with no problem. This is the approach we are currently using in our application. We will revise it if necessary.

The first way to achieve medium trust lazy-loading is to generate the proxies at build-time instead of dynamically at runtime. Caveat with this approach is that the generated proxies will be specialized to a dialect, which might or might not be a problem. You may be able to mitigate that problem by building dialect-specific versions for all databases that you target, but this is definitely less convenient than the entirely dynamic approach.

The second approach is to fix the code of the proxy factory that you are using to work in medium trust, which is entirely achievable but clearly not for n00bs. Apparently patches are on their way here and this could make the whole problem go away in the near future.

And the last and lamest approach is to disable lazy loading entirely.

3. What dynamic proxy factory to use?

Once you’ve decided that you’re going to use lazy loading and are going to need dynamic proxies, you still have to decide which proxy factory you’re going to use. Three choices are available out of the box: Castle, LinFu and Spring.

If you want to work with Castle.ActiveRecord or Castle.Windsor, Castle is the obvious choice.

If you want to work with Spring, Spring is obviously what you should use.

If you are not using Castle or Spring, or have no idea what you want, LinFu can be a reasonable default.

In our application, because we don’t need dynamic proxies for the moment, we haven’t had to choose.

3. XML, attributes or fluent mappings?

XML

XML mappings are the default but some people dislike XML’s verbosity. There is also a fair amount of repetition and magic strings involved. Refactoring won’t propagate automatically to the mapping files. Advantages include that it’s the most mature approach and that it doesn’t require any additional dependency.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="Nhib.Models" assembly="Nhib">

  <class name="Product" table="Products">
    <id name="SKU">
      <generator class="uuid.hex" />
    </id>
    <property name="ProductName"/>
    <property name="BasePrice" />
  </class>

</hibernate-mapping>

Attributes

It is possible to use attributes through Castle to specify the mappings instead. This is very easy, involves minimal repetition and a less magic strings than XML. On the other hand, doing the mapping on the objects themselves means less separation of concerns as the objects and the mappings are in the same place. It also means buying into the whole active record approach and giving up POCOs.

[ActiveRecord("Products")]
public class Product : ActiveRecordBase {
    [PrimaryKey(PrimaryKeyType.UuidHex)]
    public string SKU { get; set; }
    [Property]
    public string ProductName { get; set; }
    [Property]
    public double Price { get; set; }
}

Update: Gauthier Segay pointed out that it's not exactly true that you have buy into the whole Castle active record approach. More info here:

http://www.castleproject.org/activerecord/documentation/trunk/advanced/mediator.html

Fluent

Finally, the favorite approach du jour is Fluent NHibernate. That approach still keeps mappings nicely separated but has several other advantages.

First, it’s code, which opens up a lot of dynamic scenarios.

Second, it’s strongly-typed. That means that refactoring will work, that you will get compile-time checks and IntelliSense.

Third, it uses Lambdas and a fluent interface, and those are so cute… On the other hand, if you find those alien, it might not be such a win. On the other other hand, it’s a good occasion to learn something new and cool.

public class ProductMap : ClassMap<Product> {
    public ProductMap() {
        Id(p => p.SKU).GeneratedBy.UuidHex("B");
        Map(p => p.ProductName);
        Map(p => p.Price);
    }
}

In our application, we have chosen XML mappings for now to minimize the number of dependencies and because choosing the most mature approach also means learning is more incremental. We might revise that decision if and when the disadvantages become too much of a problem and as we learn more.

4. HQL, criteria, lambdas, ActiveRecord or Linq?

HQL

HQL is the Hibernate Query Language and is the default way of querying in NHibernate. It works and is mature but it is a text format, which means no static verification, refactoring or IntelliSense.

“select p from Product as p where p.ProductName like 'boot%'”

There are a few alternatives to HQL though. Let’s first talk about native SQL. It is possible to send native SQL from NHibernate but you should really only do that if you need to use a specific native feature of your database. While the possibility exists, it is not a relevant choice here.

CreateCriteria

The NHibernate session object has a CreateCriteria method that exposes a fluent querying interface. You can use it with expressions, but this is deprecated, or you can use it with restrictions, which are very similar but more current.

session.CreateCriteria<Product>()
    .Add(Restrictions.Like("ProductName", "boot%");

This API tends to be relatively verbose and is not completely strongly typed but it may be more appropriate than HQL for simple queries.

Lambdas

The nhlambdaextensions project provides a strongly-typed alternative to the restrictions described above through the use of Lambda expressions. This is a strong choice that comes close to Linq but it does require yet another dependency.

session.CreateCriteria<Product>()
    .Add<Product>(p =>
        p.ProductName.StartsWith("boot",
        StringComparison.CurrentCultureIgnoreCase));

ActiveRecord

If you chose to use Castle ActiveRecord, you can still query using HQL, but you also get basic repository-like operations directly on your data classes out of the box.

FindAll(typeof(Product), Restrictions.Like("ProductName", "boot%"));

Linq

Finally, you can use an implementation of Linq to query NHibernate. This is Linq, for NHibernate. In other words, pure, distilled WIN: strong typing, compile-time checks, etc. The problem is that it is still a work in progress (and an additional dependency).

from product in session.Linq<Product>()
    where product.startsWith("boot",
        StringComparison.CurrentCultureIgnoreCase)
    select product;

Linq to NHibernate can be obtained from NHibernate Contrib or as part of Fluent NHibernate.

For the moment, our application uses CreateCriteria with restrictions for simple queries, and HQL in places. Again, the motivation here is to minimize the dependencies.

Conclusion

I hope this post will be helpful for NHibernate beginners such as myself to make the right first choices.

Next time, we’ll really start digging into our transition from our old custom data layer.