Tag Archives: JavaScript

ECMAScript

App for SharePoint project​

Jasmine with Visual Studio and SharePoint Apps – Part 1

This blog does no​t describe how to perform JavaScript ​TDD (test-driven development) or BDD (behaviour-driven development). It does however describe how to set-​​up Visual Studio and configure an App for SharePoint project to get you started.

1. Install VS Extensions

Open Visual Studio 2013 > TOOLS > Extensions and Updates…

Within the Left panel, click on Online and search for Chutzpah Test

Download:

  • Chutzpah Test Adaptor for the Test Explorer
  • Chutzpah Test Runner Context Menu Extension

And then restart Visual Studio

2. Configure Test Explorer

Open Visual Studio 2013 > TEST > Windows > Test Explorer and pin the window to suite your preference…

Top left of the Test Explorer window, click on the button  “Run Test After Build” Run Test After Build

Create a new App for SharePoint Project​

Now that we have Visual Studio configured and ready to go, we need an App for SharePoint project to work with.

Create a new App for SharePoint project​

App for SharePoint project​

Choose where to debug the App and the type: Provider-hosted

Choose where to debug the App and the type

The type for project to create: ASP.NET MVC Web Application

ASP.NET MVC Web Application

And finally the authentication model: Windows Azure Access Services

Windows Azure Access Services

And finally You will then be prompted to sign into the portal your specified earlier.​

Adding Jasmine JS to a Project​

Now that we have an App for SharePoint project lets add Jasmine.

1. Install NuGet Package

Open Visual Studio 2013 > TOOLS > NuGet Package Manager > Manage NuGet Packages for Solution…

Within the Left panel, click on Online and search for SharePoint Jasmine Test Runner and click download.​

Search for SharePoint Jasmine Test Runner and click download

Note: the SharePoint Jasmine Test Runner package was created by Thorston Hans and at the time of writing this blog it was at version 0.0.1 and contained Jasmine 2.0. My reason for choosing SharePoint Jasmine Test Runner over Jasmine Test Adapter was because it did not include the VMC files which are not required if you plan to testing your code directly in Visual Studio.​

2. Configure Files/Package

Navigate to the Scripts folder for each of projects you added the package too and you will notice a folder containing JS files called  jasmine-samples. You do not need this scripts or this folder, so select the it and right click to see the context menu and then click either Delete or “Exclude from Project“.

3. Other Files

The Content folder contains a new folder called jasmine containing a single CSS file, don’t need to do anything with this.​

4. How to use Jasmine

After adding the SharePoint Jasmine Test Runner package, start by adding a “spec” file to your scripts folder. Spec files are where you will  describe your application and are the basis of your tests. After writing each test, you will immediately write the code (e.g. a function) within your “source” file fore fill the spec and therefore cause the test to pass. You repeat this process over and over again until you have written one or possible more spec that describes your JavaScript Application. Once all the tests pass have successfully passed then your development is finished (in theory).

5. Naming Convention

Depending on the size and complexity of your project, you many have one or more spec and source files. I would recommend pairing up the files so that a spec file always as a source file and vice versa.

For example:

  • filename_spec.js              contains the specs used to test the code.
  • filename.js                         contains the source code used by the application

4. What to look out for

  • Keep your spec and source files paired up and within the same folder.
  • If you are seeing duplicated tests then make sure that spec files are not being referenced. For example check the _references.js file and remove any reference:
    /// <reference path="_tests/filename_spec.js" />
  • Visual Studio add automatically adds references to the _references.js file every time a new JS file is added to the Scripts folder. You will need to open the _references.js file​ and remove spec file​ references each time a new JS file is added.
  • If your test continue to fail even when they look correct, make sure that your spec file has a reference to its related source file:​
    /// <reference path="filename.js" />
  • To enable your test to run every time you save a file, click on the button “Run Test After Build” located at the top left of the Test Explorer window.

Jasmine with Visual Studio and  SharePoint Apps​ – Part: 123

Useful links
Video Tutorials

Client-side Development Techniques with CQWP(s) and JavaScript…

The other day I was talking to one of my colleague John Holah about retrieving large amounts of data from a SharePoint 2010 Lists using “client-side” v “OOB” techniques for a particular client, who has set use a number of challenges/limitations:

  • Our access is limited to Site Collections
  • We cannot deploy server-side code
  • Internet Explorer 8 is used by all of client’s employees (120,000 Users globally)

Depending on what the end goal, previously we used these techniques to retrieve data:

  1. CQWP* and write custom XSL to render the content as HTML
  2. Call a SharePoint web service using a JavaScript library call SPServices and
  3. populate an array or an object before rending it as HTML

Option 1: is relatively quick to implement, however it has a number of limitations:

  1. The source of the content is limited to either a Content Type or a List
  2. In my opinion, it is not as easy to apply logic to XSL as it is to JavaScript
  3. IE8 times-out if a large number of rows are rendered to the UI (this can vary depending on the number of columns as well as rows and the complexity of the HTML)

Option 2: is has flexibility, however:

  1. A call to a web service is not as efficient as the CQWP in retrieving data.
  2. A significant number of lines of code needs to be written to call web service (particularly if it’s asynchronous)
  3. Supporting custom code is time consuming as developer coding styles and techniques vary

So what if we combined the two techniques? Would we get the rapid development of the CQWP and flexibility SPServices? Well I’ll let you decide after I show you some code:

Step 1

As preparation create a new list called “Product Relationships” and add the following columns:

Column                      Type
-----------------------------------------
Product1                    Number
Product2                    Number

And add some items, for example:

Product1          Product2
------------------------------------------
 2                   13
 6                    2
13                   14
15                   16
18                   19
20                   18
20                   19

Step 2

Add a CQWP to a page, configure it to point to your new list and export (save to your local machine for editing).

Step 3

Add the following directory structure to the “Style Library” directory of you site collections root sites:

\Branding\XSL\MyWebpart

And upload the MyWebpart.wepart file having add the reference (path) to the XSL file (you will create shortly):

  • ItemXslLink
  • MainXslLink
  • HeaderXslLink

And then edit the element called “Xsl”.
Once completed the file should look something like the following:

Step 4

Create a copy of the ContentQueryMain.xsl file located in  “\Style Library\XSL Style Sheets\” and edit it so that it looks something like this:

The lines of code to look at in detail starting from the top are:

<script />

The tag referencing the “_temp.js” file, this would normally be placed in the master page, however for the demo it is here.

<div id="relationshipEditor">…</div>

Used by the JavaScript to inject the demo content.

<script>…</script>

Wraps around the XSL template which will populate a JavaScript Array.

var pr = SJLewis.ProductRelationships;

Creates is a shortcut to a JavaScript Namespace.

<xsl:call-template name="populateArray" />

Does what is says, called the populateArray template.

<xsl:for-each select="$Rows">…</xsl:template>

Loops through the list items.

pr.productRelationships.push(new pr.productRelationship(…));

The “new pr.productRelationship(…)” code creates a new object containing data from the list item. And “pr.productRelationships.push()” add the object to the array.

pr.doSomeStuff();

Is a function that loops though the array and added the content to the page.

Step 5

Create a new JavaScript file for called “_temp.js” and add the following code:

And upload to this directory:

/MySiteCollction/Style Library/Branding/HTML/MyWebPart/_temp.js

Step 6

Reload the page and as baring no errors you page may look something like this:

Test 20 - 20
Test 20 - 20
Test 18 - 18
Test 15 - 15
Test 13 - 13
Test 6 - 6
Test 2 – 2

This model could easily be extended to retrieve data from multiple Content Types or Lists by adding more CQWPs and then exposing more objects and arrays from the “SJLewis.ProductRelationships” namespace. And instead of each CQWP calling the “doSomeStuff()” function to populate a DIV tag, they could call a “trigger()” function that informed a custom event handler when the data is loaded and ready for processing (e.g. combined, filtered and displayed by a div exposed by a CEWP).

XSL / JSRender Trap (Updated 14/07/2014)

When adding properties to a HTML tag located within your CQWP’s XSL file, which the value will be populated by JSRender, be sure to escape the curly braces like this:

Otherwise the XSL parser will strip the {{attr:ID}}} from the tags properties and the HTML will be rendered like this {attr:ID}.

CQWP Cashing(Updated 16/07/2014)​

Can’t see your new data and you need to see it immediately? Sounds like you need to turn off Caching. To do this, export the webpart and edit the property called “UseCache” by changing its value to “False”. The result should look like this:

Next save the webpart file and upload to your “Web parts” gallery and the final step is to replace the original webpart with using your new definition.

Glossary of terms:
  • CQWP:  Content Query Webpart
  • CEWP:  Content Editor Webpart
  • OOB:     Out of the box​

Cool Visual Studio 2013 plugin called Javascript Parser…

Found a cool plugin which improve support for JavaScript within Visual Studio 2013 and therefore help the performance of development process and avoid possible bugs.

Excellent!

However the best thing I like about “Javascript Parser” plugin is that I can now use the “// TODO: …” Task List Tokens in my JavaScript code just like we can with C#. And it gets better, if you like using Visual Studio’s default Task List Tokens (including as HACK and UNDONE) or would like to add your own, well you can. Simply go to the Javascript Parser’s window within Visual Studio (which can be found under View, Other Windows…) and click on the settings menu (the “cog” located at the top left), and select [Settings…], then [Advanced] and then enter your new values.

These are the keywords I’m using: “TODO:, To Do:, To-Do:, HACK:, UNDONE:“. Of cause I never need to use “HACK:” 😉

Javascript Parser

http://visualstudiogallery.msdn.microsoft.com/288a2b0f-1357-47b4-8215-1134c36bdf30
Javascript Parser

Related information

How to: Create Task List Comments
http://msdn.microsoft.com/en-us/library/zce12xx2(v=vs.100).aspx​

SharePoint Online Public Site: adding JS & CSS references to a Master page

I’m not going to describe the process of creating a custom master page from end to end, as there are plenty of good articles and blogs out there already. I just want to share one possible pitfall that I fell into…

As any owner of a website might, I decided to create a new master page for my SharePoint Online Public Site.  And to save time I started by coping one of the HTML files associated with an “out of the box” mater-pages.

The first thing I planned to do was to add references to my CSS and JavaScript files. This should be a very simple task, unless like me you decide to try to add the references right at the bottom of the <HTML /> block. Or to me more precise, just after the <mso:CustomDocumentProperties /> block of code.

Note: The mso tag contains block SharePoint metadata used by Design Manager to convert the file into a .master file.

After much trial and error I found the “Design Manager” parser seemed to ignores code (or at least mine) that proceeds the mso tags, in the <head /> block.  The fix is simple, I added my references just above the mso tags and all will be fine.

And this is what my JavaScript and CSS references look like:

<!--CS: References to External Files-->

<!--SPM:<SharePoint:CssRegistration Name="/_catalogs/masterpage/MPName/CSS/london.css" After="corev15.css" runat="server"/>-->

<!--MS:<script id="jQuery"     type="text/javascript" src="/_catalogs/masterpage/MPName/JS/_Bundle.js">--><!--ME:</script>-->

<!--CE: References to External Files-->

If you are interested in what these tag and can be used for, taking a look at this page: http://msdn.microsoft.com/en-us/library/jj822370.aspx

Other useful links:

Update January 2015:

Starting January 2015, Microsoft is making changes to the SharePoint Online Public Website feature. Customers who currently use this feature will continue to have access to the feature for a minimum of two years after the changeover date of March 9, 2015. New customers who subscribe to Office 365 after the changeover date won’t have access to this feature. Moving forward, Office 365 customers will have access to industry-leading third-party offerings that will enable them to have a public website that provides a complete online solution and presence.

https://support.microsoft.com/en-us/kb/3027254