The new script loader object – part V

[Update: with preview 6, Sys.loader.debug is replaced by the Sys.debug property]

We’ve already met several features introduced by this awesome new object. However, in the comments of one of the previous posts, William Apken asked about the CDN path for preview 6. That reminded me that I still haven’t presented all the features associated with this object. And that’s why in this post we’ll be talking about paths to scripts and on how we can influence them.

Btw, and before going, the base path for the CDN release of preview 6 is

Ok, now that you know the base URL, you have two options for using CDN preview 6 hosted  files in your app:

  • you can use the script tag and specify an absolute address on it. For instance, if you’re just adding the start.js file, you can simply use the absolute URL for the CDN and then all other files will be downloaded from there;
  • you can use the Sys.loader.basePath property for influencing the place from where the script files are loaded.

With the last option, you can, for instance,load some files from place A and others from place B. For instance,consider the code  we’ve used in the imperative post – take II…by using the second approach, we can easily influence the download of the files by dropping the next line of code before calling the Sys.require method:

Sys.loader.basePath = "";

However, start.js would still be loaded from the local server because we’re using a relative path for that file!

In my opinion, you probably won’t be using this property much since the easiest option is to use a relative path to the start.js file and then change it to CDN when you deploy your app Yes, I’m assuming you’re downloading the JS files on the fly through the Sys.loader object. If that is not the case, then you’d probably be ok by changing the path for the loader’s file (traditionally, this might start.js, microsoftajaxcore.js or microsoftajax.js) and then immediately setting the basePath property before including the other JavaScript files (this would let you use relative paths for those other JavaScript files).

Btw, and since we’re talking about influencing paths, you should also notice that the Sys.loader has another interesting property: I’m talking about the debug property. When this property is set to true, you’ll end up downloading the debug files (ex.: microsoftajaxcore.debug.js). Setting it to false means getting the release files:

Sys.debug = false;

In case you’re wondering, these features are only possible due to the way debug and release urls were specified during the defineScripts method call. For instance, take a look at the following snippet:

    releaseUrl: "%/MicrosoftAjax" + "{0}.js",
    debugUrl: "%/MicrosoftAjax" + "{0}.debug.js",
    codependencies: ["Core"]
}, …

As you see, we’re using the % char for specifying a marker that will be replaced for the script object’s basePath property. Another interesting thing you’ve (probably) noticed is that you can use the {0} for replacing a portion of the string with the name of the current script info object (this strategy is used by MS AAJX for simplifying the registration code for each of the modules that compose the library).

And that’s it for now. Stay tuned for more on MS AJAX.


~ by Luis Abreu on October 18, 2009.

6 Responses to “The new script loader object – part V”

  1. FYI it is just Sys.debug now. Also you do have another option for changing paths if individual scripts. Two actually. You can reregister the script with defineScript (or just set the URL field on the existing one). Or more interestingly you can statically reference any script from any location, even if it has dependencies. You might do that for example to force a particular script to load the debug version while the rest are still release.

  2. Yep, you”re right…I”ve just tested it at work and it”s Sys.debug. Not sure on why Sys.loader.debug worked at home since it no longer exists in preview 6…

  3. I”ve just noticed that I had Sys.loader.debug = true at the beginning of the page 🙂 thanks for the correction.

  4. If I have the MicrosoftAjax folder that contains the start.js on my local file system. And I register a custom script all works well.

    When I change the start.js to load from the CDN. All of the Microsoft .js files continue to load correctly. But my custom script does not load any longer.

    Checking the basePath of the Sys.loader object shows that it is pointing to the CDN location. Which makes sense.


    releaseUrl: “%/../hvClientControls/” + “{0}.js”,
    debugUrl: “%/../hvClientControls/” + “{0}.js”

    no longer is correct.

    I have not dug through the code yet (prefer not to) but since the defineScripts object uses this path as a relative path from the basePath. How to specify not to use the relative path?

  5. Hello William. You need to specify those properties (releaseUrl and debugUrl) in your script which registers scripts. In other words, copy that code from the start.js to your js file which registers your scripts but change it so that it points to your urls (removing the % is a must in this case)

  6. Thanks.

    It does not show it in my snippet, but I”m following the two file method. Where I have registerCustomScript.js and a CustomScript.js where the object is created and wrapped in an execute function.
    Like you have showed in a lot of your examples.

    So the relative path of the Sys.loader.defineScripts is based upon the location of the RegisterCustomScript.js file or the location of the currently loaded html page where RegcustomScript is being called from?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: