Microsoft Cloud Show Episode 016 – Interview with Marc Anderson on Recent Changes Impacting Customers on Office 365


Microsoft Cloud Show

A few weeks back, I sat down (virtually, of course) with Andrew Connell (@AndrewConnell) and Chris Johnson (@LoungeFlyZ) to record an episode of the Microsoft Cloud Show. Andrew was in Florida, I was in Boston, and Chris was way around the world in New Zealand. Ah, the wonders of modern technology.

The only place to stay up to date on everything going on in the Microsoft cloud world including Azure and Office 365.

Whether you are new to the cloud, old hat or just starting to consider what the cloud can do for you this podshow is the place to find all the latest and greatest news and information on what’s going on in the cloud universe.  Join long time Microsoft aficionados and SharePoint experts Andrew Connell and Chris Johnson as they dissect the noise and distill it down, read between the lines and offer expert opinion on what is really going on.  Just the information … no marketing … no BS, just two dudes telling you how they see it.

I was honored to be the very first guest on the show, which already had 15 excellent episodes in the can.

In Episode 016 – Interview with Marc Anderson on Recent Changes Impacting Customers on Office 365, we talked about a number of extremely important things that have been going on with Office365 lately.

I had done a post about one issue that has caused me and users of SPServices the most consternation, Office 365 Update Changes ‘Display Name’ on Required Fields and Andrew had posted about a few others one his blog in Office 365 Needs to Treat the UX as an API if Our Customizations are to Stay Off the Server.

Last week, I released SPServices 2014.01, which addresses the title changes (adding ” Required Field” to the title attribute of some required dropdowns), but there’s a bigger set of issues at play here, as Andrew alludes to in his post.

In the podcast, we talked about the impact of these changes as well as the mindset behind them from the Microsoft side.

If you do any client side development with SharePoint – and that’s where everyone is headed – you owe it to yourself to listen to the podcast. You’ll understand more about what changes to the DOM might mean for you as a developer, or even what might happen to you as a user of customizations that rely on the DOM being stable and predictable.

One things seems certain: we’ll see more changes like the ones we discussed in the podcast and they will have an impact on everyone, not just people replying on Office365. (The same issues started to crop up for people who have applied the December 2013 Cumulative Update (CU) for SharePoint 2010 on premises.)

I want to thank Chris and Andrew for inviting me in for a chat. Assuming I didn’t annoy them too much with my scatological terminology, maybe I’ll be able to visit with them again the next time a round of changes like this pop up and cause ripples in the SharePoint time-space continuum.

Using Jaap Vossers’ InstantListFilter with a Data View Web Part (DVWP)

On a recent client project, I was able to take advantage of Jaap Vossers‘ excellent InstantListFilter project on Codeplex. It’s just the sort of thing that you need to improve the user experience with SharePoint, and you can do it with minimal work because Jaap’s done all of the heavy lifting for you. It’s a jQuery-based solution, too, so it runs entirely client-side and you can adapt it to your heart’s content.

I’ve stolen Jaap’s animation to show you how the InstantListFilter works. The idea is to give the user a better option for filtering  than the standard column headers in a List View Web Part (LVWP) -based view. As you can see in the animation, whenver the user types characters in the input boxes at the top of each column, the list items are instantly filtered based on that value.

Click on the image to see the animation in a new window

While the code is quite elegant, it will only work with content that is in the page (not with paged content). This is because it is simply changing what the user sees in the Document Object model (DOM) based on what is typed.

In my case, I wanted to use the capability with a Data View Web Part (DVWP) rather than a LVWP. The key tweak to make it work with a DVWP is highlighted below. I could have generalized this further, of course, but what I did was change the selector to match the id of the div containing the DVWP in my specific page. I also added some CSS of my own and did a few other tweaks, but making it work with the DVWP was the change I wanted to highlight here.

// This function is adapted from Jaap Vossers' excellent InstantListFilter <a href=""></a>
function addFilters() {

 jQuery.extend(jQuery.expr[':'], {
  containsIgnoreCase: function(a,i,m) {return (a.textContent||a.innerText||jQuery(a).text()||'').toLowerCase().indexOf((m[3]||'').toLowerCase())>=0}

 $("div#WebPartWPQ2 tr:first").each(function() {
  if($("", this).size() > 0) {
  var tdset = "";
  var colIndex = 0;
  $(this).children("th,td").each(function() {
   if($(this).hasClass("ms-vh-icon")) {
    // attachment
    tdset += "<td></td>";
   } else {
    // filterable
    tdset += "<td><input type='text' class='myappFilterField' filtercolindex='" + colIndex + "' /></td>";    
  var tr = "<tr class='myapp-filterrow'>" + tdset + "</tr>";
  .keyup(function() {

// Do the column filtering
function filterColumn(obj) {

 var inputClosure = obj;
 if(window.myappFilterTimeoutHandle) {
 window.myappFilterTimeoutHandle = setTimeout(function() {
  var filterValues = new Array();
  // Gather up the filter values and check to see if they are all empty (so that we can display everything)
  var notEmptyCount = 0;
  $("input.myappFilterField", $(inputClosure).parents("tr:first")).each(function() {    
   if($(this).val() != "") {
    filterValues[$(this).attr("filtercolindex")] = $(this).val();
    notEmptyCount ++;

  if(notEmptyCount == 0) {
   // If all of the filters are empty, then show everything
  } else {
   // Otherwise, do the filtering
   $(inputClosure).parents("tr.myapp-filterrow").nextAll("tr").each(function() {
    var thisMatches = false;
    $(this).children("td").each(function(colIndex) {
     if(filterValues[colIndex]) {
      var val = filterValues[colIndex];
      // replace double quote character with 2 instances of itself
      val = val.replace(/"/g, String.fromCharCode(34) + String.fromCharCode(34));       
      var valArray = val.split(",");
      for(var i=0; i < valArray.length; i++) {
       if($(this).is(":containsIgnoreCase('" + valArray[i] + "')")) {
        thisMatches = true;
        return false;
    if(thisMatches) {
    } else {
 }, 250);

function showAllRows() {

Breaking .NET Habits When You Write Script

There’s a long thread over at‘s Stump the Panel where I’m trying to help someone to set up some jQuery to do some calculations in the form to check if the values are valid. The person (handles don’t always give away gender!) is struggling (IMHO) with the difference between server-side and client-side code. There’s been a lot of back and forth, but here’s some of the latest exchange, as I think it may be helpful to others.

Where we are at the moment is figuring out where the script should go in the aspx page and how to select, or find, the right values in the rendered page.

They have said that they are “Placing [the script] in the ASP: Content section”. There are lots of asp:content sections, and which one you choose can have an impact on how and when your script runs (or doesn’t run). I generally put my script right below the line:

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">

This is the most reliable place to put the script in my experience. You can also place the script in a Content Editor Web Part (CEWP).

The person has posted the snippet of code below and asked which of the values shown is the DisplayName.

  <td width="190px" valign="top">
      <nobr>Deal 5 Allocation</nobr>
  <td width="400px" valign="top">
    <SharePoint:FormField runat="server" id="ff41{$Pos}" ControlMode="Edit" FieldName="Deal_x0020_5_x0020_Allocation" __designer:bind="{ddwrt:DataBind('u',concat('ff41',$Pos),'Value','ValueChanged','ID',ddwrt:EscapeDelims(string(@ID)),'@Deal_x0020_5_x0020_Allocation')}"/>
    <SharePoint:FieldDescription runat="server" id="ff41description{$Pos}" FieldName="Deal_x0020_5_x0020_Allocation" ControlMode="Edit"/>

The problem is that this is the server-side code. The SharePoint:FormField will be rendered as HTML by SharePoint, so looking at the page server-side while the script is running client-side really doesn’t work. As I point out to folks a *lot*, you really need to get used to using the Developer Tools or Firebug or something to look at the Document Object Model (DOM) client-side to understand what is rendered rather than what controls are in the page server-side.

This is what the person keeps trying to do:

$("input[Title='ff41{$Pos}']").blur(function () {
  // whatever else you want to do... (blank out the column value, turn it red, whatever)

This won’t work, because the Title is never going to equal ‘ff41{$Pos}’ client-side. At the very least, the {$Pos} will be evaluated to the current row position, so the id will look like ‘ff411’. Instead it should be:

$("input[Title='Column 1']").blur(function () {
  // whatever else you want to do... (blank out the column value, turn it red, whatever)

The selector $(“input[Title=’Column 1′]”) says “find me an input element which has its Title attribute set to the string ‘Column 1′”. So you need to look at the input element in the DOM to see what the Title attribute contains. SharePoint always sets the Title to the DisplayName of the column for input elements, so if your column is called ‘Deal 5 Allocation’, that’s the DisplayName. ‘Deal_x0020_5_x0020_Allocation’ is the internal name, also called the StaticName. Note that the StaticName never changes after you create the column even if you change the DisplayName repeatedly.

Hope this is useful to folks out there!

Why Use DOM Manipulation Over Custom Code?

Every once in a while, I write a fairly long response to a question in one of my USPJ Academy courses that just feels like a blog post. Here’s another one of those.

We’ve been discussing why you would choose to use DOM manipulation over custom .NET programming. Here’s one of my replies in the thread. It’s a little out of context, of course, but the points are still valid.

  • jQuery/JavaScript is equally available to a .NET programmer. If you write a custom Web Part, for example, you can embed script to give it client side behaviors, including Web Services calls to avoid postbacks. This just doesn’t seem to be a common line of thinking in .NET programming, where the tendency is to want to have everything happen on the server. (I believe that there are many historical reasons for this, including Microsoft’s late focus on the Web, but that’s another whole long blog post!)
  • As I discuss in my Middle Tier Manifesto, bad programming is bad programming. If you’ve hired contract .NET programmers and ended up with unsupportable code, then you’ve hired bad .NET programmers. Client side code is no different than any other code. It should be well organized, well documented, and well tested.
  • Client side functionality absolutely is not the answer to everything. Much functionality is best placed server side. It’s a set of tools, not the whole toolbox.