From the SPServices Discussions: Why Should I Bother to Learn XSLT?

Client Server DiagramHere’s a question from gdavis321 from the good old SPServices discussions. In most cases, I just answer the questions in situ, but occasionally – as you frequent readers know – I realize what I’m writing feels more like a blog post, so I move it over here.

It seems that Spservices (thank you for this god send) can do anything that you might want to do with a content query webpart or other webpart… am I missing something? Why should I bother to learn XSLT?

It’s a fair question. As someone who loves using the Data View Web Part (DVWP) – which is XSL-based – the answer is, as always, it depends.

Doing everything client side isn’t always a great idea. For each specific requirement, you should look at whether it makes more sense to do the heavy processing on the server or client. There are many variables which go into this, like client machine capabilities, data volume, number of data sources, need to join data from different sources, skills on the development team, desired time to market, etc.

In SharePoint 2013, much of the processing has moved to the client side (often called Client Side Rendering, or CSR), so many people think that we should just process everything client side now. I worry about this sort of myopia.

Client machines – meaning the machine sitting on your desk or in your lap or hand rather than the server, which sits in a data center somewhere – have better and better capabilities. Yet in many organizations, you may still see Windows XP machines with 1Gb of RAM – or worse!

Additionally, client side processing may mean moving a huge volume of data from the server to the client in order to roll it up, for example. If you’re moving thousands of rows (items) to make one calculation, it *can* feel sluggish on client machine without a lot of oomph.

So client side libraries like SPServices or KnockoutJS or AngularJS (among many others) are fantastic for some things, not so fantastic for others.

When it comes to the JavaScript versus XSL question, both approaches should be part of your toolset. Sometimes good old XSL will be an excellent call if you can do some of the heavy lifting on the server, then pass the results to the client for further processing. The output need not be just nicely formatted list views, but could be sent in such a format as to make the client side processing easy to start up upon page load. My approach is often to ship the data to the browser via a DVWP and then process it further with jQuery on the client.

The mix of what happens where is on a spectrum, too, depending on what you need to do. You might roll up tens of thousands of items in a DVWP and then request items from two or three other lists from the client as the page loads to optimize your architecture.

Yup, there’s that architecture word. A good SharePoint architect will know when to use each of the tools in the toolkit, and JavaScript and XSL are just two of many.

Keep in mind that because “it depends”, your mileage may vary in any and all of this: cavete architectus.


Base Your SharePoint Database Architecture on Business Requirements First, Database Concerns Second

Sometimes when I’m speaking at SharePoint events, I’ll mention something about the fact that “the geeks” make decisions about Site Collections and database boundaries that are a detriment to the users. I got a question about this the other day:

…you mentioned something that I wanted to follow up on: basically it was a warning to avoid setting up the information architecture (site collections and thus ability to shuffle between databases) based on “the geeks”.  I would love to find out what the issues you’ve seen or experienced that were caused by breaking up data across site collections.  I image it might be the cross site query web parts and such.

The main thing I am referring to is the promise of being able to promote content from private or local contexts into wider contexts, therefore maintaining the single version of the truththat Microsoft sometimes talks about. This single version of the truth ought to apply not just to content when considered from a database perspective, but also from a Content Management perspective. A particular version of a document ought to exist in exactly one place. Of course, that’s far more easily said than done, but it’s a Content Management goal.

Note that when I talk about “the geeks”, I mean those of us (yes, I sometimes belong in this group, too) who view the technology for technology’s sake over what its function for the users should be. If you’re an admin who never talks to end users about what they need, then you probably are in this group, though you might not be because you are able to extrapolate their needs well.

Take the example where an Intranet has a root Site Collection and then a Site Collection per Department. (A simplified example, sure, but not that uncommon.) If there is a document in the HR site that we want to promote to the root site, there are no good mechanisms to do it. Site Collection boundaries are primarily security boundaries from the end user standpoint, so we can run into permission issues. We also don’t have a good way to keep a pointer on the root site to the actual document in synch. That means there can’t easily be one version of the truth.

CQWPs and DVWPs in CrossList mode are also out of the question for doing things like rolling up Announcements, for example, which is an extremely common use case. Again, Site Collections are permission boundaries, so those Web Parts don’t work across them. We have to resort to all sorts of tomfoolery using the Web Services or third party tools.

Of course, to the geeks, it makes total sense to make the Departments individual Site Collections. They want to be able to manage the content that way so that they can go to one Department if that Department’s content is getting out of hand to make them clean it up. But it often doesn’t work from a user perspective.

A more complex example would be a smaller organization (as a larger one is unlikely to find the idea palatable) which wants to use SharePoint for its Intranet, Extranet, and Internet sites. Ideally one could create work output in a Team Site in the Intranet somewhere and upon completion, promote it to expose it more widely on the Intranet. That itself if often a problem. But what if we then want to expose that piece of content in multiple Extranet sites? Or we want to expose it as part of the content corpus on the Intranet? Now, one can easily respond with all sorts of enterprise-class concerns about security, but that’s up to the customer. These scenarios come up with my clients all the time, and if they want to make them happen, it’s their choice.  The geeks will usually set things up to preclude any of this because of the content database concerns they have.

The business sometimes simply can’t do what it wants to do because of decisions based on database concerns, and SharePoint is blamed for a shortcoming which it doesn’t actually have. That’s not a good thing for any of us.