Using JavaScript in SharePoint solutions

Using JavaScript in a SharePoint solution (0)

With the advent of Web front-section technology (JAVASCRIPT/HTML5), we began to use JavaScript more in Web applications. Many of the logic that was used to run on the server are now beginning to move forward gradually. This trend does not require the author to say, as long as the Web developers, including SharePoint engineers, will experience. And in the SharePoint platform, this trend of front-end is quite obvious. When we build a SharePoint solution, the number of JavaScript code is increasing, and the number of C # code is decreasing, and this trend is beyond doubt.

There are many advantages to using JavaScript in our SharePoint apps, which I think is one of the most important, and one of the most common considerations when designing a SharePoint application Architecture is the "let w3wp" principle. The W3wp.exe process is the main process that SharePoint uses to run its own web application, and the so-called "let W3wp", that is, the custom code we write, You should try not to put it into the w3wp.exe process (or other processes that SharePoint uses to run its own code, such as the process used to run the timer job). The performance issues faced by many SharePoint projects are due to poor quality of C # code written by the development team, or problems with memory leaks (such as not having the correct release of SPSite and SPWeb objects), or containing inappropriate long-running code. Once the code is running inside the w3wp.exe process, the light causes the w3wp.exe process to take up a spike in memory, leaving the w3wp.exe process to hang.

More use of JavaScript is one of the important means to implement the "let w3wp" principle. A very common scenario, in a list in a SharePoint site, is to store the notification information that needs to be visible to the user, and the customer needs to be able to see the notifications he should see on the home page when the user wants to open the site. A logical solution to this requirement is to create a Web Part that uses C # code, through objects such as spquery, to query from the list to the notification to be displayed to the user, and then to display the notification in the Web section. If we use this scheme, our code is the W3wp.exe process running on the server, all the potential problems of code need w3wp.exe to bear.

With the SharePoint sandbox solution (Sandboxed solution), we can run our C # code in a separate sandbox process on the server to avoid the impact on w3wp.exe, a way to implement the "let w3wp" principle. But another more flexible approach is to use JavaScript's front-section technology to achieve the functionality we need. For this requirement, developers can simply rely on JavaScript and the SharePoint JavaScript Object Model to query from the list to the notification that needs to be displayed to the current user, and then display the notification on the first page. Since these JavaScript code runs in the user's browser, they are much smaller than the C # code for the impact of the SharePoint server.

So, as a SharePoint engineer, it's important to know how to use JavaScript in the right way in your custom SharePoint app. The purpose of this series of articles is also in this, most of the content is the author himself in the process of practice, summed up some personal experience. However, this series of articles does not tell the JavaScript language itself and the SharePoint JavaScript Object Model, and we do not tell you how to use the JavaScript language correctly ( While this is very, very important for engineers, there are already too many books and articles that tell the best practices of the JavaScript language.

This article is the beginning of a series of articles.

Using JavaScript in a SharePoint solution (1) – Referencing a. js file

This article is the first article in a series.

• Using JavaScript in a SharePoint solution (0)

The first step in using JavaScript in a SharePoint application is to know how to put a well-written. js file on the page. Well, you might think this topic is too simple, "does quoting a. js file just add a <script> tag to the top of the page?" "But the things we have to think about are usually much more complicated than that." For example, most of our. js files, which may all be placed on all pages in the site, modify every. aspx in the site is obviously not a good idea, and we need a better, more flexible solution.

1. Refer to the. js file directly on the master page

Because all pages in a SharePoint site use the same master page (. master file) by default, referring to a. js file on the master page automatically allows all Web pages that use the master page to refer to the. js file. In the

(Although SharePoint Designer is used above, I do not recommend that you use SPD directly in a production environment to make such modifications to the master page.) The correct approach should be to maintain modifications to the custom master page in the Visual Studio project, and to publish the custom master page to the Web site in module mode. )

Reference. js directly in the master page, simple and straightforward. This approach is ideal for referencing JavaScript libraries that are used on almost all pages, such as jquery. After a reference to jquery has been completed on the master page, the JavaScript code in all pages (and all custom Web Part on the page) in the site can be used directly from the jquery library. The entire project, if there are some common custom JavaScript library files, can also be referenced in this way.

Note, however, that you need to seriously consider whether to place a reference to the. js file in the

The <script> tag supports the defer attribute, which is used to tell the browser that you can run me after the HTML content is loaded. HTML5 also added an async attribute to the <script> tag to mark that the code can be executed asynchronously. But because of browser compatibility (you know), I recommend that you do not rely on these attributes.

2. Using the Spweb.customjavascriptfileurl property

If you want to refer to a. js file on all pages without modifying the master page, an alternative is to do so through the Spweb.customjavascriptfileurl property. Set the path of a. js file to this property, and the <SharePoint:CustomJSUrl> control on the master page will automatically load that. js file onto the page.

The following PowerShell script demonstrates how to set a value for Spweb.customjavascriptfileurl. I use PowerShell only for demonstration purposes, and in your project, the code is usually implemented in C # and probably written in a feature activation event, so that when feature is activated, it sets the script that all pages in the site need to load.

One problem with the Spweb.customjavascriptfileurl property is that it can only be used to specify a. js file. But this problem is easy to overcome, we can let the quoted. js file is just a "launcher", it is responsible for loading other required. js files. Just like this:

Of course, you can also write this "launcher" a little more complicated and flexible.

Another problem with the Spweb.customjavascriptfileurl property is that the. js file referenced by it is bound to be loaded in the

3. Use custom Action

In most cases, the purpose of the custom action is to add a custom menu item or other UI element to the interface, but the custom action can also be used to add the. js reference to the page.

In Visual Studio, add an "empty element" to your SharePoint project, and then add a <CustomAction> element to the <Elements> element as shown below. The "location= ' ScriptLink '" property tells SharePoint that the purpose of this <CustomAction> is to "inject" the script into the page. The "Scriptsrc" property is used to specify the location of the. js file to be referenced. Inside the "scriptsrc" attribute, you can use "~site" and "~sitecollection" tags to represent the root of the site and site collection, for example: "Scriptsrc= ' ~site/scriptlibrary/start.js ' "。

If you want to reference more than one. js file, it is also very good to do, just need to add multiple <CustomAction> tags. Note the "Sequence" attribute for each <CustomAction>, which is used to identify the loading order of each. js reference. SharePoint refers to the. js file in the order specified by the "Sequence" property instead of the <CustomAction> tag's declaration order.

The best thing about Custom action is that you can put it in a feature. When the user activates the feature, the site references the. js file specified by the custom action, and the user deactivates the feature, and these. js files are not referenced. This is a great deal of flexibility.

A limitation of the Custom action is the. js file that is referenced by its "scriptsrc" property, either in _layouts or in the site or site collection. It is not used to reference an external. js file, for example, "scriptsrc= ' http://ajax.aspnetcdn.com/ajax/jquery/jquery-1.8.2.min.js '" is not working. Of course, you can use the previously mentioned "launcher" scheme to solve this problem, first by the custom action to reference a "launcher". js file, and then in this "launcher" to load other external. js files.

4. Custom scheme

If the above scenarios are not suitable for you (or not strong enough/flexible ...), then you can build a custom. js file loading scheme. A custom. js file load scheme should try to solve the following problems:

• You can refer to a. js file, either inside or outside the Web site;
• You can specify the loading time for a. js file: After the
• You can specify that a. js file be loaded only to a specific page, such as a new list item page for the Forms page/list of the list (new Form)/page for a specific URL
• You can specify a dependency between multiple. js files and load them in the order of dependencies

The text overview describes several common ways to reference. js files in a SharePoint site, and in a later article we will continue to talk about where to place the. js files, how to use JavaScript scripts on the Web Part, and more.

Using JavaScript in SharePoint Solutions (2) – modularity

This article is the second article in using JavaScript in SharePoint, and the previous articles include:

• Using JavaScript in a SharePoint solution (0)
• Using JavaScript in a SharePoint solution (1) – Referencing a. js file

Theoretically, you should make your code modular, regardless of the scenario in which you are writing JavaScript code. JavaScript code is very easy to turn into mess, especially if you don't have to modularize the code. The same is true with JavaScript in SharePoint. Some of the basic JavaScript modularity principles include:

• Try to make each of the. js files a module
• Each module can have only its own "private" data and functions, the module only exposes the necessary data and methods to go out
• There is a dependency between the modules
• By a loading scheme, the modules can be loaded in the correct order (usually their dependencies)

Here are two common JavaScript modular approaches, and the corresponding loading scenarios.

1, the most simple modular

The simplest way is to use the anonymous function of JavaScript directly. By placing the entire module in an anonymous function that executes immediately, we can get a separate "execution space". In the following example, we can define "private" variables and functions in the module, and then register the content that needs to be exposed in a global "namespace" MyNamespace. Since JavaScript does not actually have the concept of namespaces, our namespaces are actually implemented by defining a global variable. Registering all modules of the entire application in the same "namespace" minimizes the use of global variables (in theory, there is no need to register other global variables in addition to the namespace itself).

The way this namespace is defined is sometimes written like that. In the example, the module exposes a constructor directly.

The advantage of passing namespaces to the parameters of an anonymous function is that, in other modules, it is natural to invoke the interface exposed by the other module through the namespaces passed in by the parameters.

The biggest benefit of this minimalist approach is that it doesn't have to rely on any third-party libraries and has very good compatibility. You can copy a module file from one project to another, (in addition to modifying the namespace that the module registers with), it is possible to use it directly.

Managing dependencies between modules and loading them according to dependencies is an issue that developers need to consider. You can either use some simple methods (such as referencing all the module files directly to the page, if the modules are relatively small), or create a custom scheme to manage.

Here is a simple example of declaring all the modules in an application and defining their dependencies, and then loading all the modules in order according to the declaration, using a custom script loader. Well, the actual code of the specific loader is not attached, this is just a handy example of writing. In fact, as long as you have a module declaration, using functions like Lazyload to load the module is not difficult to implement.

2, AMD (asynchronous module Definition) Modular

In addition to encapsulating modules with anonymous functions that do not rely on any third-party libraries, you can, of course, use the AMD specification to define modules. There are many libraries that support the AMD specification, such as the famous Requirejs. Here is a module that is based on the REQUIREJS definition.

Of course, once you decide which AMD library to use, then all modules need to use the look that the library requires, but most of the AMD spec-based libraries are very similar to the definition requirements for modules. Requirejs is able to automatically load the other modules it relies on when loading a module, depending on the dependencies declared by the module. For more detailed information about Requirejs, please refer to its official website.

This article only describes two scenarios for JavaScript modularity. Of course, there are many other options for modularity, and there are many similar libraries on the market. Many of the more complex JavaScript frameworks, such as ANGULARJS, can even be directly involved with modular functionality. Microsoft's typescript directly built-in module this keyword (typescript seems to be trying to emulate Es Harmony, the next JavaScript Language Specification version of the use) to support modularity. Based on which scenario JavaScript is modularized, you need to choose a solution that is best for your application based on each factor. Based on my experience, basically all of the scenarios should work well with SharePoint.

Using JavaScript in SharePoint solutions