This project has moved and is read-only. For the latest updates, please go here.

What NOT to do with SPServices

Mar 17, 2011 at 1:47 PM

Hi Marc,

First off, I wanted to say Thank You for writing this wonderful tool. I use it extensively and "try" to teach all of my clients to use it as well.

For those of you finding this post without the back story, I tweeted my disgust with a current "client" who after I spent a lot of time getting them up to speed with jQuery and SPServices decided to write a wrapper around SPServices (and parts of jQuery). Here's the full back story...

I'm currently working with a client who was mandated to install SharePoint. Initially, they planned on installing it, releasing it to the work force and letting it die a quiet death. However, a large group of people within the workforce had previous knowledge of SharePoint and what it could do, so they started pressing for modifications. That converted my 14 week contract into a 10 month contract. The downside is that due to limitations imposed by various forces, we do not have access to the object model, thus the need for extensive use of jQuery and SPServices.

Three months ago, 2 developers were assigned to the team and I was tasked to getting them up to speed with SharePoint development so that they could take over once I left. I sat them both down and gave them a crash course on SharePoint 2007, SP Designer, jQuery and then SPServices. I then pulled 2 requests from the list that were not urgent, but required some form custimization for them to work on. Neither developer was allowed to work on this "full-time" so I didn't expect miracles. Both of them would ask questions across the room and I would help them as needed while trying to keep the urgent requests from becoming emergencies. We also had daily stand up meetings to make sure there were no roadblocks. For three weeks everything seemed to be going fine. I finally got a chance to sit down with each of them and that's when I discovered that he started writing a wrapper around JavaScript and the DOM to provide access to elements. He wrote this even after I showed him how to use jQuery. After I found this, I showed him how he was not only duplicating jQuery's code, but was doing it inefficiently. He tried to argue that his was better, but his arguments always boiled down to "because it's my code".

He was then pulled away from working on the code for several weeks and just started back up on it and came to me with a question about why he was getting an error on his page. I pulled up his site in SPD and immediately noticed that he was no longer putting his javascript files in the site collections JavaScript library, but was copying his wrappers into each list that he was working with in order to hide them from me.

The wrapper that he created currently only covers two methods (that I've found)...UpdateListItem and GetListItems. The wrapper takes in the valuepairs, the callback function, CAMLQuery and ID. It then goes through each of the options defined in SPServices and hard codes an entry...with no way of overriding them if needed. The total "cost" for this is over 1800 lines of javascript code that are being included into each of the forms that he writes. The wrapper simply carves out a small subset of the available features within SPServices and then removes a lot of capabilities such as being able to specify which site the list is part of.

I realize this isn't a normal discussion for this forum, but I hope someone will read this before they start writing a wrapper around jQuery and SPServices and realize that second word in "Code Reuse" is "Reuse"...which (as I define it) means don't write a wrapper around something just so you can make it "yours". :)

Mar 17, 2011 at 4:10 PM
Wow. I'd say that there's a blog post in this, but I'd be afraid that it would just fuel the anti-Middle Tier folks' arguments that script is dangerous.

Yet more proof that bad developers can write bad code, regardless of the platform or language they are using.

Thanks for sharing!