Build a SharePoint Scripting Resource Center
This article is part of a series as I document my processes of discovery for creating jQuery solutions in SharePoint. To view the entire series, click the link at the bottom of this article to view all of the articles in the series. — Mark
I laid the groundwork for my jQuery investigations in a previous article. Now that I’ve done a little research, I’ve started building out a SharePoint Scripting Resource Center. The SSRC is at the top of the site collection, and set to “Read Only” access for all users of the site collection. I used a SharePoint wiki site to build the interface for the center.
In this article, I’ll walk through the process of creating a resource center. Follow along in your own SharePoint site and by the time you get done, you’ll be ready to start working on some jQuery with me.
Site Architecture
The first thing needed is to architect the Information Architecture of the site. I use MindManager to do that, diagramming and brainstorming the various areas needed to hold the content. Here’s the diagram I built as a first pass, defining the lists and libraries I will need for the initial build.
Looking at the list of columns needed in the document library, it seems pretty obvious that we should create a content type to handle all the duplication. Let’s create a content type called “Resource Library” and store it in a “SharePoint Scripting Resource Center” group within the content type gallery.
That makes it MUCH easier. Now I can create the document libraries for holding the resources and associate the “Resource Library” content type to each. If I find in the future I need to make changes to the structure of the library, I can do it through the content type.
Resources-jQuery Library
The libraries are used for holding resources needed for implementing any scripting solution within the site collection. I looked through the articles on EndUserSharePoint.com, talked with the authors of the Live Online Workshops and polled the SharePoint Community through twitter to see what the core libraries should be in a jQuery scripting center.
The general consensus is that multiple versions of the core jQuery library should be housed within the resource center. Some solutions are dependent upon specific versions of the library. What I chose to do is house the legacy scripts so that specific solutions can point to them. I then take the most recent library, store it with the version name and also with a generic name so that solutions that want to point to the most recent script will not have to be changed when there is an upgrade to the library.
The jQuery site has an archive of all previous versions if you want to have a complete set. For my purposes, I only need to roll back to version 1.2.6 to accommodate the current solutions available.
If you’ll look closely at that image, you’ll see that I have included Marc Anderson’s jQuery for SharePoint Web Services Library. This is to show that all jQuery resources go into this library, no just the core jQuery libraries.
Resources-Scripts Library
A best practice when using the content editor web part to expose jQuery solutions is to store the scripts/solutions in a central library and point to the solutions from within the CEWP. That way, you can have multiple instances of the solutions running within the site collection, and any updates to those solutions will be immediately exposed to the calling web parts.
The Resources-Scripts library is the central respository for the jQuery scripts and solutions. In my initial setup, I put the LyteBox solution in the library, along with a solution by Peter Allen to format the SharePoint wiki interface into something a little more usable.
Resources-Images
Some of the solutions provided by the authors use interface images and custom graphics. As an example, Christophe Humbert from Path to SharePoint has created KPI solutions for WSS and needs the KPI graphics that are only available MOSS. By storing a copy of those images in a central library, his solutions, and anyone else who would like to use those graphics, have easy access to the resources.
Resources-Charting
One of the limitations of WSS is there are no Excel Services to expose charts and graphs. There are a lot of EndUserSharePoint.com articles on how to create graph and chart solutions using jQuery and other resources. Because this is a major idea that will be expanded upon of the next year, I decided to create a library exclusively for holding the charting resources.
The main resources in this library are from the Yahoo charting API since these can be used as a stand-alone resources, as opposed to the Google charting API which must reside on Google.
Documentation Library
The final library in the SharePoint Scripting Resource Center is the library that holds the wiki pages for documentation. Because the site is built as a wiki, the site itself can be self documenting, allowing the creators of each of the solutions the ability to embed the documentation for their solutions within the site.
Conclusion
What I have described here is the foundation for building and expanding a central resource repository for using jQuery or any scripted solution in your site collection. Over the next few articles, I will be utilizing the resource center to develop simple solutions using those resources.
Mark Miller, Founder and Editor
EndUserSharePoint.com
- SharePoint and jQuery for the Common Man
- SharePoint and jQuery for the Common Man: Resources
- Build a SharePoint Scripting Resource Center
- Resources for jQuery Projects in SharePoint
- First Project w/ jQuery and SharePoint: An Image Slider
- Implement Your First Content Slider in SharePoint
- jQuery SharePoint Resources for the Common Man
Wow, this is a great post. Would be very helpful for development teams to have an implementation like this to house all their resources.
Mark,
Really looking forward to this Series!
If I understand it well, the CEWP should point to:
J Query ‘Current’ (which is overwritten when a new version is issued)
and the list also list
JQuery V2 (the latest version issued – copy pasted as the JQuery Current
JQuery V1 (1st revision)
JQuery (initial version)
right?
Silly question…if 2 CEWPs are pointing to 2 separate scripts (from 2 different authors) intialy pointing
to 2 different versions of J Query, should the 2 scripts be updated by pointing to the J Query ‘Current’?
Could pointing to a more recent JQuery version, ‘break’ a script?
Greg
Greg,
Yes, always pointing to the most current version could break your solutions. Both Paul Grenier and Christophe Humbert have run into that situation. That’s why I have the legacy scripts in place with the full version name.
Mark
FYI — I’m working on a function called SPScriptAudit for my jQuery Library for SharePoint Web Services (which Mark mentions above). This function will help keep track of the script usage across a Site Collection. Take a look at the demo page for this work-in-progress and let me know whether it seems useful for you, if you have enhancement ideas, etc.
M.
Some random comments:
- keeping track of versions is important for jQuery, but even more for plugins (like the jQuery UI I see in the screenshot).
- the YUI chart API requires Flash, and is still in beta. Note that Google also offers a visualization API (I haven’t tried it). It is different from the charting API you mention, and doesn’t require Flash.
Your first paragraph (site architecture) actually makes a good introduction to content types!
@Greg: yes, older scripts could potentially break with new jQuery versions, or new plugin versions. And calling two different versions in the same page will be an issue as the second library you call will overwrite the first one.
Mark, great post … looking forward to the rest of the series. I am trying to follow along in creating a resource center as suggested and, as a SP newbie, am running into some issues/questions on our SharePoint 2003 site. I created the resource center as a wiki site. Then I created the Resource Center content type within that site, with the Item content type from List content types since you did not specify and it obviously uses columns like items.
When I try to add the columns using ‘Add from existing site columns’, none of them appear in the list, but when I try to add column ‘Type’ using ‘Add from new site column’, it tells me a column with that name already exists.
What am I doing wrong?
Sam – Wiki pages are documents in a library. If you create a content type from a “List” parent, it will not be available as a document content type. Rebuild your content type using document as the parent. During that process, you can use the columns you previously created without having to do them all over again. — Mark
Mark, I did as you replied and am still getting the same results. Could this be because I did not create the resource center at the root of the site (do not have administrator rights), but in a sub-site where I do have admin rights?
This is awesome as usual Mark! By the way, am I the only one who likes the charting components built into .Net 3.5? I see a lot of different javascript solutions, but I guess I just like the .net ones. I really can’t wait to see more in this series!
I love the concept!
I’m very interested in this topic and think this is a great idea. But as someone new to SharePoint, you seem to make a lot of assumptions about your readers SharePoint knowledge and leave out some necessary details about how to construct this.
As a concept, I find this post useful. But as a guide to creating mine own, not so much.
Hopefully future articles will provide a more detail and shed some much needed light on this subject.
James – Specifically, what is it that’s missing? — Mark
Mark, I’m interested in doing something like this for my company so that all of our site collections can get scirpting resources from a common center. What, if anything would i need to change from your architecture?
TIA
Dean
Dean – Christophe Humbert and I are putting together a new series of live online workshops, and the scripting center will be a session in that series. The announcement comes out Monday. — Mark
Mark – I set this up and its working great, except when trying to access the scripts across site collections. I know from the feedback on one of your SharePoint Days recordings that it *should* work, but so far all I get is “Cannot retrieve the URL specified in the Content Link property.” This is with an out-of-the-box implementation of WSS 3.0 on my test server. Any suggestions for getting this to work would be greatly appreciated. Thanks!
Tim,
As you say, site collection should not be a problem. Check to see that both site collections are using the same AD and the NT\Auth group has read access into the scripting center.
Mark
Hmmm… Thanks for the response Mark!
Searching the web shows that I’m not alone on this. I’m wondering if there’s something unique about your/my SharePoint setup?
Here’s what my environment looks like (from a security perspective):
- Both site collections running under the same IIS web site (SharePoint – 80)
- Directory Security set to “Integrated Windows Authentication” (Anonymous NOT checked)
- App Pool identity set to the SharePoint service account (domain account)
- Web.Config includes and and
- Resource-Scripts docLib located in the root SharePoint site collection
– All Auth Users have read access to site and doclib
- I link to the resource lib from the other site collection with “/ResourceScripts/MyCustomScript.txt” (I’v also tried the full URL)
I still get “Cannot retrieve the URL specified in the Content Link property.”
If you have ANY ideas, please share. Thanks!!
Let me check when Sharon Richardson from JoiningDots.net to see if she’s got time respond. — Mark
I too have seen this issue. I think the file the XSL link refers to, needs to be on the same site collection OR the site containing the file needs to have Anonymous access enabled.
The XML Web part suffers from the same issue as mentioned here: http://office.microsoft.com/en-us/sharepointtechnology/HA011609331033.aspx
Tim: instead of using the content link, try calling the script using a script tag in the source editor of the CEWP:
Thanks Jack! That turned out to be the trick! Enabling anonymous access to the site provided access to the scripts library from any other site collection.
To avoid needing to look this up, here are the steps:
- In Central Administration –> Application Management –> Application Security –> Authentication Providers, select the zone that represents the site where your script libraries are located.
- make sure “Enable Anonymous Access” is checked
- In Site Settings (for the site where your scripts are located), bring up Site Permissions, then under Settings, select Anonymous Access
- Select either Entire Web Site, or Lists and Libraries. I selected lists and Libraries.
- In the settings for each of your script libraries, select “Permissions for this document library”
- Under Settings, select Anonymous Access
- Check the “View items” box.
Keep in mind, this is all on an intranet site, never exposed to the internet. On a public facing site or extranet, you may want to re-think where you locate your scripts – perhaps a separate site – so you can better control security.
Curious if there are any other solutions to this issue. I posted the same issue in Stump the Panel. I just checked with our global Admins and there is no way they are going to turn on Anonymous access. I have a resource center all set up. I just cannot access the scripts from all my other site collections to the site collection that has the resource center loaded on it. No problem when I click the test link (the file opens up). Security is wide open for testing. I just keep getting that
“Cannot retrieve the URL specified in the Content Link property. For more assistance, contact your site administrator.”
message. I really do not want to have to run a workflow to duplicate the scripts across site collections. Hoping someone has some ideas.
Tom – what about setting up a separate site that contains only the resource libraries? This can be setup with anonymous access without risk to your main site’s content.
I did ask that question. The answer was no.
I am out of ideas
This is not a great idea, but with your apparent restrictions, it might do the trick: You could host the repository on each of your site collections, but only one would be considered the “master” repository. Add a workflow to this (using Visual Studio – I don’t think SP Designer will work for this) that copies new and updated files from the master to each of the other site collections.
There’s always the risk that someone who doesn’t know better will modify one of the other libraries directly, but I suppose you could use alerts to inform you of that.
Like I said – not the best solution, but it may work.
I agree, not our preferred solution. I started to do this, as a backup solution, already in case we could not find a resolution to this. I hate duplicating data. Kind of a pet peeve of mine. I really appreciate your ideas. Confirms where we were headed. Thanks Tim.
Tim and Mark, thank you so much for your help. My boss and I have a meeting this afternoon with the admins and will bring up the points and ideas that you have shared. This has been very helpful. Thank you.
>> what about setting up a separate site that contains only the resource libraries?
> I did ask that question. The answer was no.
I hate to be hard core on this, but if that truely was the answer, they need to be able to justify that as a business decision. If there is absolutely nothing else in that site collection other than the resources needed to implement your clientside solutions, and there is no risk to business data, IT is taking the easy way out by saying “No” as a convenience to them.
Personally, I would go over their head. IT works for the business, not the other way around. Find a high level person who will champion your cause and push it through. The benefits will be apparent immediately.
I know it’s easy as a third party, outside opinion for me to say this, because I don’t have to deal with the politics of your situation. However, as a business owner myself, I would want to know if IT was standing in the way of a project just because they didn’t want to do something.
Hope that helps.
Mark
Tom and Tim,
How about setting it up OUTSIDE of SharePoint? Have an external site that contains all the core libraries and scripts, then point to the external resources. That’s the way google is setup. I don’t use google because of an HTTPS connection, but if you’re not running under HTTPS, this might be the solution you’re looking for.
Regards,
Mark