Blog

Generations of Hope

You may or may not know, but Flo and I are in the midst of a cycle of IVF right now in our attempt to conceive and create a more compact and portable version of me (or something similar). Flo has been blogging about the process. Not every aspect of the journey is wonderful, especially for Flo – but regardless of that and regardless of the outcome weā€™re fortunate to have the chance to participate.

IVF in Alberta is not funded by the government or any health plan, and it isnā€™t cheap. Even aside from the procedure itself, the drugs Flo has been required to inject herself with are a significant expense.

Weā€™re very fortunate. We have two decent incomes and with a little cutting back here and there weā€™re able to afford treatment without any significant hardship. The drugs are covered by the healthcare plan our employer provides.

Not everyone is that lucky, and thatā€™s where Generations of Hope comes in. This registered charity does two important things: it campaigns and petitions the Alberta legislature to fund IVF treatment in the province (this would actually save the taxpayer money, not cost money), and it provides a fund offering assistance to people who are unable to afford to pay for the treatment themselves.

This evening I made a donation to the organization, and Iā€™d be delighted if youā€™d consider doing the same. I donated through ATBCares.com and as a result ATB matched 15% of my donation to an Alberta-based charity. It was also extremely easy: a couple of clicks and some credit card details were all it took.

Blog

[youtube https://www.youtube.com/watch?v=DYu_bGbZiiQ?feature=oembed&enablejsapi=1&origin=http://safe.txmblr.com&wmode=opaque&w=500&h=281]

A couple of days ago I blogged about some weird workplace etiquetteĀ surrounding phone calls that we seem to have developed into our culture where I work.

One or two people mentioned this video of what a conference call would look like in real life and I don’t think I’ve shared it before so, enjoy! Happy Friday, everyone!

Blog

Weird Workplace Etiquette

I’ve noticed some strange etiquette that seems to be plaguing my workplace.

It’s been going on for a long time, but now that I’ve explicitly noticed it it’s really starting to bother me. It’s this:

image

Every phone call seems to be preceded by an IM or an email, asking if a phone call is acceptable. If the call initiator feels that there’s going to be more than a few minutes of content, then it’s not at all unusual for them to book the call in a half hour slot on your calendar, often with conference line information included so everyone can avoid the “what’s the best number to call you at?” pre-conversation. Sometimes that meeting invite is also preceded by an IM or an email asking if it’s acceptable to set up some time.

Does this happen in every workplace, or is it some unique etiquette that’s grown into the culture of just mine?

I’ve been as guilty of this behaviour as anyone else in the past, but I’m working to stamp it out now.

Here’s the deal: if you want to call me, just call. If it turns out you’re doing so at an inopportune time and I’m busy with other things, my voicemail will give you some appropriate options. And the best number to reach me at? That would be the one that appears beside my name in the corporate directory.

What strange etiquette rules exist where you work?

Blog

SharePoint Development: Lesson 4

Welcome back to my ongoing series on SharePoint development!

I promised last week that Iā€™d follow up lesson three within a week, so here we are! In that previous lesson everything we did was in relation to setting the stage for what weā€™re going to tackle today, so Iā€™ve got no doubt that youā€™ve been waiting with barely contained anticipation to get back to writing some code.

Because all the steps from last week were fairly standard SharePoint stuff, if youā€™re pretty familiar with the platform you may well have skimmed through it. Thatā€™s fine, but for everything we do today to be successful weā€™re going to need to make sure that:

  • Weā€™ve created and populated a list of shipping prices, with different shipping profiles (in our example, these different profiles are based on destination).
  • Uploaded the SPServices library minified javascript to our ā€œwebā€ document library.
  • Located and noted the GUID of the shipping prices list, so that we can programmatically reference it in our code.

With those steps done everything is in place, so letā€™s not waste any more time!

The HTML

The HTML portion of our code hasnā€™t changed very much since we wrote it way back in lesson one, and it doesnā€™t change much today either. That being said, we do have an additional option that forms part of our calculation this time around, so weā€™ll add a form element for that.

Destination province:
Please wait, loading data...

Item weight:
lbs

Shipping cost: $0

As you can see, weā€™ve added a drop-down menu that allows for the selection of the destination province. In the HTML it has a single entry in the list that says ā€œPlease wait, loading dataā€¦ā€ As you might anticipate, weā€™re going to remove this option later on and replace it with the actual choices, but itā€™s probably good practice to have something there because the SPServices library is going to read from our list with an AJAX HTTP request ā€“ in other words the page will load first (with our ā€œplease waitā€ message), and the data to populate the list will be loaded afterwards. Hopefully it will all happen so fast that nobody ever really sees the ā€œloadingā€ message, but you never know.

The JavaScript

OK, now weā€™re really going to start getting into some changes in functionality! First things first, though. We need to include the external libraries weā€™re going to be using. jQuery has been there from the start of our journey, but SPServices is new for today.

/web/js/jquery-1.11.0.min.js
/web/js/jquery.SPServices-2014.01.min.js

The other thing Iā€™m going to do at the beginning of my main block is declare a global variable in which to store list data. There are probably better approaches than this, but for the sake of keeping my code relatively simple this is one Iā€™m taking.

var shippingData = false;

Loading Data from our SharePoint List

Next is where the SPServices magic happens. Immediately inside our jQuery document ready function weā€™re going to call SPServices and grab the data from our list, putting the result of that request inside our shippingData variable. SPServices has many available options that get passed as an object to its main function and more details can be found in the documentation on their website. Like I said though, Iā€™m keeping things simple:

$().SPServices({
   operation: 'GetListItems',
   listName: '{4883AC18-E2A5-4EAF-8446-23B15B43861A}',
   completefunc: function(xData, Status) {
      if (Status == 'success' && ($(xData.responseXML).find('ErrorCode').text() == '0x00000000' || $(xData.responseXML).find('ErrorCode').text() == '')) {
         shippingData = $(xData.responseXML).SPFilterNode('z:row');
         populateDropdown();
      } else alert('Something went wrong!');
   }
});

Not bad, eh? Ten lines of code and weā€™ve read all the data from our SharePoint list. Letā€™s look at what weā€™ve done in a bit more detail.

The code weā€™ve written can be summarized as:

$().SPServices(obj);

All weā€™re doing is calling the SPServices plugin and passing in a javascript object that contains all the options it needs to understand what we want it to do. There are many options we could pass to it, and youā€™ll find more detailed documentation on the SPServices homepage. Iā€™ve kept things as simple as possible and passed in the bare minimum.

Operation: ā€˜GetListItemsā€™

In our example weā€™re dealing with items in a list. GetListItems is the operation we need to read data from a SharePoint list into our webapp. There are many other types of operation related to lists that SPServices could do for us ā€“ creating entirely new lists, adding or removing list fields, deleting lists, etc. Essentially almost anything you could do manually on SharePoint could be done programmatically with SPServices. If we wanted to write data back to a list then UpdateListItems would be the operation weā€™d use.

ListName: '{4883AC18-E2A5-4EAF-8446-23B15B43861A}'

The ListName parameter could take one of several formats. A simple string containing the name of the list will work, but to avoid any kind of confusion between similarly named lists my preference is to pass in the GUID of the list. Remember that the GUID of your list will be different to mine. SPServices can also take a WebURL parameter that tells it which site in your SharePoint collection the list can be found on, but since weā€™re using a GUID thatā€™s unique across all sites in the collection we donā€™t need that.

completefunc:Ā  function(xData, Status)

This is where the real magic happens. The completefunc parameter represents a callback function that SPServices executes once data has been loaded, and it takes two parameters: xData and Status.

Our completefunc does some basic error handling, and then calls another function to do the dirty work.

if (Status == 'success' && ($(xData.responseXML).find('ErrorCode').text() == '0x00000000' || $(xData.responseXML).find('ErrorCode').text() == ''))ā€¦

For the Status parameter thatā€™s passed in to completefunc, weā€™re looking for it to contain a value of ā€˜successā€™. We have to be a little careful about exactly what this means though: To SPServices success means that itā€™s passed a query to SharePoint and received a response. It doesnā€™t mean that our query was well formed, or that we received any useful data back. Basically youā€™ll always get a successful status unless SharePoint is down ā€“ in which case our webapp probably wouldnā€™t be available to users anyway.

To check that our query has truly been executed successfully by SharePoint, we look in the responseXML for an error code. Depending on the version of SharePoint weā€™re running, that will either be 0x00000000 or blank.

shippingData = $(xData.responseXML).SPFilterNode('z:row');

There are few ways we could approach what happens next. My goal was to keep my code as simple as possible so Iā€™m doing some things that may not be best practice. This is one of them: we take the data SPServices has returned and put it into a global variable.

The data SharePoint has passed back to us is in XML format and contains a wealth of information about our query, metadata about the response, and so on. We donā€™t really need any of this stuff ā€“ we just want the data itself ā€“ so SPServices has a function called SPFIlterNode that helps us filter the returned data down to what we actually care about. Weā€™re filtering here by z:row. Each z:row returned represents one entry from our SharePoint list.

populateDropdown();

Now that we have our data in a globally accessible variable, Iā€™m outsourcing the processing of it to another function: populateDropdown. That last step for our completefunc is to call this function.

Populating the Dropdown List

OK! So now we have the data we need loaded from our SharePoint list and resident in memory (in our shippingData global variable) so that we can manipulate it and our users can interact with it. The first step of this process is to populate the relevant options into the select box we created in our HTML. Iā€™m doing that (surprise surprise) with the populateDropdown function.

function populateDropdown() {
   $('select#destination option').remove();

   for (i = 0; i ' + $(shippingData[i]).attr('ows_Title') + '');
   }
}

If you recall, the dropdown list initially contains a single option with the text Please wait, loading dataā€¦. At this point in the story our data is loaded, so letā€™s get rid of that option first:

$('select#destination option').remove();

Done! Good. The next step is to loop through each of the items weā€™ve loaded into our shippingData variable, and add them as an option in the dropdown. We do this with a standard for loop:

for (i = 0; i 

If youā€™re not familiar, this construct sets a variable i to zero, then loops through the following block of code multiple times, as long as i is less than shippingData.length, which is the number of items in our shippingData variable. On each iteration i is incremented by one (i++).

On each loop we add an item to our dropdown, using jQuery to append the relevant HTML. Based on the data that exists within our SharePoint list, we end up with these options in our dropdown:

Each $(shippingData[n]) has an attribute for each of the columns in our list. These attributes all have the prefix ows_, and, as mentioned in lesson 3, they are all referenced by the original name of that column (even if itā€™s been renamed since it was created). Thatā€™s why weā€™re using the attribute ows_Title to get at the data thatā€™s in our Province column: the column was called Title when the list was created, and we renamed it.

Performing the Calculation

With any luck everything in our story up to this point will have happened in a split second, but regardless weā€™re now ready for user input. The user selects the destination province, inputs the weight of the item being shipped, and hits the calculate button.

The calculation itself is really no different from the one we built in lesson 1, the difference being that our variables are defined by the list data rather than hardcoded in.

We still identify that the Calculate button has been pressed through the use of the jQuery $(ā€˜input#calculateā€™).click(function() {});, but our first step is now to set some variables based on whatever is selected in the destination province dropdown at the time.

bp = parseFloat($(shippingData[$('select#destination').val()]).attr('ows_BasePrice'));
bw = parseInt($(shippingData[$('select#destination').val()]).attr('ows_BaseWeight'));
ap = parseFloat($(shippingData[$('select#destination').val()]).attr('ows_AdditionalPrice'));
aw = parseInt($(shippingData[$('select#destination').val()]).attr('ows_AdditionalWeight'));

We set each of these variables by reading the relevant attribute (representing the column in our SharePoint list) from $(shippingData[n]), where n is the value of the destination dropdown, $('select#destinationā€™).val(). After that, itā€™s business as usual:

var shippingcost = bp;

if ($('input#itemweight').val() > bw) {
   shippingcost += (Math.ceil(($('input#itemweight').val() - bw) / aw) * ap);
}

$('span#shippingcost').html(shippingcost);

Putting it All Together

And weā€™re done! The completed code block ā€“ including all the javascript and HTML ā€“ that we copy and paste into our content editor webpart is as follows:

/web/js/jquery-1.11.0.min.js
/web/js/jquery.SPServices-2014.01.min.js

   var shippingData = false;

   $(document).ready(function() {
      $().SPServices({
         operation: 'GetListItems',
         listName: '{4883AC18-E2A5-4EAF-8446-23B15B43861A}',
         completefunc: function(xData, Status) {
            if (Status == 'success' && ($(xData.responseXML).find('ErrorCode').text() == '0x00000000' || $(xData.responseXML).find('ErrorCode').text() == '')) {
               shippingData = $(xData.responseXML).SPFilterNode('z:row');
               populateDropdown();
            } else alert('Something went wrong!');
         }
      });

      $('input#calculate').click(function() {
         bp = parseFloat($(shippingData[$('select#destination').val()]).attr('ows_BasePrice'));
         bw = parseInt($(shippingData[$('select#destination').val()]).attr('ows_BaseWeight'));
         ap = parseFloat($(shippingData[$('select#destination').val()]).attr('ows_AdditionalPrice'));
         aw = parseInt($(shippingData[$('select#destination').val()]).attr('ows_AdditionalWeight'));

         var shippingcost = bp;

         if ($('input#itemweight').val() > bw) {
            shippingcost += (Math.ceil(($('input#itemweight').val() - bw) / aw) * ap);
         }

         $('span#shippingcost').html(shippingcost);
      });
   });

   function populateDropdown() {
      $('select#destination option').remove();

      for (i = 0; i ' + $(shippingData[i]).attr('ows_Title') + '');
      }
   }


Destination province:
Please wait, loading data...

Item weight:
lbs

Shipping cost: $0

Taking it Further

The next steps with our shipping calculator app would be to add some additional error-checking and handling, and maybe amend the code to avoid using unnecessary global variables. Iā€™ve kept things as simple as possible here for the sake of example.

After that? As I mentioned earlier, thereā€™s a lot of cool stuff we can do with SPServices. Where you go from here is really up to you, but hopefully you can see some possibilities. Even with the basic building blocks of reading from and writing to lists, itā€™s possible to build some really cool stuff on top of SharePoint, possibly even taking the approach of using SharePoint as a database for a webapp that has its own look and feel.

Enjoy!

Blog

ā€‹What It’s Like When Your Job Actually Treats You Like an Adult

ā€‹What It’s Like When Your Job Actually Treats You Like an Adult

Blog

SharePoint Development: Lesson 3

Welcome back to my continuing series on SharePoint development!

If youā€™ve been following along with lesson one and lesson two then this post has probably been a long time coming, but weā€™re now at the point where weā€™ve built a pretty useful tool for calculating shipping costs, and weā€™ve integrated it into our existing SharePoint site to make it easily accessible to everyone in our team who might benefit from it.

Hereā€™s the thing, though. If your organization is anything like mine, then SharePoint is a tool that theyā€™ve made available to everybody. Youā€™re using it for some cool stuff, but writing code probably isnā€™t your day job ā€“ youā€™re the techy guy or gal in your group whoā€™s found an opportunity to make everybodyā€™s life a little easier with technology, and the beautiful part is that you can do it all without needing to engage your companyā€™s IT team (who are busy with large-scale projects involving a contribution to your companyā€™s bottom line, which your idea for a shipping calculator would need to be prioritized against).

Thereā€™s nothing wrong with any of that. Something like this really shouldnā€™t be a thing that your companyā€™s IT team get involved with in the exact same way that helping you craft an especially complex excel formula shouldnā€™t be a job for them either. If youā€™ve ever crafted an especially complex excel formula in a workbook thatā€™s shared throughout your group though then you may already have identified the downside to this approach: things change.

Our tool is built on a fixed model for calculating shipping costs of $19.99 for the first 20lbs and $3 for every 5lbs (or part thereof) over and above that. That rule is embedded within your code now, youā€™re the only one around with the necessary technical knowledge to update it when shipping costs change, and you have a day job to worry about too. If updating SharePoint tools is not how you like to spend your weekends, then we need a different approach.

What we need, then, is a solution where the average SharePoint user can make changes to key pieces of data, and our tool needs to be smart enough to read that data so that it can be used in calculations. And, while weā€™re at it, letā€™s expand the tool so that it can handle a few different shipping profiles (which could represent different couriers or, in our example, destinations).

Enter the SPServices library. SPServices is a jQuery plugin thatā€™s used to expose SharePoint data to our jQuery apps, including (amongst other functions) reading from and writing to SharePoint lists in SharePoint 2007, 2010 and 2013.

This is a significant step up from where we were at the end of lesson two (which is probably why Iā€™ve been procrastinating over writing it for so many weeks). Iā€™ve split it into parts. Today weā€™re going to set the stage and prepare our data, and this time next week (I promise!) weā€™re going to get our hands dirty with some code.

Nevertheless, both this post and its successor are probably going to be longer than those that have gone before, so be forewarned, go grab yourself a cup of coffee, and letā€™s dive in!

Creating the List

First things first, we need a list to hold our data. This list is where our less-technical colleagues will come when changes need to be made and weā€™ll keep it fairly straightforward.

Much like we did to create our document library in lesson one, go to Site Actions > View All Site Content and hit the Create button. This time weā€™re going to choose Custom List as the type of entity weā€™re going to create. We need to give the list a name, so letā€™s call it ā€œShipping Prices.ā€ For the time being weā€™ll leave the description blank, and weā€™ll hide our list from the Quick Launch bar. We can always change these options later.

image

When you hit the Create button the list will be created and will have a single column (ā€œTitleā€). We need to add a few more columns, so choose List Settings from the toolbar or the Actions menu (depending on your version of SharePoint). The first thing weā€™re going to do is rename the ā€œTitleā€ column to ā€œProvinceā€ by clicking it in the list, then weā€™re going to add four more columns by clicking the Create Column link and adding them one by one. Hereā€™s where we want to end up:

image

An Important Note Regarding Column Names

With this the basic framework for our data is in place. You may notice that none of our column names have spaces in them. Thatā€™s because SharePoint in the backend does strange things with spaces. As youā€™ll see later we can programmatically read from a column called ā€œBasePriceā€ by referring to it exactly in that way, whereas a column called ā€œBase Priceā€ would need to be referred to in our code as ā€œBase_x0020_Price.ā€

That being said, we can leverage a bit of trick here if want to improve readability for people who will interact with this list directly (our less-technical colleagues, remember). Behind the scenes (and in our code) SharePoint will always know the column by its original name, even if itā€™s subsequently been renamed. If we go back and spaces now, the internal name of the ā€œBasePriceā€ column will remain ā€œBasePrice,ā€ even if its display name is changed to ā€œBase Price.ā€

This is helpful in this scenario, but can easily be a bit of a gotcha ā€“ you need to remember the original name of all your columns, because thatā€™s how your code will reference them. Remember the ā€œTitleā€ column we renamed to ā€œProvince?ā€ Itā€™s still ā€œTitleā€ behind the scenes.

Populating the Data

There are many ways to get data into a SharePoint list, and Iā€™m not going to go into a great amount of detail here. You can add each item row by row with the built-in list forms, you can use SharePointā€™s datasheet view to edit many rows at once, or you can use a third party tool. Our example is probably a little basic to warrant breaking out a special third-party tool for, but nevertheless as you do more complex stuff in the future Iā€™m a fan of SharePoint List Item Editor. It does exactly what its name suggests, gives you a spreadsheet-like interface for editing items in SharePoint lists, and makes it easy to copy and paste many rows at once.

Regardless of how we do it, hereā€™s the data Iā€™m going to put into my list for the purposes of this example.

image

With this data in place youā€™re probably starting to get a sense of where things are going with this example. The BasePrice is the cost of shipping the first BaseWeight pounds, and the AdditionalPrice is the cost of each AdditionalWeight pounds or part thereof.

In many ways itā€™s no different from what weā€™d created by the end of lesson two, but with one critical difference ā€“ none of these variables are going to live in our code anymore. Theyā€™re all factored out into the list where theyā€™re easily editable when things need adjusting in the future.

image

Find The GUID of the List

Everything weā€™ve done so far is fairly standard SharePointy stuff, but youā€™ll notice weā€™ve had one eye on the end goal of programmatically interfacing with this data throughout. Finding the GUID of the list weā€™ve created is an important step in this process.

A GUID is a globally unique identifier, and every SharePoint list (or calendar, or document library, etc) on our SharePoint site collection has one. There are several ways we can connect our front-end custom interface to our back-end data, but the GUID is probably the most reliable because as the name implies, itā€™s globally unique. Itā€™s also not affected if our list gets renamed later.

There are several ways to find it, but my favourite is to use a simple tool I found for the purpose. Open the app and plug in the URL of your SharePoint site. Hit the Display List Titles and IDs button, and grab the relevant ID (including the opening and closing braces).

image

For me {4883AC18-E2A5-4EAF-8446-23B15B43861A} is what I need. For you it will be different. You may notice that the tool can also find the GUID of a list view. We donā€™t need this because weā€™re going to use the default view. Iā€™m not going to get into it right now, but if youā€™re unfamiliar SharePoint views define things like the sort order and filter thatā€™s applied to a list, and each list can have multiple views defined. If you want to programmatically access data thatā€™s filtered out of your default view then the simplest method is probably to create a new, unfiltered, public view and reference it by its GUID in your code. The documentation for SPServices will tell you more.

ā€¦and Talking of SPServices

Now is probably a good time to download the library and place the minified javascript file in the ā€œwebā€ document library we created in lesson one, in the ā€œjsā€ subfolder alongside the jQuery library thatā€™s already there. At the time of writing this file is called jquery.SPServices-2014.01.min.js.Ā With that our stage is set and weā€™re ready to rewrite the code in our content editor web part to interface with it, but that was a lot to take in so weā€™ll get to that next week.