Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

There is always the ASP.net way of registering javascript on the page using the Page.ClientScript.RegisterClientScript() method, but I was wondering if there was a better way to register your javascript files for SharePoint. I see that SharePoint has a ScriptLink control that can be used as well.

I was wondering this because it was my understanding the standard Page.ClientScript.RegisterClientScript method will use the type and the name to create a registration key so that the javascript is only provided once on the page. I see that the ScriptLink control does not take a type or a key, so I was wondering if it has similar properties and if it might be better to utilize the ScriptLink control rather than the Page.ClientScript.RegisterClientScript method.

As I am sure you can see, if you have multiple instances of jQuery loading for instance with plugins, the second load of your jQuery libraries will overwrite your initial instance and the plugins that were initially added will be unavailable. Coupling this with the fact that you may have competing vendors installing projects in the farm, they may be using some of the backing libraries and cause this to fail.

So what do you guys think? Is there another method that I should be leveraging to register my javascript libraries?

share|improve this question
    
So... No takers on this one? –  Mandrake Sep 6 '11 at 17:45
    
Some good points below of things you can do, but they don't address the issues of concurrency with files. For instance, if I make two discrete webparts that have requirements on JQuery and I put them both on the page, how do I prevent them from both initializing the JQuery library. Using the same keys in script block registrations will make it not cached, but that is only a good strategy in solutions you control. –  Mandrake Jun 26 '12 at 22:27
add comment

3 Answers

You can develop a Delegate Control for the Head Section and put JavaScript registrations there with the help of a custom SharePoint feature. That SharePoint feature can be enabled and disabled according to the Sites.

share|improve this answer
add comment

Well, in this case what about including the script tag for jQuery in the site's master page. Hence, all pages will have only one call to jQuery.

share|improve this answer
    
This does nothing to prevent conflicts with other instances of JQuery (from third parties for example) –  Louis Jun 23 '12 at 2:44
add comment

You can get some protection by encapsulating your modules with something like the Revealing Module pattern. See my answer to a similar question here.

Note that in this example the encapsulation redefines $ internally from jq171, so it is not the same as JQuery's $ (which is not defined here because you used noConflict). This protects your own code.

share|improve this answer
    
This is a good approach for protecting your modules, but I was worries more about full on files. In Rails 3 now they have a whole subsytem devoted to collating, minifying and caching javascript and css for the application as part of the Rails application initialization. –  Mandrake Jun 26 '12 at 22:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.