For a few years now I’ve been pushing myself to see what is possible with SharePoint 2010. Some of these things are small, out-of-the-box (OOTB) solutions: creating custom search scopes, customizing table styles, and messing with itemstyle.xsl. But more often than not, the solutions I like to create are the ones that go beyond what SharePoint does OOTB. I rely heavily on SPServices for a lot of these solutions. It’s a great tool that does everything I need to do with lists in SharePoint. More recently I’ve been using SharePoint’s REST service and wiring in things like Backbone.js to create some interesting solutions.
Side note: if you want to see some great front-end solutions using SharePoint, check out the book Black Magic Solutions for White Hat SharePoint.
I was training a SharePoint newcomer last week in New York. My trainee had a strong developer background, and just needed to get familiar with SharePoint for an upcoming job. As I was explaining things to her, I started to talk about a few custom front-end solutions that I’d built, and she latched on to those (coming from the developer world). But as I was explaining things to her, we started to discuss the legitimacy of doing some of these things in SharePoint. When does it change from a “SharePoint solution” to a “solution that uses SharePoint as a relational database”?
Let’s say you are using jQuery, SPServices, and maybe the Google Charts API. You can hook into a list, display a really great chart, and put it on a SharePoint page. That’s a great use of SharePoint. It’s a single page, accessing a single list, and enhancing the experience for the end user. Now say you have several lists that need charts. So we put several charts on the page. Easy. But how about when it comes time to organize all of these charts (say we have 30)? Now we need to add some UI elements that organize the charts in, say, tabs, or maybe an accordion. Ok, that’s great. But now instead of hardcoding in all of our lists to our scripts, we want one list just to organize our other lists. So now our code is much cleaner, we get all of our chart references from one list, and we organize it on the page with one cleaner, bigger script. At this point we have now made a list into a relational connection to other lists. But this is fine, even SharePoint allows this, right? (think Lookup fields)
So where is the line? How many lists must be connected before we pump the brakes and say, “wait…things are getting a little hairy”. See, in my opinion, SharePoint is a great place to store data. It’s also a great place to store data from external sources. It’s a great collection point for everything from a SQL server with lists of students, or to a connection to a 3rd party Gradebok. That’s what SharePoint is great at, being a central point of contact for many different systems. So the logical next step is to build things on top of this central point in order to interact with the data, right?
Here’s the problem I had with it. In order to give parents rights to see their data, as well as their child(ren)’s data, we needed to give them access to the parent and student lists. This meant that for that period of time, all parents (if they knew the address) had access to all the data for all other parents. Now, this school is a fairly tight-knit community. There was nothing more in those lists that couldn’t be found out through the directory and doing a little digging. But nonetheless, it was all right there, in an easily exportable format. The intranet is password protected, but who is to say a parent with malicious intent couldn’t have really caused a headache for a lot of people?
All this aside, we weren’t really worried because a) the time period was so short, and b) the stakes weren’t too high. That said, this was definitely a clear line for me in where I stop using SharePoint. Keep in mind, that’s when “I” stop using SharePoint. A back-end developer could have a field day with this project. Put everything server-side, secure it to the logged-in user, and you’ve got a much better system.
SharePoint has its faults, many, many faults. But I think we are doing ourselves an injustice to use SharePoint for some of these solutions. While we may be thinking, “look what I can do with SharePoint,” maybe we should take a second and think “should this be done in SharePoint”? There are faster ways to do things. There are more efficient ways to go about linking data from relational tables.
So where is the line? Where is the line for you? When do you stop developing front-end and go a different route? What are your personal limitations?