Here’s what this now looks like when accessing jQuery elements in the page:
Note that you get Intellisense all the way down the chain – ie. not just on the first element. Notice also that plug-ins (draggable in this case) shows up as well in the list of ‘attached’ jQuery wrapped set functions.
Just as useful is Intellisense on individual members:
with all parameters and some fairly detailed information provided on methods, and their parameters although there are a few functions that have missing parameters (all the before/after/append/appendto/prepend/prependTo etc.).
Notice also that the jQuery parameter stored into an instance variable is also recognized as a jQuery instance and so Intellisense works on the win variable as well as an explicit $() function.
What you need to use jQuery Intellisense effectively
Here are all the things that you need to get the best jQuery support in the VS 2008 editor:
- Visual Studio 2008 SP1
- jQuery Intellisense document file (jQuery-1.2.6-vsdoc.js)
This .js file is an annotated version of the base jQuery.js that includes detailed Visual Studio style Intellisense information about each of jQuery’s functions and utilities. None of the code is changed – only comments have been added. This file isn’t meant to replace your original jQuery.js file, but rather to serve as a more complete Intellisense file during development. Not meant for production.
- VS 2008 SP1 Hotfix for –vsdoc.js Intellisense (KB958502)
This hotfix enables any file with –vsdoc.js extension to act as an Intellisense background file for any referenced .js file. So if you have a script src referencing jquery.js all you have to do is have the jquery-vsdoc.js in the same folder as jquery.js and Visual Studio will automatically find and use the –vsdoc file for Intellisense. This works for jQuery with the above mentioned files as well as your own files.
This is all very nice and it works great.
I’ve talked about Intellisense some time back and I basically did something similar to my copy of jquery.js by providing a few key functions with Intellisense markup. So then when referencing the .js file I’d get the same Intellisense. With this support provided in Visual Studio it’s now become a lot easier to provide documentation in an external file simply by having a –vsdoc.js file for the same file.
The way this works is that Visual Studio first looks for the –vsdoc.js file, then a debug.js file and finally for the file you actually specified in the source.
This works in basic script includes in the <head> tag or inside of the document inside of ASPX pages:
in script manager code:
<asp:ScriptManager ID="ScriptManager" runat="server">
<asp:ServiceReference Path="~/MsAjax/MsAjaxStockService.svc" />
<asp:ScriptReference Path="~/scripts/jquery.js" />
or in script source files:
/// <reference path="~/scripts/jquery.js" />
/// <reference path="~/scripts/ww.jquery.js" />
Note that I prefer NOT to use the version number with my jQuery.js file to avoid later update renaming issues so my Intellisense file is actually jquery-vsdoc.js. Match whatever your main file name is version nunmber or not. Here’s what this looks like in a project in Visual Studio for me:
Note that I also have a jquery.min-vsdoc.js file in case I decide to embed the minimized version. Visual Studio is not checking for .min.js files and mapping them to the plain –vsdoc.js file – yet. So the following also works, but only if jquery.min-vsdoc.js is provided.
I spoke with Jeff King last week at PDC and there’s a chance that support for .min.js files might be added in the future natively. But even having the extra file should be no big deal because they are not used at runtime anyway so they don’t need to be deployed.
Check it out if you haven’t already.
I’m doing the latter now through a custom script manager that minimizes and zips output, but really this should just not be necessary. ScriptManager does something similar but even it requires both debug and release scripts. Either way these approraches work well only if you use resources or otherwise have ASP.NET serve the scripts rather than letting IIS optimize and do it. It’d be really nice if IIS natively could somehow participate in this process and provide minimization. I know I can do this with some ASP.NET code in a module myself, but IIS is already extremely optimized for the compression scenarios where it builds temporary files that are served with compressed data. This is something that ultimately would be nice to have native support for so developers can set a switch and not have to think about whether you’re working with release or ‘debug’ versions of files.