Power User Toolbox: JavaScript for SharePoint – Pt6

Be A Mad Scientist JavaScript Developer
Looking over the last two articles in this series, parts 4 and 5, 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.”

I call this the JavaScript mashup.

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 your JavaScript code, various library files, and the web parts that put everything on the page.

Managing Libraries
I found three ways to manage your JavaScript libraries that make sense for SharePoint.

1. 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
2. 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
3. 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 Code
Everyone has their own habits for managing code.  I typically keep an offline copy of each web part I make and a copy of each version of the JavaScript code the web part holds.  I also upload a copy of reuseable web parts to the web part gallery.  This way, I can always grab the latest copy from the Quick Add Groups.

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.

<geeky stuff>
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.
</geeky stuff>

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.