Tales from the Evil Empire : HTML

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

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

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

Tell me what smells in WebForms as a view engine

Bertrand Le Roy — Mon, 13 Jul 2009 17:58:00 GMT

Don’t read too much into this, but I’d love to read your feedback on this. I’m compiling a list of stuff that smells in WebForms when used as a view engine in MVC.

Along the lines of:

Noisy page directives that are useless for MVC
runat=server
Page lifecycle

For once, you can let the inside troll take over :)

Mandelbrot set in a twitcode

Bertrand Le Roy — Sat, 11 Jul 2009 00:50:00 GMT

Kinik just published a pretty amazing #twitcode version of a Mandelbrot set visualization in JavaScript that Jacob Seidelin wrote.

Here’s the code:

for(k=84;k-=1/32;document.write(k%3?i%8:'<br/>'))
for(x=y=0,i=99;--i/y;x=t)t=x*x-y*y+1-k%3,y=1-k/42+y*x*2

And here’s what it renders:

http://twitter.com/KiniK/statuses/2575582146

A (less) simple include for ASP.NET

Bertrand Le Roy — Fri, 10 Jul 2009 22:57:00 GMT

In yesterday’s post, I published the code for a simple include method for ASP.NET that I’ve been using in a couple of places, only to realize that it was fine for what I was doing but probably not very useful beyond that.

So I spent some time today broadening its scope. It now supports nested includes (I modified the original post to reflect that change) and also setting properties on the control.

You can still do plain includes:

<% this.Include("contents.ascx"); %>

But now you can also set properties on the included user control using an anonymous object:

<% this.Include("contents.ascx", new {number=2, what="A"}); %>

The code for the helper considerably grew along the way but it’s still reasonable:

using System;
using System.Linq;
using System.Reflection;
using System.Web.UI;

public static class IncludeHelper {
    public static void Include(this TemplateControl host,
                               string virtualPath) {
        Include(host, virtualPath, null);
    }

    public static void Include(this TemplateControl host,
                               string virtualPath,
                               object properties) {
        var resolvedPath = host.ResolveUrl(virtualPath);
        var include = host.LoadControl(resolvedPath);
        if (properties != null) {
            var includeType = include.GetType();
            foreach (var fieldInfo in
                         properties.GetType().GetProperties()) {
                var targetInfo = includeType.GetMember(
                    fieldInfo.Name,
                    MemberTypes.Field |
                    MemberTypes.Property,
                    BindingFlags.IgnoreCase |
                    BindingFlags.Instance |
                    BindingFlags.Public)
                    .FirstOrDefault();
                var targetPropertyInfo = targetInfo as PropertyInfo;
                if (targetPropertyInfo != null) {
                    targetPropertyInfo.SetValue(
                        include,
                        fieldInfo.GetValue(properties, null),
                        null);
                }
                else {
                    var targetFieldInfo = targetInfo as FieldInfo;
                    if (targetFieldInfo != null) {
                        targetFieldInfo.SetValue(
                            include,
                            fieldInfo.GetValue(properties, null));
                    }
                    else {
                        throw new ArgumentException(
                            "There is no property of field with " +
                            "that name on the target control.",
                            fieldInfo.Name);
                    }
                }
            }
        }
        using (var writer =
                   new HtmlTextWriter(host.Page.Response.Output)) {
            include.RenderControl(writer);
        }
    }
}

I hope this helps. Again, if you are OK with the regular syntax to include a user controls, you probably shouldn’t use this and stick to what you know. I built this because I’m not entirely satisfied with that syntax and because I have a clear use case where it makes more sense. Make your own opinion and follow it :)

Note: The control is still not going into the control tree, which breaks lots of stuff. I don't really care that much about it but it may be important to you so I thought I'd point it out.

A simple include for ASP.NET

Bertrand Le Roy — Thu, 09 Jul 2009 23:30:55 GMT

In yesterday’s post, I alluded to a simple include extension method that I like to use when I don’t care about designer support. In a comment, Andrew asked if I could share the code for it, so here it is.

I never liked the regular way of including user controls in WebForms and how they require a registration and a declaration, both of which are more verbose than they need to be. A plain #include would work but is a little outdated (and if I’m not mistaken it’s not even available by default in IIS7).

My Include method is quite similar to MVC’s RenderPartial except that it doesn’t deal with view data. It’s a plain and simple include. Just give it the relative path to a user control:

<% this.Include("Header.ascx"); %>

Here’s the code for that extension method:

using System.Web;
using System.Web.UI;

public static class IncludeHelper {
    public static void Include(this TemplateControl host,
                               string virtualPath) {
        var resolvedPath = host.ResolveUrl(virtualPath);
        var include = host.LoadControl(resolvedPath);
        using (var writer =
                   new HtmlTextWriter(host.Page.Response.Output)) {
            include.RenderControl(writer);
        }
    }
}

It just resolves the path, loads the control and renders it in place.

To use that method, just drop the code as a cs file into App_code if you’re using a web site, or just add it to your project otherwise.

I played with the idea of enabling an anonymous object parameter to set properties on the user control, but I guess if you’re going to do that, the benefits of the helper get dimmer and going with the regular WebForms user control registration and tags is probably just easier (you’ll get IntelliSense on the properties for example).

Disclaimer/update: No, this does not run the control through the page lifecycle (although it could by adding it to the page’s control tree and removing it after rendering it). No, if you use master pages you probably don’t need it. No, you can’t set properties.

This is just the simplest include I could build, and it does only that: including contents. If it seems useless to you, it probably is. I published it mainly because I was asked to. :)

Update: I wrote a more complex version that can set properties on the included controls:
http://weblogs.asp.net/bleroy/archive/2009/07/10/a-less-simple-include-for-asp-net.aspx

Are Master Pages too complex?

Bertrand Le Roy — Wed, 08 Jul 2009 23:38:00 GMT

Master Pages are a wonderful concept that as developers we highly value. It’s the sort of pattern that just looks like the right thing to do (to our twisted, concept hungry developer minds) and that even makes you wonder why we haven’t done it that way since the beginning of time (1990). For the record, master pages were invented by David Ebbo, who is behind a lot of the smartest things in ASP.NET.

Just in case you have no idea, what are Master Pages? Before master pages, sharing layout between pages was done using includes (or user controls). For example, your typical hello world page might have looked like this:

<%@ Page Language="C#" %>
<%@ Register TagPrefix="include" TagName="header"
             Src="~/HelloHeader.ascx" %>
<%@ Register TagPrefix="include" TagName="footer"
             Src="~/HelloFooter.ascx" %>
<!DOCTYPE html>
<html>
<head>
    <title>Hello world with includes</title>
</head>
<body>
    <div>
    <include:header runat="server" />
    Hello world!
    <include:footer runat="server" />
    </div>
</body>
</html>

Notice that the page does contain markup that is not specific to the page (boilerplate markup mainly that you could put into includes as well, but only at the cost of breaking beginnings and ends of semantic blocks into separate includes).

As a side note, I’ve always thought the user control syntax above was overly verbose when all you want is a plain include. It has the one advantage of enabling the Visual Studio designer but having a separate registration and declaration seems overkill. The #include directive still exists but I personally prefer to use a simple helper extension method to Page that brings the code down to this (MVC gives you Html.RenderPartial, which is roughly equivalent):

<%@ Page Language="C#" %>
<!DOCTYPE html>
<html>
<head>
    <title>Hello world with includes</title>
    <meta name="keywords" content="hello world" />
</head>
<body>
    <div>
    <% this.Include("HelloHeader.ascx"); %>
    Hello world!
    <% this.Include("HelloFooter.ascx"); %>
    </div>
</body>
</html>

With master pages, you can get rid of all common markup and really limit what you put into the page to just what varies from page to page. for example, the above hello world page might be written like this:

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master"
    Title="Hello world!" %>

<asp:Content ContentPlaceHolderID="head" Runat="Server">
    <meta name="keywords" content="hello world" />
</asp:Content>
<asp:Content ContentPlaceHolderID="content" Runat="Server">
    Hello from the content page!
</asp:Content>

That is clean, but pretty puzzling the first time you see it. To understand where the markup comes from, you need to track that @Page directive and understand that you need to look into the corresponding master page file:

<%@ Master Language="C#" %>
<!DOCTYPE html>
<html>
<head runat="server">
    <title>Master page</title>
    <asp:ContentPlaceHolder id="head" runat="server">
    </asp:ContentPlaceHolder>
</head>
<body>
    <h1>Hello from a master page</h1>
    <div>
        <asp:ContentPlaceHolder id="content" runat="server">
        </asp:ContentPlaceHolder>
    </div>
    Footer says hi.
</body>
</html>

You need to understand that those content place holder ids correspond to other controls that are in the master page and that the framework will make the match.

Master pages also come with the price of mangled ids, but that’s an implementation detail (one could imagine an implementation that wouldn’t suffer from that problem). The price we pay for master pages also comes in the form of a weird control tree: master pages are really implemented as user controls that get included by the page, a concept that is the inverse of the model they seem to promote; in other words, the implementation is the reverse of the concept, in a way. There are also complications about putting contents in the head section (head must be runat=server, script tags are tricky, setting the title, etc.).

So are master pages worth the price? It depends on who your audience is and on how your pages are built.

By audience, I mean the person who is going to write the views. If it’s just you and you are a developer, they might actually be a pretty solid choice. But if external designers are going to build the views, maybe you need to pause and try not to think as a developer for a moment.

The main problem with the include approach (and the reason why master pages were invented) is that the outer markup for the page needs to be on all pages. So if you decide to change that markup, you need to do so on all pages.

But in more and more applications, in particular CMS, this problem becomes moot. If your application decouples the content from the view code, and if the layout or view to use for a given content can be determined at runtime by a themeing engine, you might end-up with templates that look like this:

<%@ Page Language="C#" %>
<!DOCTYPE html>
<html>
<head>
    <title><%= Title %></title>
</head>
<body>
    <div>
    <% this.RenderZone("Header"); %>
    <% this.RenderZone("Contents"); %>
    <% this.RenderZone("Footer"); %>
    </div>
</body>
</html>

This is actually no different in concept from master pages (there are place holders in generic markup and no specific contents) but the contents do not come from a content page. Instead, they are dynamically inserted by the application.

The template file then becomes no more than layout. It is easy to understand and easier to assign a different layout to any given contents.

So in general there is no perfect answer on whether you should use master pages or not, but if you are able, in your application, to decouple page layout from contents, there is an opportunity to have clean and easy to understand markup that also maximizes re-use.

Why is ASP.NET encoding &’s in script URLs? A tale of looking at entirely the wrong place for a cause to a non-existing bug.

Bertrand Le Roy — Sat, 06 Jun 2009 00:27:15 GMT

Several people have reported seeing errors in their logs that seem to be due to requests such as this:

/ScriptResource.axd?d=
[lots of junk]&
t=ffffffffee24147c

The important part here is the HTML-encoded “&” sequence, which stands for “&” of course. If this exact URL is sent to the server, the server won’t know what to do with the escape sequence (URLs are not supposed to be HTML-encoded on the wire) so the parameters won’t get separated as expected, potentially resulting in a server error. This bug in the toolkit is an example of that: http://ajaxcontroltoolkit.codeplex.com/WorkItem/View.aspx?WorkItemId=13134

Of course, when people see 500 errors popping up in their server logs, they immediately assume the application is failing for some users. Or that some idiot at Microsoft did something incredibly stupid (that’s what we idiots at Microsoft do after all).

Case in point, a quick peek into the source code of the application’s pages immediately reveals that the script tags generated by ScriptManager do indeed generate these URLs:

So that’s where it came from! See? When I copy this URL into the browser’s URL bar, I do get the same error!

Then ensue various more or less rational reactions such as:

Correlate the user agent to the faulty requests (which correlates more or less with normal browser usage, i.e. lots of IE and then lots of Firefox, when there is a large enough sample).
Blame IE6 (lots of these requests come from IE6, hence it must be responsible: IE6 sucks).
“Fix” ScriptManager and remove the HTML encoding.

Well, by copying the URL from the source view into the URL bar, you did indeed reproduce the problem. A little too well. Better than you realize.

This is why. All of the errors in your server logs come from people doing precisely what you just did: copy the URL from the source view into the browser’s URL bar. They do it for various reasons: look at the source code for the scripts, understand what these weird URLs are, who knows?

But the point is, you will never be able to reproduce these errors during normal use of the application. There is nothing to fix here. The value that gets sent to the server never has the “&” sequence. You can verify it in IE6, you can verify it in any browser on any OS, it will just work.

When putting a URL in an HTML attribute, you should *always* HTML-encode it. It’s the standard, and for good reason (it enables the browser to tell between “&”, “&” and “&amp;”, it enables quotes to be embedded into attributes, etc.).

A consequence of that is that if you’re going to copy the value of one of these attributes from the source view, you should do what the browser does when parsing the HTML: decode the value first (in other words, replace “&” with “&”).

So yes, people do fail to do that and copy the URL without decoding. Well, they are not supposed to do that, nor do they need to do it. The error is normal, it results from a bad URL having been entered manually. Nobody would be surprised to get an error when querying foo.aspx?somenumber=thisisnotanumber for example. Same thing here. Pretty much.

Of course, this is not entirely trivial to figure out and I did pull my remaining hair a bit trying to understand what was going on, and you tend to trust people when they tell you there is a problem, especially when the description seems to make sense. There is some sort of confirmation bias going on there. But the more I looked at the different pieces of evidence, the more this explanation looked like the most likely, by far.

But of course, I may be missing something…

New release of the Ajax Control Toolkit

Bertrand Le Roy — Thu, 14 May 2009 05:19:00 GMT

A new version of the AJAX Control Toolkit is now available for download from the CodePlex website. It contains three new controls:

HTMLEditor - allows you to easily create and edit HTML content. You can edit in WYSIWYG mode or in HTML source mode. The control exists as a server-side extender but can also be instantiated purely on the client-side with a single line of code. Many thanks to Obout for building this.

ComboBox - provides a DropDownList of items, combined with TextBox. Different modes determine the interplay between the text entry and the list of items. this control behaves very much like a Windows combo. Many thanks to Dan Ludwig for building this.

ColorPicker - can be attached to any ASP.NET TextBox control to provide client-side color-picking functionality from a popup. Many thanks to Alexander Turlov for building this.

The ASP.NET website has been updated with new videos and tutorials for these controls.

This new release also includes fixes for over 20 of the most voted bugs in existing AJAX Control Toolkit controls and now features minimized release versions of the script files.

The release can be downloaded as a server dll or as a set of files for use with pure client-side applications.

http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27326

Glimmer: visually build jQuery animations and stuff

Bertrand Le Roy — Tue, 28 Apr 2009 18:35:29 GMT

If you’re still intimidated by jQuery or DOM manipulation in general, if you need to quickly build web animations, if you’re more a designer guy, if you think tooling makes sense, or a combination of the above, you should probably check out Glimmer.

In a nutshell, Glimmer is a visual tool that builds HTML animations, menus, tooltips on jQuery. It builds all the code you need (HTML, CSS and JavaScript with jQuery) at the click of a button.

Check it out!
http://visitmix.com/Articles/Glimmer-a-jQuery-Interactive-Design-Tool

CSS isolation: there has got to be a better way

Bertrand Le Roy — Tue, 14 Apr 2009 07:26:04 GMT

CSS can be a tricky thing. I’m trying to do something that I think should be pretty simple. Let’s say a page contains a section (e.g. an admin panel) that must be styled independently from the rest of the page, but consistently and predictably. The DOM and CSS for the main part of the page is undetermined (e.g. because it’s part of a user-defined theme). Of course, you could use iframes, which are about the only isolation mechanism in HTML but we can’t do this here because iframes are quite rigid in shape (they are rectangles), they make scripting the DOM more difficult and they pretty much require an additional round-trip to the server to serve their contents.

The real problem to solve here is that if the main CSS for the page defines very general styles that for example target all elements with a given tag name, and those styles are going to bleed into our specialized region unless we find a way to block that CSS from cascading down. Ideally, you’d have an attribute on the tag, something like inheritcss=”false”, but no such thing exists.

So the only way I’ve found to solve this problem is to write a stylesheet that explicitly resets the defaults for all properties and all elements. Here is an excerpt from the CssIsolation.css file:

.isolate *
{
    background: white none repeat scroll 0% 0%;
    border: 0px none black;
    border-collapse: separate;
    border-spacing: 0px;
[...]
    z-index: auto;
}
.isolate p 
{
    display:block;
    margin-top: 16px;
    margin-bottom: 16px;
}
.isolate strong, .isolate b 
{
    font-weight: bold;
}
.isolate h1
{
    display: block;
    font-size: xx-large;
    font-weight: bold;
    margin-top: 21px;
    margin-bottom: 21px;
}

This is lame for a number of reasons:

Defaults might vary from browser to browser (this is particularly true of fonts and sizes).
Some styles can’t be reset to defaults, such as default button styles (at least, not without using browser-specific styles that aren’t consistently available):
An exhaustive list of tags and style properties is sure to be wrong now or in the future (I did CSS 2, so it’s already outdated by CSS3).

Still, imperfect as it is, this is a solution that works reasonably well and can be improved as problems are found. The equivalent of that inheritcss=”false” attribute, using my isolation stylesheet, is to set class=”isolate” on the parent element of the section of the page you want to isolate. None of the styles defined for the rest of the page (which is defined just as usual, with no difference whatsoever) should bleed then.

Here a snapshot of my test page, where you can see, side-by-side, unstyled HTML and HTML with reset styles:

Differences exist but are quite subtle.

The HTML for an isolated section is defined like this:

<div class="isolate" id="isolated1">
    Isolated 1...
</div>

If for example the main style sheet defines the style of lists like follows, this style won’t bleed into any element that has the isolate class (on the right on the next screenshot), just because we set the “isolate” class on the parent element.

ul li 
{
    list-style-type: square;
}
ol li 
{
    list-style-type: upper-roman;
}

You can then style each of these sections independently by just qualifying each of the style selectors with the ID of the parent element. In other words, just paste “#isolated1” in front of each selector of the local stylesheet, if the id of the parent element is “isolated1”:

#isolated1 p
{
    color: Green;
    border: solid 1px black;
}

This style will override the isolation CSS because it is qualified by id, which always wins over styles that are only qualified by class:

I really wish one of you will tell me how stupid I am for not knowing about feature/hack X that is way simpler and gets you to the same place… There has got to be a better way.

The code for the isolation stylesheet, as well as the test pages, can be found here:
http://weblogs.asp.net/blogs/bleroy/Samples/CssIsolation.zip