SusQTech “30 on Thursday” Webinar “Top 10 jQuery Uses in SharePoint 2010”

“30 on Thursdays”

I want to thank the fine folks at SusQTech (@SusQTech) – Steve Witt (@SPLumberjack) and Julia Oates (@juliaoates), in particular – for asking me to present in their “30 on Thursday” webinar series today.

We had a great turn out and it’s a given that I love to talk about SharePoint and jQuery together. It’s like peas and carrots or chocolate and peanut butter.

My slides from the webinar are available on SlideShare. If you missed it, the recording will be available soon on the “30 on Thursday” site. (Every time I type “30 on Thursday” I’m reminded how long ago it was that I was 30.)

Referencing jQuery, jQueryUI, and SPServices from CDNs – Revisited

In my previous post entitled Referencing jQuery, jQueryUI, and SPServices from CDNs, I provided the references to quickly add jQuery, jQueryUI, and SPServices from the CDNs I typically use.

However, I made a bit of a faux pas in what I provided. It’s better to omit the protocol in the references. Browsers will simply use the current protocol, whether it be http: or https:, as needed. This means that you won’t have to worry about any issues down the road should you decide to implement SSL. It also means that the location your user happens to use to access the site doesn’t matter.

Here’s my updated set of references with the protocols omitted and updated to the versions I’m currently using:

<!-- Reference the jQueryUI theme's stylesheet on the Google CDN. Here we're using the "Start" theme -->
<link  type="text/css" rel="stylesheet" href="//" />
<!-- Reference jQuery on the Google CDN -->
<script type="text/javascript" src="//"></script>
<!-- Reference jQueryUI on the Google CDN -->
<script type="text/javascript" src="//"></script>
<!-- Reference SPServices on cdnjs (Cloudflare) -->
<script type="text/javascript" src="//"></script>

Refreshing a Page Section with a User-selected Interval Set with jQueryUI’s Slider

I’m still doing lots of work with SharePoint 2007, even while many of my compatriots have moved on almost exclusively to 2013 work. The new shiny stuff is fun and all, but just because it’s new doesn’t mean that all the good work is there. Both SharePoint 2007 and 2010 are still providing valuable collaborative toolsets in organizations out there.

When you work with an older version of the product, you get the benefit of hindsight as well as knowledge of new trends in user interfaces and development approaches.

One of my clients wanted to create and auto-refresh capability for a SharePoint 2007 page that they use as a sort of dashboard. Many of the people in the organization keep the page open all day, and hitting refresh all the time is tedious. They also forget sometimes and can mistakenly be looking at stale content.

In SharePoint 2010, Data View Web Parts (DVWPs) provide this capability simply by checking a box on the ribbon (which usually works). I’ve rarely seen anyone enable the feature in 2010, but it’s there. To make this work in 2007, I had to build it with script.

To improve the situation, and therefore the general user experience (UX), we decided to give the user control over the auto-refresh capability. It wasn’t that much extra work to do it this way, and by allowing them the set their own refresh interval, they feel that they have more control of the page. This makes them more satisfied with the solution, which increases adoption. All goodness.

Page Map

It took some iteration to decide how to lay things out ideally, so what I’m showing here is closer to the end result than the starting point. I was able to take advantage of a function I had written earlier called refreshElement, which I wrote about in my prior post entitled Refreshing a Web Part Without a Postback Using jQuery’s AJAX Function.

The first step is to ensure that we have references to jQuery, jQueryUI, and jQueryUI’s CSS in the page. I’m also using jQuery cookie to set a cookie with the value in the slider that the user sets, thus making it possible to persist the value between sessions. In this particular case, we have references to the script libraries in the master page because we’re using them pervasively.

Next, I added a little markup to the page. My thinking on this was that by adding the markup at the top on the PlaceHolderMain rather than where the slider actually ended up, I could ensure that the data which drives the refresh will always be in the same place that I always put my script references, thus easy to find. If we decide to put the slider somewhere else in the page, I can just change the script, with no need to change the markup in the page itself. (We’re using this capability in four sites at the moment, with more to come.) There’s a div containing the slider info and then a second div wrapped around the area of the page I’d like to refresh. The refresh div can really surround anything in the page. I’m using AJAX to grab the full page, and I can simply parse out whatever is in the div. In this case, it contains the complex DVWP and one other Web Part. Note that the first div has a data attribute (how very HTML5 of me) which “points” to the div we want to actually refresh.

<div id="aaa-refresh-control" data-to-refresh="aaa-listing"></div>
<div id="aaa-listing"><!-- ... DVWP, etc. ... --></div>

Next comes the script. Hopefully the comments inline are clear enough, but if you have questions feel free to ask them in the comments section.

$(document).ready(function() {

  // If there is an element with the id aaa-refresh-control, we'll refresh what it indicates at a user-specified interval
  var refreshControl = $("#aaa-refresh-control");
  var toRefresh ="to-refresh");

  // If there is a request to refresh an element...
  if(toRefresh !== undefined) {


    // Add the elements to the page that we need for the functionality to work
    refreshControl.append("<div id='refreshInfo'>" +
      "<label for='refreshInterval'>Refresh every</label>  " +
      "<input type='text' id='refreshInterval'/>minutes " +
      "<label id='refreshTime'></label></div>");
    refreshControl.append("<div id='refreshSlider'></div>");
    refreshControl.append("<div id='refreshNow'></div>");

    // Get the refresh interval value the user has set by retrieving the cookie
    var refreshInterval = $.cookie("refreshInterval");

    // If the refreshInterval hasn't been set, default to 5 minutes
    if(refreshInterval == 0 || refreshInterval == undefined) refreshInterval = 5;
    $("#refreshTime").html("Last refreshed: " + getNow());

    // Set up the refresh behavior using a timer
    var refreshListing = setInterval(function(){
      refreshElement(toRefresh, "", "Please wait...", "Refreshing...");
      $("#refreshTime").html("Last refreshed: " + getNow());
    }, 1000 * 60 * refreshInterval);
    $("#aaa-listing").css("clear", "both");

    // Adjusting the slider allows the user to set the refresh interval to their own needs
      value: refreshInterval,
      min: 5,
      max: 60,
      step: 5,
      slide: function(event, ui) {
      change: function(event, ui) {

        // Set a cookie with the refresh interval so that we can reload it when we return
        $.cookie("refreshInterval", ui.value);

        // Re-initialize the timer
        refreshListing = setInterval(function(){
          refreshElement(toRefresh, "", "Please wait...", "Refreshing...");
          $("#refreshTime").html("Last refreshed: " + getNow());
        }, 1000 * 60 * ui.value);
        $("#aaa-listing").css("clear", "both");


// Refreshes an element's contents on a user action, showing a modal dialog during the refresh
// elementId  The id of the container element
// qs      The Query String to append to the current URL
// msg      The message to show in the dialog
function refreshElement(elementId, qs, title, msg) {

  var elementObj = $("#" + elementId);
  var infoDialog = $("<div><div>" + msg + "</div><div class='aaa-please-wait'></div></div>").dialog({
    open: function(event, ui) {
      $(".ui-dialog-titlebar-close").hide();  // Hide the close X
      $(this).css("overflow-y", "visible");  // Fix for the scrollbar in IE
    autoOpen: false,
    title: title,
    modal: true,
    position: { my: "center", at: "center", of: window }

  elementObj.fadeOut("slow", function() {
      // Need this to be synchronous so we're assured of a valid value
      async: false,
      url: window.location.pathname + qs,
      complete: function (xData) {
        newHtml = $(xData.responseText).find("#" + elementId).html();

  }).fadeIn("slow", function() {

// Helper function which gets the current time and formats it in HH:MM format
function getNow() {
  var d = new Date();
  var curr_hour = d.getHours();
  var curr_min = d.getMinutes() >= 10 ? d.getMinutes() : "0" + d.getMinutes();
  return curr_hour + ":" + curr_min;

And voila. We have a little slider right under the main links in the Quick Launch which the user can slide to set their own refresh interval. Every time the timer hits that interval, the dialog pops up with info about the refresh, the content is refreshed, and the time above the slider changes to tell the user how fresh the content is.
jQueryUI Slider

Upgrading Your jQueryUI Custom Theme

jQuery ThemeRollerI have always wondered what would happen if I created a custom theme for jQueryUI using the excellent ThemeRoller tool and then wanted to upgrade my version of jQueryUI. It always seemed like the odds were that the existing CSS and accompanying image files wouldn’t change too much (I’ve found that there’s far less disruption in an upgrade to jQueryUI than there is in an upgrade to jQuery itself), but at a certain point, there were bound to be changes that mattered enough to cause a problem.

I haven’t run into any of those problems, but as I’m carefully upgrading jQueryUI in a client installation, I don’t want to make any egregious mistakes. (The buck stops with me no matter how crappy a tool I’m using works.)

I decided to Bingle to see if there was a converter that some kind soul may have built out there somewhere. Lo and behold, it’s even easier than that. I found a nice little answer over on StackExchange that shows how. Thanks to StackExchange user fbuchinger for that. Gotta love the Internet.

If you open your custom CSS file and scroll down to the second main section, you’ll see something like this:

 * jQuery UI CSS Framework 1.8.20
 * Copyright 2012, AUTHORS.txt (
 * Dual licensed under the MIT or GPL Version 2 licenses.
 * To view and modify this theme, visit,Arial,sans-serif&fwDefault=normal&fsDefault=1.1em[...SNIP...]cornerRadiusShadow=5px

Assuming that you haven’t customized your theme manually since downloading it (probably a big assumption, actually) this link in the CSS file allows you to go right back to where you started in the ThemeRoller. Simply copy that link and paste it into a browser window and the ThemeRoller will load up your custom theme just as you created it.

My guess is that this would be a bit more tenuous depending on how many versions removed you are from the current one, but I’ve had no problems today. This is also helpful if you create a theme and realize a few days later that you missed that baby blue hover color that only shows up with one of the widgets or something.

[important]I just realized that the “To view and modify this theme” link may show up in different places in the CSS file depending upon your version. Do a search – it should be there somewhere.[/important]

Referencing jQuery, jQueryUI, and SPServices from CDNs

OK, I admit it. Now that SPServices is available on a CDN, I’m coming around to thinking that CDNs might be a good idea in some cases. I had been balking at using them primarily from a control standpoint, and I’m still concerned with that aspect. When you host the script and CSS files you are using yourself, you know exactly what you’re going to get. You control the content, the naming conventions, the storage location, the uptime, everything. With CDNs, many of those things are no longer your problem, but you give up some control. I don’t think that CDNs are perfect in every situation, but they can sure be useful.

When I was working with Dan Antion and his team last week, I needed to quickly get something up and running while they were all staring at me, expecting me to perform. (They are the nicest people, but it’s still unnerving to be on the spot to write great code on demand. It seems that I managed to pull it off.) Rather than trying to go out and download jQuery, jQueryUI, and SPServices right then, I decided to quickly toss together a txt file I could easily point to in a Content Editor Web Part (CEWP).

Here’s what I came up with. Google hosts jQuery, jQueryUI, and all of the standard jQueryUI themes, and SPServices is now on cdnjs.

<!-- Reference the jQueryUI theme's stylesheet on the Google CDN. Here we're using the "Start" theme -->
<link  type="text/css" rel="stylesheet" href="" />

<!-- Reference jQuery on the Google CDN -->
<script type="text/javascript" src=""></script>
<!-- Reference jQueryUI on the Google CDN -->
<script type="text/javascript" src=""></script>
<!-- Reference SPServices on cdnjs (Cloudflare) -->
<script type="text/javascript" src=""></script>

I didn’t realize it at the time, but this txt file has become a standard part of my toolkit already. I’ve added it to three client environments just since last week. It’s the A #1 fastest way to get something up and running, even if you know you’re going to host the files locally later.

You simply add a CEWP to whatever page you want to work on, and then point the Content Link to wherever you’ve stored the txt file above. I usually use a Document Library in the root site of my Site Collection called ScriptCSS or something like that. You can, of course, just paste the contents of the txt file into your master page if your use of these tools is going to be ubiquitous.