During a recent discussion with @TashasEv, the topic came up of preserving site definition when rolling out jQuery form enhancements. The preservation of site definitions is something that many people ignore, but in the interest of best practices I figured it was worth a blog post to explain some of the pros and cons, and offer some solutions.
Many of us (myself included) use jQuery to enhance out of the box (OOTB) SharePoint forms. jQuery allows us to make a variety of minor or major changes to the usability and functionality of forms either through straight jQuery or with Marc Anderson’s (@sympmarc) popular jQuery Library for SharePoint Web Services (SPServices). Cascading dropdowns, content relevant fields, dynamic changes to styling, and other enhancements can greatly improve the user experience and the data entry side of a form, but can be the achilles heel of your support model if done incorrectly.
In layman’s terms, the site definition is the foundation on which all OOTB SharePoint sites, templates, forms and pages are based. Essentially, this allows you to manage assets within the site by managing the site definition. An easy to understand example would be upgrading your SharePoint environment. If a version upgrade or service pack comes along that touches the site definition, all objects using that site definition will be updated accordingly. The issue lies in the fact that when you open your OOTB SharePoint form in SharePoint Designer and edit it, you essentially disconnect that form from the site definition. Six months down the road when you upgrade your environment or push that next service pack, your form will now not be updated. Additionally, if you find yourself in a position where you need to consult Microsoft for support, Microsoft can very well point out that you’ve customized the OOTB code, and refuse your support request.
One of the challenges I always seemed to face with SharePoint was limiting content displayed based on a users access level. Marc Anderson’s (@sympmarc) SPServices library solves some of those hurdles if you’re using jQuery elsewhere, as you can call the SharePoint permissions web services to determine if a user is in a specific group, then use jQuery to write content. But what if you’re not using jQuery anywhere else, is it worth adding the jQuery library and the related web service calls to check permissions? Are you looking at hiding web parts by permissions, or changing site controls?
I recently discovered the PermissionsString attribute, which compares the user’s credentials against the defined permission string. We can then use this logic to display content relevant to the user’s permissions. This is a great alternative to calling a web service if you’re not already using the jQuery library elsewhere, or if you want to make site wide access based adjustments to the SharePoint UI. As an example, we can hide the “View all site content” link from anyone except for site admins.