2

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?

Improve this question
2
  • So... No takers on this one?
    – Mandrake
    Sep 6, 2011 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, 2012 at 22:27

3 Answers 3

Reset to default
2

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.

Improve this answer
1

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.

Improve this answer
1
  • This does nothing to prevent conflicts with other instances of JQuery (from third parties for example)
    – Louis
    Jun 23, 2012 at 2:44
1

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.

Improve this answer
1
  • 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, 2012 at 22:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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