Using ScriptManager with other frameworks

ScriptManager is a useful control. It manages script references, removes duplicates, enables localization and debug/release modes, enables script combining and makes client-side component-based development easier (components register their script dependencies with ScriptManager without the page developer having to know those dependencies). But one thing we should have anticipated was that this control would be interesting to developers who wish to use a different framework than the Microsoft Ajax Library.

Currently, ScriptManager isn't really usable without Microsoft Ajax because it includes the Microsoft library (without a simple way to disable it) and outputs some startup script to the page. We're looking at correcting that in future versions of the framework, but in the meantime I wanted to come up with a workaround.

The workaround is a simple control derived from ScriptManager and that enables the replacement of the MicrosoftAjax.js reference with a script of your choice:

<%@ Register Namespace="Bleroy" TagPrefix="asp" %>
...
<asp:AltScriptManager runat="server" 
    FrameworkPath="~/script/jquery-1.2.6.js" />

Here, we're replacing Microsoft Ajax with jQuery. Being derived from ScriptManager, AltScriptManager benefits from all its features. It just removes the Microsoft Ajax stuff. The resulting markup is:

<script src="script/jquery-1.2.6.js" type="text/javascript"></script>

The first thing the control does is set the default value for EnablePartialRendering to false. This suppresses the default reference to MicrosoftAjaxWebForms.js.

Then, it registers from Init two empty scripts with the type of the ScriptManager and names "AppInitialize" and "FrameworkLoadedCheck". This is a bit of magic that relies on knowledge of the names and types that ScriptManager uses to register its inline scripts.

Finally, it adds a ScriptReference with the Microsoft Ajax assembly and the "MicrosoftAjax.js" name but with a different path (the value of the new FrameworkPath property). This effectively replaces the Microsoft Ajax script reference with a script of your choice.

This should broaden developer choice in terms of client framework while keeping the great benefits of ScriptManager. Hope that helps.

Download it from here: http://weblogs.asp.net/bleroy/attachment/6374028.ashx

20 Comments

  • @Zubair: I'd be very interested to know what didn't work well for you with jQuery and ASP.NET Ajax. Can you please drop me an e-mail at bleroy at microsoft?

  • I don't have a particular case with me at the moment but I know we had issues and I didn't want to give up ASP.NET AJAX but my UI dev insisted on jQuery, it was a hard decision to make at the end of the day between built-in controls of ASP.NET AJAX vs more control in jQuery for some other tricks.

    I'd love to see an example of both these frameworks working side by side in a project, can you put up a post with some sample ? that'll be great. Thanks

  • Given that scripts from other libraries (e.g. jQuery) will not include calls to:

    Sys.Application.notifyScriptLoaded();

    What affects will this have at runtime? I was under the impression that it was a requirement for scripts to incude this call in order to play nice with ScriptManager - or is this ONLY a requirement when using partial loading, which you mention gets disabled by default anyway?

  • @Rick: true, but I think the control is still quite useful. I'll follow-up with Jeff.
    @Matt: the script loaded notification really is to play nice with UpdatePanel's script loader. If your scripts are never added to the page as part of a partial update, you don't need it (but having it won't hurt if you include the full code that tests for Sys before using it).

  • @Rick: Jeff tells me this is fixed in SP1. Couldn't get it to work on SP1 Beta 1 though. Still investigating.

  • I appreciate you looking into this, but let me raise the red flag for the record.

    I would love to be able to plaster a poster on every ASP.NET team member's office "Do not hardcode! Make it generic!" The SM issue is one, hardcoding intellisense behavior is another example. There are other examples of built-in magic that just smell of hardcoding.

    And another thing: Can we please stop coming out with new stuff, take a deep breath, and actually go back and try to polish some more on the things people actually use?! And how about actually going back and updating some of the "old" stuff. I know it's vague (I can come up with examples if needed), but I feel ASP.NET is getting dirty and need to be cleaned.

    Rant over,
    Thanks.

  • @Peter: feel free to contact me at bleroy at microsoft to tell me what needs to be cleaned.

  • The most annoying feature of the ScriptManager control is that it is completely useless without a server form.

    Although it's possible to include the ScriptManager control in a page without a server form (when EnablePartialRendering is false), none of the registered scripts will be output to the page.

    The control seems to rely on the ClientScriptManager class, which only outputs the registered scripts when the internal Begin/EndFormRender methods of the Page call internal methods on the ClientScriptManager class.

    Since MVC views can't use server forms, this must surely be on the "TODO" list?

  • @Richard: Yes :)

  • @Rick: I think you're asking a different question here, probably a more general one. If you want, we can start an e-mail discussion with Phil about that?

  • Good point Richard.

    Thanks

  • Thanks for the answer Bertrand, I hope Visual Studio will support intellisense for ScriptControl's without having to additionally reference them with ScriptManager in the future.

  • This is great by the way, but it doesn't add the js file specified by FrameworkPath into the CompositeScripts...?

  • @CaitNY: I'll look at that forum post. If you're using CompositeScript, you should be able to modify the source code so that the new reference is added to the composite list instead. The source code isn't that complex, that should be relatively easy to do. Let me know how that goes.

  • Nothing new on this thread in a while. Has anything changed? Is it possible now to subclass ScriptManager without loosing intellisense?

  • In 4.0, you don't need to subclass ScriptManager to do that sort of thing. I t's handled natively.

  • @Christofer: you are SO on your own on this one :)

  • Though I don't know why, it worked after I saved everything, exited visual studio and reopened my project. If you'd like I can e-mail you the VB version to post if you think others would find it useful.

  • @Vladimir: no, script tags block the execution of the page, so if you put them in head, you are blocking the rest of the page from displaying until they have loaded, which is usually not what you want. It's nice and tidy to put the script tags in head but it's usually not the best option in terms of performance. Plus, script tags are valid pretty much anywhere on the page. For script manager, it's actually not possible the way it's built currently as it relies on the form runat=server to display, which is after the head tag. The best option is actually to use a script loader like the one you can find in ASP.NET Ajax 4.0.

  • @Saeed: care to look at the date for this post?

Comments have been disabled for this content.