I continue to receive comments and feedback on SP SIN, and it’s very positive so far. If you have questions, comments, feedback, success stories, bugs, hate, or anything, feel free to let me know.
One set of questions I would like to mention specifically came from Chris Quick on SPYam. With his permission, I’m reposting the questions and answers as blog posts so I can answer more fully and to a larger audience. There are two questions, and thus two blog posts, because I know your attention span is the length of a human hair.
Oh, and to make sure you read until the end, I’ll both reveal my evil plan with SP SIN and tell you how to become filthy rich by the end of this blog post.
Chris Quick in reply to Bjørn Furuknap: I really love SP SIN and have been investigating it for some of the projects I am currently developing. Here are a couple of points that I shared with a co-worker the other day after evaluating the tool. I’d be very interested in your feedback.
1. This is scoped at the web level, so you have to activated it on all sites and subsites in a collection where it will be used. This means to import the scripts, you have to provide them on every site where you intend to use them, correct? This is good because you have more control over where it is running. However, it could become a burden because you have to add the script resources – AND maintain the script resources on multiple sites. Any plans to scope it to an entire collection?
It’s almost eerie how these questions line up with things I’ve already been discussing in several one-on-one sessions over the previous weeks. Because I’ve given these questions considerable thought, I want to elaborate on the answers.
SP SIN Scope
If you’ve started using SP SIN, you’ve probably noticed that the features to activate SP SIN are site scoped (meaning scoped to an individual web). As Chris points out, this means that you have to activate and store the SP SIN resource configuration on each and every sub site in a site collection.
Before I move on to explain why this is the case, I just want to point out that you can store the scripts and resources you reference anywhere you like, including in a site collection level repository like the Site Assets library of the root site if you’re using SharePoint 2010. So, you don’t need to actually copy the scripts or style sheets, you just point your resource to the location of the script or style sheets where they are. Provided your users has access to those files, you won’t need to store them anywhere else.
Now, the short answer to why the SP SIN framework is site scoped is simply that there are no storage mechanisms in a site collection. That’s right, a SharePoint site collection is simply a management and organization thing; it doesn’t actually store anything. Everything you store in a site collection is stored in one of the sites. When we talk about site collection scoped content like master pages, content types, or web part galleries, these are by convention stored in the root web of a site collection, but regardless, it’s still just a site, not a site collection.
The slightly longer answer has several components, one of which, as Chris mentions, is flexibility. By having each sub web host its own configuration, you can target even more focused where you want things to appear. Further, you can delegate responsibility to site owners without having them needing permissions to parent sites or site collection. Finally, although I could have tried to come up with some kind of inheritance system, it would complicate the solution considerably, both for the end users who need to understand where their resources come from, but also for developers who need to design multi-level configurations.
Even if the inconvenience of setting up the configuration on several sites is your most important factor, however, there are still a ton of options available to you.
Let’s say you have something like a project portal where you’ve designed your own site definitions or solutions that automatically set up new sites according to some provisioning mechanism. Well, if you’re already building your solutions, you can easily add a line of two or code to activate SP SIN and a single feature to deploy the configuration. If you’re using a premade or custom made site definition, you can either include SP SIN and a custom feature in those definitions, or staple them on to any site definition (including MySite) using a feature stapler.
You Promised to Make Me Rich!
OK, I can’t actually make you rich, but I have an idea that someone, like yourself, may want to pursue. In fact, it’s part of an evil plan I have to take over the world, get a furry white cat, and send secrets agents to their deaths in pools of sharks.
Note: The second part of my plan is to stop watching Bond movies.
Because SP SIN is both open-source and designed to be extremely scalable using standard SharePoint features only, it’s perfect for someone to extend. And, even though SP SIN is open-source and free, that doesn’t mean your brilliant solution that extends SP SIN must be.
Here’s an idea, one I’ve been turning around in my mind and that might be a good candidate for building a commercial product on: why not build a product that allows people to manage their SP SIN resources either on a site collection scope, or even a farm level? You could do something as simple as adding a site event receiver to automatically activate SP SIN and configuration packs when users create new sites, but you could make it as complex as you’d like.
For example, you could have a fancy interface where the entire site hierarchy was shows as a tree view and a right-click would give you a context menu where you could activate or deactivate SP SIN, install custom resource types, deploy configurations, or even, if you’re very brave, have a button to extract a WSP containing the current configuration for redeployment across test, staging, and production environments.
I’m certain that once SP SIN gains traction in adoption, and once the SP SIN Store comes out to give you an easily accessible marketplace in which to promote your products, making money off building SP SIN extensions will not only be possible but much easier than it is to become rich on Apps. Because SP SIN is licensed under GPL, you can even bundle it up with your product and ship the entire thing to your customers if they don’t have SP SIN already.
So, here’s my challenge to you. Build a useful extension to SP SIN, something that will make life easier for someone. Create a good user story with a problem and explain why your product solves the problem. If you build something good, I’ll feature it on my blog and on the SP SIN CodePlex site. Can I help you in any way to realize your idea? Shoot me an email or a comment, and I’ll get in touch to help in any way I can.
Hm… Perhaps I’ll even run a competition of some sort…
In any case, I have another question to answer from Chris, and maybe even a product idea for you there, so stay tuned.
Found this article valuable? Want to show your appreciation? Here are some options:
a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.
b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!