Tales from the Evil Empire : jQuery

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)

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.

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

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. :)

Survey: Ajax usage among .NET developers

Bertrand Le Roy — Fri, 22 May 2009 19:13:20 GMT

If you haven’t already and you are a .NET developer, please take a couple minutes and answer this survey, whether you use Ajax or not. There are a number of Ajax surveys around, but Simone’s is the only one that focuses on .NET developers.

The survey:
http://www.zoomerang.com/Survey/?p=WEB22973CYKW2H

Simone’s post:
http://codeclimber.net.nz/archive/2009/05/21/ajax-usage-among-.net-developers-in-2009.aspx

Creating jQuery plug-ins from MicrosoftAjax components

Bertrand Le Roy — Tue, 05 May 2009 05:23:00 GMT

We had an interesting discussion recently on the ASP Insiders mailing list and ended up talking about what cool stuff we could build on top of jQuery. Many interesting things were mentioned and it was a very useful discussion but one suggestion in particular struck my curiosity as it was something I had investigated before and that could be improved on with very little code.

I had already written a little plugin to enable instantiation of Microsoft Ajax components on the results of a jQuery selector:

jQuery.fn.create = function(type, properties) {
    return this.each(function() {
        Sys.Component.create(type, properties, {}, {}, this);
    });
};

I have another version that is a little more elaborate and takes a bag of properties and events instead of just properties (get it from the attached sample) but you get the idea. This makes it fairly easy to instantiate components based on a selector:

$(":text.nomorethanfive")
    .create(Bleroy.Sample.CharCount, { maxLength: 5 });

But if this were a native jQuery plugin instead of a Microsoft Ajax component, as Rick Strahl suggested, chances are you’d do something like this instead:

$(":text.nomorethanfive").charCount({ maxLength: 5 });

We can actually get that exact result fairly easily by writing a plugin that is specific to this component, but we can’t expect every Microsoft Ajax component author to also write a jQuery plugin, can we? We can do better than that. Here is a second small piece of code that is still generic but is in the business of creating jQuery plugins:

Sys.Component.exposeTojQuery = function(type, pluginName) {
    return jQuery.fn[pluginName] = function(properties) {
        return this.each(function() {
            Sys.Component.create(type, properties, {}, {}, this);
        });
    }
}

Like above, the version in the sample is better than that in that it supports events in addition to properties but again you get the idea. Thanks to this function, we can create a jQuery plugin for any existing Microsoft Ajax component with a single line of code:

Sys.Component.exposeTojQuery(Bleroy.Sample.CharCount, "charCount");

After this call, we can write exactly the code we wrote before, but without having had to write a specific plugin. We can then use charCount like a native jQuery plugin:

$(":text.nomorethanfive").charCount({ maxLength: 5 });

This is really easy to use, and I quite like it. We could for example add the following line of code to the new MicrosoftAjaxTemplates.js:

if (jQuery)
    Sys.Component.exposeTojQuery(Sys.UI.DataView, "dataView");

This would enable us to instantiate DataView controls as simply as this:

<ul class="dv">
    <li>{{ $dataItem }}</li>
</ul>
<script type="text/javascript">
    $(".dv").dataView({ data: ["foo", "bar", "baz"] });
</script>

Get the code from here (you need to include jquery-1.3.2.js to the script folder):
http://weblogs.asp.net/blogs/bleroy/Samples/jQueryCreate.zip

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

VsDoc for jQuery 1.3.1 now available

Bertrand Le Roy — Fri, 06 Feb 2009 21:53:12 GMT

John Resig tells us he just uploaded the VsDoc file for jQuery 1.3.1 to jquery.com. This enables IntelliSense for the latest available jQuery.

Download the file from the jQuery downloads page:
http://docs.jquery.com/Downloading_jQuery#Download_jQuery

More info on what this is:
http://weblogs.asp.net/bleroy/archive/2008/11/07/visual-studio-patched-for-better-jquery-intellisense.aspx

JavaScript Behavior Sheets: an experiment

Bertrand Le Roy — Sun, 18 Jan 2009 08:53:00 GMT

Here’s a little experiment. I’m really after feedback on this one as I’m trying to decide whether this is a good idea. It’s also entirely possible somebody else did this before. That would be good feedback too. Anyway, here it is.

Despite its shortcomings, CSS has a number of features that make it very compelling. First, it decouples styling from markup. Second, its selector syntax is simple, yet reasonably powerful.

So we have semantic markup on the one hand, and styles on the other hand, and the only coupling between the two is the selectors in the stylesheet.

In Ajax applications, there is a third kind of entity in the mix, JavaScript behavior. There are of course ways to decouple the script behavior from the markup, which are usually referred to as unobtrusive JavaScript. jQuery also introduced back in 2005 a way to associate script behavior with the DOM using the same selector syntax that CSS uses.

But way before jQuery, Internet Explorer 5 enabled developers to specify behavior in stylesheets. You could do this for example:

.hilite { behavior:url(hilite.htc) }

This was a pretty neat idea at the time despite the challenges that came with it (in terms of performance for example), but it was never adopted by the other browsers despite having been submitted to W3C. The feature was never very widely used. There *is* a Firefox implementation of HTC behaviors but it doesn’t seem to have helped much in terms of adoption of this feature.

And one thing that bothers me with that idea is that while it does decouple behavior from markup, it also couples behavior to styling at least in location. Putting styles and behavior in the same file, in retrospect, looks like one step forward, and one step backwards. Sure, you could always use two separate files but the system did nothing to encourage you to do that.

What I’m trying to do here is separate styling, markup *and* behavior, leverage selectors in a nice, declarative way à la CSS and still work on all modern browsers. The coupling mechanism between style and markup (CSS selectors), is reasonably good and is already known by all Web developers so it remains a natural choice as jQuery showed clearly. Let’s see if one can express behavior in a way that is close to the already well-known CSS pattern.

In this implementation, it is possible to add event handlers and Microsoft Ajax behaviors from a “JavaScript Behavior Sheet” which can be embedded in the page or be loaded from a separate file using a modified script tag:

<script type="text/behavior" src="BehaviorSheet.jss"></script>

The contents of the tag or file is in the simple JSON notation for an object, omitting the curly braces:

"input[type=text].nomorethanfive": {
    click: function(e) {
        alert("You clicked input #" + e.target.id);
    },
    "Bleroy.Sample.CharCount": {
        maxLength: 5,
        overflow: function(source, args) {
            $(source.get_element()).jFade({
                 property: 'background',
                 start: 'FFFF00',
                 end: 'FFFFFF',
                 steps: 25,
                 duration: 30
            });
        }
    }
}

The top-level entities that can be found in there are the CSS selectors (note the quotes that are a departure from CSS notation but made the prototyping so much simpler). Each selector is associated with an object that contains event and object definitions.

The event definitions consist in the event name and the handler to associate with it:

click: function(e) {
    alert("You clicked input #" + e.target.id);
},

The implementation of this feature uses the new live events from jQuery. The result of that definition is that clicking on any input of type text with the class “nomorethanfive” will display an alert giving the id of the input that was clicked. That is a pretty efficient way to hook up events to multiple elements…

The behavior instantiation specifies the class to instantiate, “Bleroy.Sample.CharCount” and lists the properties, fields and events to set (here, the maxLength property is set to 5 and the overflow event is hooked to a function that flashes the element’s background yellow):

"Bleroy.Sample.CharCount": {
    maxLength: 5,
    overflow: function(source, args) {
        $(source.get_element()).jFade({
             property: 'background',
             start: 'FFFF00',
             end: 'FFFFFF',
             steps: 25,
             duration: 30
        });
    }
}

Here’s what the page looks like:

<\/embed><\/div>";" galleryimg="no">

I should point out that while the events will handle DOM mutations (such as adding new elements that match the selector) just fine, component instantiation won’t in this implementation, which is a limitation that is quite hard to work around in current browsers.

So here it is. All the code for this is available from the link below (contains jFade, code licensed under MIT: jQuery, and code under MS-PL: Microsoft Ajax and my own code), with some tests written with RST.js. So what do you think?

http://weblogs.asp.net/blogs/bleroy/Samples/BehaviorSheet.zip

UPDATE: interestingly, the intent behind Reglib by Greg Reimer is pretty close to this and he even uses the words “Behavior Sheets”.

UPDATE: Stuart Langridge did something very close to declarative events as they are done here back in November 2003. Thanks to Clayton for pointing that out. One should note that the limitations of the time are no longer preventing the technique from reaching its full potential.

Wally’s introduction to 3.5 SP1

Bertrand Le Roy — Mon, 29 Dec 2008 19:36:18 GMT

Wally McClure, MVP extraordinaire and ASP Insider, just published a short book about the new features in ASP.NET 3.5 SP1. It is a short and to the point read that should get you started in no time. I wouldn’t have shown web service access as the main advantage of jQuery myself (the selector and animation support adds more value for ASP.NET Ajax developers) but that’s a minor thing, and there are plenty of other resources to learn about jQuery. Topics in Wally’s book include:

Ajax History
Script Combining (including ScriptReferenceProfiler)
jQuery
Routing
Entity Framework
Dynamic Data
ADO.NET Data Services

http://www.wrox.com/WileyCDA/WroxTitle/New-Features-in-ASP-NET-3-5-Service-Pack-1.productCd-0470457341.html

Microsoft Ajax Client Templates and declarative jQuery

Bertrand Le Roy — Wed, 10 Dec 2008 07:33:57 GMT

Apparently Brian likes our declarative syntax. And jQuery. And he did something quite fun with them, something we had clearly not anticipated: using Microsoft Ajax’s new declarative syntax to call jQuery plug-ins instead of Microsoft Ajax behaviors as was the original intent.

<input type="text" maxlength="20" size="40" 
   sys:key=”self” 
   sys:attach=”wajbar”  
   wajbar:submit=”{{ $(self).next(’input:submit’) }}” />

The way he made that possible is by adding a registration step to make the plug-in accessible through sys:attach. This registration API actually creates a wrapper behavior for the plug-in that gets Microsoft Ajax to believe the plug-in is a regular behavior. The actual plug-in gets called during initialization of the wrapper behavior, using the behavior itself as the options for the plug-in. This works because the declarative engine in Microsoft Ajax will just set plain expando fields for namespaced attributes such as “wajbar:submit” that don’t correspond to a property. Clever.

This is quite interesting and opens up a number of possibilities, such as enabling our declarative syntax to instantiate components from any framework (without the hack of wrapping them in a Microsoft Ajax behavior) if we open up the right extensibility points. This is definitely something I’ll investigate.

What do you think?

Brian’s post:
http://weblogs.manas.com.ar/bcardiff/2008/12/declarative-jquery-with-microsoft-ajax/

Visual Studio patched for better jQuery IntelliSense

Bertrand Le Roy — Sat, 08 Nov 2008 05:34:57 GMT

Jeff King just announced the release of a patch for Visual Studio 2008 that enables the IDE to find the –vsdoc.js file without requiring the developer to reference it.

To give some context, a documentation file (basically the same file as the runtime script but with XML documentation annotations) can be provided to help Visual Studio provide IntelliSense. Until now, you had to reference that extra file explicitly, usually within a server-side <% if %> block so that the file never gets included at runtime.

Now that this patch shipped, this is no longer necessary and Visual Studio is going to be able to find the –vsdoc.js file for any script file that is referenced, whether that is through a ScriptManager ScriptReference:

or using a plain script tag:

or even a reference XML tag:

That makes jQuery IntelliSense as easy as dropping the –vsdoc.js file in the web site next to the main jQuery file (other libraries can easily take advantage of that too of course):

Pretty sweet.

The patch can be found here:
http://code.msdn.microsoft.com/KB958502/Release/ProjectReleases.aspx?ReleaseId=1736

The IntelliSense file for jQuery can be downloaded from the jQuery servers (look for the “documentation: Visual Studio” file):
http://docs.jquery.com/Downloading_jQuery#Download_jQuery

Jeff’s post:
http://blogs.msdn.com/webdevtools/archive/2008/11/07/hotfix-to-enable-vsdoc-js-intellisense-doc-files-is-now-available.aspx

Jeff’s other post on using the documentation file:
http://blogs.msdn.com/webdevtools/archive/2008/10/28/rich-intellisense-for-jquery.aspx

The format for XML doc comments:
http://weblogs.asp.net/bleroy/archive/2007/04/23/the-format-for-javascript-doc-comments.aspx

PDC 2008 ASP.NET AJAX Futures talk available online

Bertrand Le Roy — Mon, 03 Nov 2008 18:10:00 GMT

The full 83 minutes of my PDC talk are available on the Channel 9 web site. You can watch the session online (using Silverlight) or download the video in a number of formats. Slides and source code for the demo are also available.

Watch online:
http://channel9.msdn.com/pdc2008/PC32/

Download MP4 / iPod, Zune, WMV or WMV-HQ.

Slides:
http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/PC32.pptx

Demo code (contains MIT and MS-PL licensed JavaScript files):
http://mschnlnine.vo.llnwd.net/d1/pdc08/ZIP/PC32.ZIP

Another talk you may be interested in is Stephen Walther's. Stephen did an amazing job explaining how jQuery and ASP.NET Ajax work and fit together. The talk is very accessible even if you have no prior knowledge of jQuery: http://channel9.msdn.com/pdc2008/PC31/.

ASP.NET 4.0 Roadmap talk available online

Bertrand Le Roy — Tue, 28 Oct 2008 22:09:26 GMT

Scott Hunter’s talk on the ASP.NET 4.0 roadmap (in which I’m doing a 10 minute demo) is available from Channel9:

http://channel9.msdn.com/pdc2008/PC20/