Looking over the last two articles in this series, parts 4
, some ideas may have popped into your head.
"If I use the web service to get data then use that to pre-populate a form or manipulate page elements, I can make some awesome functionality."
Manage Your Resources
Keep in mind the title of this series, Power User Toolbox
. I want you to fill your toolbox then collect, build and evaluate solutions for your users. If you started working on your own solutions already, that's great! Your next challenge
will likely involve managing
, various library
files, and the web parts
that put everything on the page.
- Put the files in the server's file system (as seen on Jan Tielens’ blog).
- Pro: Fastest load time
- Con: Challenge to keep large farms updated
- UPDATE: Jan has more information about managing scripts using SmartTools: More info or get it on CodePlex
- UPDATE: David suggests ShUIE for managing script files
- Put the files in a SharePoint document library.
- Pro: Only one repository for the entire farm
- Con: Stores the files in database blob, increases burden on SQL server
- Use the Google AJAX Libraries API.
- Pro: Single repository, constantly updated, zero administration, user cache
- Con: Needs DNS call since files are not local, relies on Google uptime, not SSL, not all libraries or plugins supported
If you have a secure site
, the Google AJAX Libraries API
will throw errors in most browsers on the default security setting--not ideal. Otherwise, for a small performance hit, you can forget about keeping your libraries updated. As the popularity of the Google AJAX Libraries API
grows, users may already have a copy of the library you use in their cache
when they hit your page which can actually improve performance
Managing Web Parts
When you design web parts that use outside scripts or libraries, avoid calling the same script more than once--it will only reduce performance. We could
add our library to the default.master page but since we also know about footprints (pt 3
), we want to avoid loading our library to a page that does not need it.
The easiest "cross-browser" way to do this in SharePoint that I found looks like this (example for jQuery through Google API):
With that code in our web part, the web part will check for the presence of jQuery and if not found, load the library from Google's API--but not more than once. So, you can have multiple web parts on the page and only the first one will load jQuery.
You might notice that we did not use _spBodyOnLoadFunctionNames.push
(the loader) or try to wrap this in a function. If we wrap this in a function, SharePoint ignores it unless you use the loader or call it with another event--like onClick. If we use the loader, we're telling the browser to fire the function during the onLoad event (after the DOM loads). However, if we wait till then, the newly inserted script element will not get processed by the browser.
Also, because we need the script element created before we try to call the jQuery library, we have to close out the first script tag and start another one.
If you're worried that Google could go down (pshaw!) and render your page useless, add a contingency plan script as well, like this:
Make sure you change the path to your jQuery library to match your environment in the 4th line. This script can also help if you followed Jan Tielens’ blog
but a member of the farm somehow missed an update. Keeping a copy of the jQuery file in a document library and using the contingency script can avoid problems.