SharePoint Designer 2013′s Missing Design View – More Thoughts

I’ve written previously about SharePoint Designer 2013′s Missing Design View here on my blog as well as on the Microsoft forums and elsewhere.. My goal in writing about this and making a lot of noise about it is not to simply complain. (We have way more complaining about everything out here on the InterWebz than we already need.) People need to understand what not having the Design or Split View in SharePoint Designer means if they upgrade to 2013 so that they can make good decisions.

At this point, I’m going to be going with the assumption that the net-net  answer is “hire more developers”. (Note: Assumption)

If the Code View is the only available view in SharePoint Designer, and existing functionality has been implemented with XSL-driven Web Parts, such as Content Query Web Parts (CQWPs) and Data View Web Parts (DVWPs), then there are two main options:

  1. Maintain the DVWP in Code View, which requires an XSL able developer. This is not at all easy. The XSL that SharePoint Designer generates – it is essentially playing a code generator role here – is horrible. There are some reasons for this that are legitimate: in order to be prepared for that next button you click on to change what you want to display in a DVWP, SharePoint Designer includes all sorts of stubs in its XSL For years, I’ve simply thrown away most of the SharePoint Designer -generated XSL and written my own because of this. However, altering existing DVWPs that have been implemented by power users become a development task going forward with 2013 even if a developer wasn’t needed before. It’ll have to be direct customization of the XSL in the Code View.
  2. Rearchitect the solution to use client-side processing. This is where Microsoft is clearly heading. The client-side push that started in SharePoint 2010 continues in 2013. Microsoft has expanded the Client Side Object Model (CSOM) and the REST Services. In many cases, the exact same functionality we have used DVWPs to build can be built with this new paradigm, but there will, of course, be cases where we have to make some trade-offs. Regardless, it becomes a developer task, as I can’t see many power users choosing to learn scripting.

If you follow me at all, you know that I love using client-side processing.with SharePoint to greatly improve the user experience (UX). The tools of the trade here are CSS, JavaScript and the many things that people have built to provide extended functionality, like jQuery, SPServices, and so many libraries, plugins, and add-ons it’s impossible to count. This is a great thing for SharePoint. As I’ve been saying for years now, it opens up SharePoint development to herds of new people who already have those Web development skills

But I also see a huge downside to this rush to client-siide development. The reason I coined the term “SharePoint’s Middle Tier” (OK, OK, I know most people hate the name – I can’t say it without the disclaimer) is that we do processing on the server *and* the client. We choose what makes the most sense in load distribution and put each chunk in the right place. Using a DVWP to do the heavy lifting of getting the initial load of data onto the page often covers a high percentage of use cases. Then we layer script (the other code) onto the page to provide behaviors and interactivity with the data without postbacks. By pushing for client-side processing exclusively, we lose that capability to architect well-balanced solutions (without cracking open Visual Studio – which Microsoft has started to discourage).

The biggest issue here is that we go from minimal error assistance – which is only shown in the Design or Split Views – to zero error assistance. Even a well-trained XSL developer or an XSL monkee like me will get zero error messages other than the essentially useless

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.

error message in the browser and have to figure out what error we’ve introduced by feel.

Design and Split View for most of us who do this kind of work has nothing to do with “design”. The argument that SharePoint 2013’s new Design Manager allows us to design with something like Dreamweaver is somewhat specious. Instead, we use SharePoint Designer to develop real solutions using markup, DVWPs, script, etc. The Design View is where SharePoint Designer shows us what is going on. When I intentionally created a error in a DVWP to get the text for the error above, SharePoint Designer was telling me “This Web Part does not have a valid XSLT stylesheet: Error: A name was started with an invalid character. <<< “. That’s useful – I had added a couple extra < signs and it told me that I had. We totally lose that with no Design or Split View. The upshot of this is that there will be no reasonable way to build this type of solution or maintain existing ones. QED

Thus, we end up at option 2, which is a rearchitecting all the existing solutions which rely on development using the Design or Split Views. IT shops have used these methods as much as power users, at least at my clients, so it is my firm belief that this issue is going to be big and pervasive.

So, what’s the upshot of all of this? Well, if you plan to upgrade to SharePoint 2013 and have used the development methods I talk about here, then keep your eyes open to the level of effort it may require. Do a very careful inventory of solutions that you already have in place that were built using SharePoint Designer and think about what you will do with them in 2013. It’s not hopeless, but it’s going to be a lot of work.

Error Deleting a Content Type – “The content type is in use”

Are you as annoyed by this “The content type is in use” error as I am?

Error Deleting a Content Type

Error messages like this that don’t give you a way to solve the problem are a sign of the devil to me. That Correlation ID does us no good (try to find the administrator in a large organization to help you out in a timely way) and there’s no good way to find out where the Content Type is in use.

In many cases the Content Type may be in use with real content. However, in the instance where you are prototyping something and delete the list where you were using the Content Type, you know that it’s not in use anymore, right?

Well, it’s still in use, actually, but only sort of. When you delete the list, it goes into the Site Recycle Bin, so it actually still exists. It’s a great safety feature, but in this case, it’s getting in our way.

You need to delete that list from the Site Recycle Bin as well as the Site Collection Recycle Bin. The former is easy: you deleted the list so you have permission to delete it from the Site Recycle Bin.

Site Recycle Bin

The latter is only available to you if you are a Site Collection Admniistrator, so you may need to find someone who has that permission to help you out.

Site Collection Recycle BinOnce you’ve deleted the list from both Recycle Bins, you’ll be able to delete that pesky Content Type. Of course, you can also wait the requisite 60 days until the list is deleted from the Site Collection Recycle Bin automatically (by default – your settings may vary), but who will remember that far into the future? And we all know that a clean Site Collection is a good Site Collection.

Generic Error Handling in SPServices

Recently, I got this question in the SPServices Discussions:

I’m new to SPServices, and I was wondering if it is possible to define some kind of out-of-the-box error handling procedure, like this:

$().SPServices ({
operation: "DoSomething",
[option1: value1],
[option2: value2],
    // ...
success: function (xData) {
        alert ("The operation has been completed!");
        // some processing code ...
    },
fail: function (jqXHR) {
        alert ("Something went wrong!");
        // some fallback code ....
    }
});

The only thing I am aware of is that you can do something like this:

completefunc: function (xData, Status) {
    if (Status == "Success") {
        alert ("The operation has been completed!");
    } else {
        alert ("Something went wrong!");
    }
}

However, this solution will also execute the success-branch when the server returns an XML-document containing error messages. Above that, I don’t think it’s that elegant because you would have to check the Status == “Success” every time you define a new request, which looks a little bit like overkill.

Any suggestions?

By the way: really love this project!

I was on vacation with only my iPhone (my first laptop-free vacation in probably 10 years!) so I waited until I returned to answer. The question is similar to many others I’ve received since I started working on SPServices.

Oh, I’d love to add something like this! Unfortunately, it’s not that simple.

There are two main layers where an error can occur:

  1. In the AJAX call itself. This really only occurs if the endpoint (SharePoint) isn’t responding, almost always due to the servers being down. SOAP may be an old, crufty standard, but it’s damn reliable.
  2. In the Web Service itself. Unfortunately there is almost zero consistency in the implementations. No two operations respond in quite the same way, and there’s really very little in common across the Web Services. Some operations return only one error message regardless what you’ve done wrong, and others return 5 or 6, but inconsistently. Some responses contain heavily nested XML while others contain a single element with many attributes. The only real commonality is that they return XML.

In all of my use of SPServices, I’ve found a few truths.

  1. SharePoint always responds if it’s up and running.
  2. The only time a Web Service call fails is if you pass it bad data or poorly formed XML.
  3. If you get a valid response, then the operation succeeded.

Early on I decided that my job in SPServices is to reduce the likelihood of 2. By eliminating the need to construct the SOAP envelopes, SOAP headers, etc., a huge number of errors simply never happen. It’s up to you to test the XML coming back to see if it contains what you expect.

While I could add error handling for some of the core operations, I would have to assume quite a few things about what you are doing. For instance, you might be calling GetListItems specifically to see if you get zero items back, and that might be a success to you.

What I *have* done is to add the debug mode to many of the “value-added” functions. Because I know what ought to be coming back when I make calls to the various Web Services, I can reasonably provide some error messages that are useful for you to use in setting things up. Things like this debug message:

SPCascadeDropdowns Debug Message Example
Which brings me to another important point: what should we do when there is an error? I’ve vowed to myself never to write an error message like “An error has occurred. Please contact your administrator.” (What error? Is it important? Do I need to do something to fix it? Who’s my administrator? How do I contact them? What do I tell them?) Even something with a correlation ID which can only be deciphered by an administrator is too obtuse. It’s the user who needs to know what to do if there’s a problem.

Given the myriad ways people use SPServices, I can’t possibly predict what they are building or how it should behave. It is first a toolkit and second a power user tool. The core of SPServices should give a developer lean tools that can use how they see fit. Generic error handling isn’t going to help them much because some of the edge conditions are good in some cases and bad in others. In the value-added functions, I intend the debug mode to help power users to get things set up, and then things should be humming and they should turn it off.

But what do we tell the user if there’s a problem? “I couldn’t write that item. Please try again”? Remember that the SOAP Web Services are *extremely* reliable. I can’t even recall an instance where I’ve seen a call to an operation fail when it’s passed good data and the servers are awake. We can assume that calls are going to work.

What do you think about all of this? How would you suggest I improve SPServices error handling?

SPServices v0.7.2 Countdown, Updates, and Futures

Inukshuk near Golden, BC, CanadaHello, all! I was away on a fantastic trip to Western Canada.I posted BETA1 before I left and there have already been over 500 downloads. I’m back and ready to push out the v0.7.2 release of SPServices as soon as I work through the feedback I received while I was gone.

I haven’t seen any significant issues except that I heard that SPServices wouldn’t work with jQuery 1.8.x. As usual, the jQuery team made some subtle changes – no doubt improving the library overall – that had an impact on SPServices. Luckily, this one was a pretty easy fix (for those of you interested in details, here’s the issue in the Issue Tracker), and it seems to work just fine with the earlier versions of jQuery I’ve tested as well. Of course, I’m just one guy, so any testing that you can do with the BETA2 that I posted last week would be great for the SPServices community. If there’s one thing I’d ask of anyone who uses SPServices extensively, it’s help in testing new versions.

Another thing I wanted to comment on was a question from Paul Tavares (@paul_tavares) due to a comment I made in the SPServices Discussions.

[notice]By the way, the Discussions is the right place to start any threads on SPServices, NOT the Documentation pages. Codeplex doesn’t give me any good way to track comments on the Documentation, so odds are I’m going to miss your question or comments – there are a lot of documentation pages and I can’t check them all regularly. Also, starting with an item in the Issue Tracker is often not the best thing because code posted there cannot be formatted.[/notice]

Microsoft has officially said that the ASP.NET (SOAP) Web Services have been deprecated in SharePoint 2013 – thanks to Rene Modery (@modery) for the link.

Two API sets are still supported in the SharePoint 2013 Preview framework for backward compatibility, but we recommend that you not use them for new projects: the ASP.NET (asmx) web services, and direct Remote Procedure Calls (RPC) calls to the owssvr.dll file.

So while the SOAP Web Services are deprecated, they still exist in SharePoint 2013, though they will go away sometime in the future. However, that future could be quite a way off (2016? 2019?) because earlier versions of Office rely on the SOAP Web Services to interact with SharePoint. The Microsoft replacement to SOAP is the REST interface, along with the Client Side Object Model (CSOM). In SharePoint 2010, the coverage of functionality in those two options is limited, however. In 2013, they have been significantly extended, but I haven’t yet seen (or done) a side-by-side comparison with SPServices and REST and CSOM in SharePoint 2013. I believe that the SOAP Web Services will still have better coverage in SharePoint 2013.

All that said, I believe there’s still a “long tail” for SPServices, at the very least. People are still using SharePoint 2007 and 2010 and will be for a long time. This is certainly true of my client base, as well as in the wilds, based on my conversations at conferences. Upgrades are very expensive – hardware, licensing, but most importantly time – and many organizations are making damn good use of the existing versions of SharePoint.

This means that SPServices isn’t going to become useless anytime soon. I’m going to continue maintaining it and extending it. I still see it as an extremely viable development tool for SharePoint. One of its best qualities is that it works as you move from SharePoint 2010 to SharePoint 2010 and now SharePoint 2013. You may need to tweak your code, but you won’t need to rewrite it. None of Microsoft’s client side tools can do that for you!

Stay tuned for more updates about the release, and let me know if you have any issues or feedback.

SPServices v0.7.2 is Almost Ready for Beta

It’s been a bit too long since I’ve released a new version of SPServices. It was mid-February when I released v0.7.1, and I’ve been adding new functionality and squashing bugs since then. At this point, I believe that I have a pretty stable beta ready.

If you have the time and the inclination, I’d truly appreciate any testing you could do. If you’re already using SPServices and could pop this new version into your test environment to look for regressions that would be great. Unfortunately a few regressions crept into v0.7.1 and I didn’t catch them until too long after I released it.

I’m going to release the beta in a few days and this time let it stand as a beta for a few weeks. There are some pervasive changes in this release that I think may be really useful for everyone, but since there have been almost 13,000 downloads of v0.7.1, I want to be sure that I take care of anything that might be a problem before general release – or as Microsoft would say, RTM.

The two impressive things in this release – if I do say so myself, and I do – are caching and a new function called SPFindPeoplePicker.

The caching I’ve added into this version of SPServices is somewhat rudimentary, but at the same time it can save a decent amount of traffic back and forth with the server. It uses jQuery’s .data() functions to cache the XML for each request which has the option cacheXML: true. This is basically brute force. If cacheXML: true, then the returned XML is saved as a data object on the body of the page with the request XML as the key. If you make the exact same call again, then the request is fulfilled from that cache. Note that it’s “exactly the same call”. This means that the request XML has to match exactly.

I’ve set the option to true for some of the internal calls to the Web Services operations to speed things up when you use functions multiple times. For instance, quite a few of the value-added functions make a call to GetList to get details about the current list, and there’s no need to make that call more than once during the page life. If you are creating more than one cascade with SPCascadeDropdowns, for example, you’ll see an immediate improvement.

The SPFindPeoplePicker function helps you find and set People Picker columns. (The documentation is rudimentary at the moment. Don’t worry; I’ll improve it before the release.) These little buggers are problem enough as it is, and selecting them and manipulating them with jQuery is something that a lot of people want to do. Add to that the fact that the People Picker is rendered differently in IE than in other browsers, and you have a challenge not unlike simple vs. complex dropdowns.

There are other goodies in this release, and you can see the full list of enhancements and improvements on the download page. Note the link to the Issue Tracker items for this release. (Issue Tracker is a horrible name – some of this stuff is simply new functionality.)

As I’m getting ready for the release, I’ve been looking back at some of the feedback and suggestions I’ve gotten since the release of v0.7.1, of course. Particularly gratifying are the reviews that people have left for that version. I’ve captured them below. If you’re not using SPServices as part of your SharePoint development toolkit, maybe you should be!

image