Search
Categories
Navigation
Twitter Updates

Twitter Updates

    follow me on Twitter
    « Custom Multi-select Control | Main | ASP.NET Web Forms and XHTML »
    Wednesday
    13Feb2008

    JS IntelliSense with Namespaces in VS 2008

    When ASP.NET AJAX came out and my interest in the UpdatePanel had waned, I really dug into the client-side library. I'd never gone very deep into JavaScript until then, so the structure of the library was intriguing and, over time, became a pattern that I began adopting in my own work.

    A corner-stone to this structure is partitioning your JavaScript into namespaces (using Type.registerNamespace), which are split up in a manner similar to .NET itself, and also avoid naming conflicts with third-party components and non-global page functions.

    Of course, with my increased adoption of JavaScript, I was excited to hear of JavaScript IntelliSense support in VS2008. I had assumed that namespace support for IntelliSense would work as expected, since so much of the ASP.NET AJAX library uses it and that I would soon be reveling in all the contextual help provided by my diligent use of JavaScript doc comments. After converting my current project to VS2008, I was confused by the seemingly utter lack of IntelliSense when using namespaces. So, as with most things that confuse me, I searched around on the 'net to see if anybody else had solved this problem. To my chagrin, I found a disturbing post stating that a bug had been submitted to Microsoft for this issue, and that the response was, effectively, that the namespace pattern would not be supported in VS2008.

    Dejected, I continued on with my project, having conceded that my namespaced script wouldn't be quite as easy to work with as I had hoped. It wasn't long, however, that I noticed that the namespaces worked properly when they were defined in a different file from the active document, which is the expected behavior as stated in the Microsoft Feedback report. In fact, this is the same functionality that provides us with IntelliSense for the ASP.NET AJAX client-side framework itself.

    Add all of this together and you can, in fact, get JavaScript IntelliSense for script that uses namespaces (through Type.registerNamespace) by doing a few tricks within your application. Read on for more details.

    Step 1: Add a Namespace definition file

    Since any Type.registerNamespace calls in the active document aren't parsed, we need to add a new file to the project for storing namespace registration calls. This file is also the root JS file that will reference the MircrosoftAjax.js file for client-side library IntelliSense support. For the example, we'll refer to this as SampleApp-Namespaces.js:

    /// <reference name="MicrosoftAjax.js" />
    Type.registerNamespace("Coderoni.JsSampleApp.Utility");

    Step 2: Reference this Namespace definition file

    In order to get proper IntelliSense support in the files where we would normally define namespaces and then use them, we now need to reference this namespace definition file. It's important to point out that nothing else in this your existing JavaScript code has to change. The Type.registerNamespace() call does nothing if the namespace already exists, so you can (and should, more later) leave your standard Type.registerNamespace() calls alongside the object definitions they correspond to. Here's what SampleApp-Core.js might look like:

    /// <reference path="~/Scripts/SampleApp-Namespaces.js" />

    /*
    * Coderoni.JsSampleApp.Utility.RandomGenerator
    /*--------------------------------------------------------------------------*/
    Type.registerNamespace("Coderoni.JsSampleApp.Utility");
    Coderoni.JsSampleApp.Utility._RandomGenerator = function()
    {
    /// <summary>
    /// Provides convenience utility methods for generating random values.
    /// </summary>
    Coderoni.JsSampleApp.Utility._RandomGenerator.initializeBase(this);
    }

    Coderoni.JsSampleApp.Utility._RandomGenerator.prototype =
    {
    generateRandomString: function(length)
    {
    /// <summary>
    /// Generates a random string of the specified length.
    /// </summary>
    /// <param name="length" integer="true" optional="false">
    /// Length of the string to generate.
    /// </param>
    /// <returns type="String">
    /// Randomly generated string of the specified length.
    /// </returns>
    var chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
    var randomString = "";

    for (var i = 0; i < length; i++)
    {
    var randomNum = Math.floor(Math.random() * chars.length);
    randomString += chars.substring(randomNum, randomNum + 1);
    }
    return randomString;
    }
    }
    Coderoni.JsSampleApp.Utility._RandomGenerator.registerClass(
    "Coderoni.JsSampleApp.Utility._RandomGenerator");
    Coderoni.JsSampleApp.Utility.RandomGenerator =
    new Coderoni.JsSampleApp.Utility._RandomGenerator();

    The important parts of this code is the call to registerNamespace() with the same namespace information as that found in SampleApp-Namespaces.js. After making the reference to the namespace file, you should find that your namespaces appear and work as expected in IntelliSense. This is because the parser that analyzes references does realize that registerNamespace() creates objects, and therefore, everything works.

    Step 3: Don't reference the namespace definition

    Of course, we all know that the fewer requests the browser needs to send when loading a page, the better off our users are, so adding a JavaScript file to the application for design-time IntelliSense is not a smart move. Fortunately, the work-around relies on the reference hints you give to Visual Studio in JS comments, so you shouldn't add a script link to the namespace definition file within your application; it's simply not necessary. This is also the reason you leave the duplicate registerNamespace() calls in the SampleApp-Core.js file; these calls are the ones that actually register your namespaces at runtime.

    <asp:ScriptManager runat="server" ID="ScriptManager">
    <Scripts>
    <asp:ScriptReference Path="~/Scripts/SampleApp-Core.js" />
    <asp:ScriptReference Path="~/Scripts/Default-Script.js" />
    </Scripts>
    </asp:ScriptManager>

    Everything also works right if you reference the objects defined in SampleApp-Core.js from a third script file, such as Default-Script.js:

    /// <reference path="~/Scripts/SampleApp-Core.js" />

    function ShowRandomString()
    {
    str = Coderoni.JsSampleApp.Utility.RandomGenerator.generateRandomString(10);
    element = $get("MessageDiv");
    element.innerHTML = str;
    }

    Again, this is because the multiple calls to registerNamespace() do nothing if the namespace already exists.

    Summing Up

    While it's not the prettiest work-around that ever existed, it's relatively painless and allows those of us that have adopted the namespace structure in their JavaScript to enjoy the many benefits of VS-based IntelliSense. Hopefully a future release or update for VS will allow the parsers to work without this extra bit of effort, but until then, at least it's possible with just a bit of extra code and no real impact on your application. Now all those JavaScript doc comments weren't a complete waste of time after all.

     

    PrintView Printer Friendly Version

    EmailEmail Article to Friend

    Reader Comments (3)

    I just finished writing 3000 lines of JavaScript and only just now found your workaround. GAHH!

    Thanks for this. Now if I could only find a way to get IntelliSense to recognize inheritance via registerClass().

    August 15, 2008 | Unregistered CommenterJeff Stewart

    Thanks for the article on the Intellisense namespace issues.

    I'll be updating my JavaScript to be more OO like and this will really help with productivity.

    January 8, 2009 | Unregistered CommenterMark

    Thanks for the information on the Intellisense workaround. It took me a bit of searching to find this. The best part is that it's not at all complicated to accomplish. One minor change I had to make to your instructions was as follows. Rather than declaring:

    /// <reference path="~/somepath/myjsfile.js" />

    I declared:

    /// <reference name="~/somepath/myjsfile.js" />

    I'm using VWD 2008 Express Edition with AJAX 1.0 for use with a .NET 2.0 solution. .NET 3.5 (and the corresponding AJAX implementation) seems to work only using the former reference declaration whereas setups similar to my own appear to only work with the latter reference declaration. Just thought it was worth mentioning for anyone else that stumbles upon this.

    March 9, 2009 | Unregistered CommenterMike

    PostPost a New Comment

    Enter your information below to add a new comment.

    My response is on my own website »
    Author Email (optional):
    Author URL (optional):
    Post:
     
    Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>