Init

There is a saying that goes “when you have a hammer, everything looks like a nail”. In the case of SharePoint lists sometimes they get carried away from  their designed nature and used to store massive data sets. The more columns loaded into a list, the slower it typically performs. This is especially the case for ‘lookup’ columns which may query lists other lists (or even itself) and return a massive data set that needs to be rendered as user controls.

Once traveled down this road the only preventative maintenance you can do is clean up and move your data to another location (relational database) or create some custom forms for your users to access. These forms can display a subset of the lists fields so that a user may be access something more performant for their purposes. This is a very simple task when you realize how to do it, screen shots will explain this quite quickly: (more…)

Microsoft’s SharePoint services are very good at meeting some generalized needs for information storage and organization. I won’t go down the rabbit hole of discussing how SharePoint lists should never be used to represent data that is inherently relational. Given that you can get a site up and running in a matter of seconds it is very difficult to customize and extend the out of box functionality. One particular need people might have when using SharePoint lists is to modify the default menu buttons. In particular we created several new display and edit forms for a monolithic list we were using, we needed a way to let users navigate to these customized pages.

In this article I will explain how to take the standard menu bar like this:

Standard menubar might not provide enough functionality.

Through post-processing DOM Manipulation accomplish something like this:

Added new buttons, removed one, and created a second row.

I tried to write these customization scripts in a manner that would allow for them to re-usable by someone else for the same purposes. They are separated into two files, one is a toolkit containing common functions used through this hack and the other is the actual ‘main’ which contains all page specific information.

Firstly lets look at where to put the code in at; every list creates a DispForm.aspx which is filled with bunches of <asp:content> tags. We need to put a link to the javascript customization files in between on of these <asp:content> tags to make sure it gets executed on the users page. For my purposes I put the calls inside the the “PlaceHolderTitleAreaClass” like this:

<asp:Content ContentPlaceHolderId=”PlaceHolderTitleAreaClass” runat=”server”>
<script id=”onetidPageTitleAreaFrameScript”>
document.getElementById(“onetidPageTitleAreaFrame”).className=”ms-areaseparator”;
</script>
!– Call to the Customization Script –>
<script src=”http://prod.servername.intranet.local/resources/script/toolkit/toolkit.js”>
<script src=”http://prod.servername.intranet.local/resources/script/sharepoint/customization.js”>
!– End Call to Customization Script –>
</asp:Content>

You can see here I am linking to my javascript toolkit, which has many of the common functions I use, and the particular pages customization script. First lets look at the customization script. This will help you to see what I am doing on the page, I caution you however that this will appear as an extreme hack… mainly because it is.

customization.js — Download this file and I will explain what I am doing as you read through.

iD is a variable that we are storing to represent aspx pages overall ID.

source is a variable that we are going to store the return address for any of the links that we are building.

tableID variable is the specific html id of the table that we will be manipulating, this has to be hard coded in the customization file. Basically you need to find the parent table of the control we are modifying, I will leave you to figure this out.

We are going to get the html element table and start modifying the dom. From here on you should be able to see how iterated through using two worker functions; addButton and addSeperator.

toolkit.js — Download this file and I will explain what I am doing as you read through.

The functions and their comments should be most likely self explanatory except for addButton which might look quite daunting. This is because I tried to follow the convention of how they have created the container for buttons. I nested the concatenation like the html should appear for readability, but to me it still looks like junk and I wrote it.

So, in recap we essentially are hacking up the menu item on each client after the page loads. This is a nasty hack in my opinion and I would much rather have modified the actual control, however the way that SharePoint was designed makes it very difficult for a developer who doesn’t have access to the whole production environment. Over a period of about a year we didn’t see any data corruption from building out the aspx links in this manner, I would consider this hack safe for the data in your list and unobtrusive enough that someone with limited access (ex. SharePoint Desginer) can get it in place.