Tuesday 6 September 2016

SP.SOD Class

Represents an on-demand ECMA script. 
SP.SOD

Example

The following example registers a link to an ECMAScript(Jscript, JavaScript) file and creates an input button on an application page that calls a function defined in the script file. The function displays a simple "Hello" message on the page.
First, create a file named "MyScript.js" in the "\Program Files\Common Files\Microsoft Shared\Web server extensions\14\Template\Layouts\1033" folder, and add the following code to the file:
function sayHello() {
  alert("Hello");
}
//Notify SharePoint that the custom file has loaded.
SP.SOD.notifyScriptLoadedAndExecuteWaitingJobs("myscripts.js");
Then add the following code to the application page.
<asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">
<script type="text/ecmascript" language="ecmascript">

    function runCode() {
        var x = ExecuteOrDelayUntilScriptLoaded(sayHello, "MyScript.js");
    }

</script>

    <SharePoint:ScriptLink ID="ScriptLink1" runat="server" language="javascript" Name="MyScript.js"/>
    <input id="Button1" type="button" value="Run Code" onclick="runCode()" />

</asp:Content>


In SharePoint 2013 the Javascript loading mechanism seems to be changed a bit. When porting a SharePoint 2010 solution to 2013 I found out that sometimes some weird script errors where occuring when calling SharePoint Javascript libraries. On some pages in SharePoint 2013 it happens that not all SharePoint Javascript libraries are loaded because of the built-in lazy loading mechanism. This reduces bandwidth when loading pages, because no unneeded libraries are downloaded to the client. But this causes issues when you want to use not loaded libraries. The following sample Javascript codes shows how you can load some Javascript Libraries and then automatically call your function where you want to use those libraries:
1//Register SOD's
2SP.SOD.registerSod('core.js''\u002f_layouts\u002fcore.js');
3SP.SOD.executeFunc('core.js'falsefunction(){});;
4SP.SOD.registerSod('sp.js''\u002f_layouts\u002fsp.js');
5SP.SOD.executeFunc('sp.js'falsefunction(){});
6SP.SOD.registerSod('sp.core.js''\u002f_layouts\u002fsp.core.js');
7SP.SOD.executeFunc('sp.core.js'falsefunction(){});
8 
9function doSomething() {
10   //Your Logic here which calls sp core libraries
11}
12 
13// Load asynchronous all needed libraries
14ExecuteOrDelayUntilScriptLoaded(function() { ExecuteOrDelayUntilScriptLoaded(doSomething, 'sp.core.js') }, 'sp.js');
In the example above we’re using the SP.SOD library provided with SharePoint. Those existed already in SharePoint 2010 and are still present in 2013. With the SOD library it is possible to lazy load Javascript files and load them on the moment you need them. The sample script exists of three parts. In the first step we register Sod’s (Script on Demand) where we define a key and as value the relative path to the Javascript file. We also call executeFunc to load the file using a dummy function. In the second step we create a custom function. This is the function where you want to call specific methods in the Javascript libraries loaded. Then we call ExecuteOrDelayUntilScriptLoaded. Because in this sample we want both sp.core.js and sp.js loaded, we nest it with another call to ExecuteOrDelayUntilScriptLoaded and finally let the callback call the function which needs the libraries loaded before executing. This method of loading scripts seems to work well in SharePoint 2013 and can also be used for other OOTB Libraries, like the Taxonomy Javascript Library. When your site is still running in SharePoint 2010 mode however, this doesn’t work properly. The registering of Sod’s seems to break with the 2010 way of loading the OOTB Javascript files so there you need only the ExecuteOrDelayUntilScriptLoaded calls. If you need to detect the mode in Javascript you can use the SP.Site.get_compatibilityLevel() function to retrieve that info using JSOM and then dynamically decide which method of loading to use.

No comments: