Remember in part 3 when I said that frameworks can help you develop faster? Since jQuery in SharePoint is the hot topic right now, I’ll compare an old standby script in poj (Plain Old JavaScript) against a new jQuery version.

Soon after people started using SharePoint 2007, the SharePoint Designer Team blogged about Using Javascript to Manipulate a List Form Field. This opened a lot of doors for me personally and I really started getting interested in using JavaScipt to solve SharePoint challenges.

Scenario: We have a simple newform.aspx generated by our custom list. One of the fields, ItemID, needs to be pre-populated from the URL.

Solution 1 (old shcool):

1. Navigate to the newform.aspx page of our custom list.
2. Add the following to the URL: “&PageView=Shared&ToolPaneView=2″.
3. Add a Content Editor Web Part (CEWP) to the main zone.
4. Open the web part’s tool pane and edit the source.
5. Paste in the following JavaScript (making sure the three parameters are entered):

<script type="text/javascript">
_spBodyOnLoadFunctionNames.push("fillDefaultValues");
function fillDefaultValues() {
  var qs = location.search.substring(1, location.search.length);
  var args = qs.split("&amp;");
  var vals = new Object();
  for (var i=0; i &lt; args.length; i++) {
    var nameVal = args[i].split("=");
    var temp = unescape(nameVal[1]).split('+');
    nameVal[1] = temp.join(' ');
    vals[nameVal[0]] = nameVal[1];
  }
  setTextFromFieldName("ItemID", vals["ItemID"]);

  //two parameters to copy query string to field
  switchback("ItemID"); //another parameter to reset the field if changed
}
function setTextFromFieldName(fieldName, value) {
  if (value == undefined) return;
  var theInput = getTagFromIdentifierAndTitle("input","",fieldName);
  theInput.value=value;
}
function getTagFromIdentifierAndTitle(tagName, identifier, title) {
  var len = identifier.length;
  var tags = document.getElementsByTagName(tagName);
  for (var i=0; i &lt; tags.length; i++) {
    var tempString = tags[i].id;
    if (tags[i].title == title &amp;&amp; (identifier == "" || tempString.indexOf(identifier) == tempString.length - len)) {
      return tags[i];
    }
  }
  return null;
}
function switchback(fieldName){
    var switchInput = getTagFromIdentifierAndTitle("input","",fieldName);
    switchInput.onchange = fillDefaultValues;
}
</script>

Now when we add the query string “ItemID=x”, x is put into our text field and, because of the switchback function, if the user changes it, it will fire fillDefaultValues again. I made that modification to the original scripts to prevent users from haphazardly changing my pre-populated values.

Solution 2 (jQuery):

1. Upload the jQuery and jQuery.queryString plugin scripts to our server.
   • If you have access to the server file system, add them to 12\TEMPLATE\LAYOUTS so they reference at /_layouts/…
   • You can also place the scripts in a document library where “all users” have Restricted Read or higher permissions.
2. Navigate to the newform.aspx page of our custom list.
3. Add the following to the URL: “&PageView=Shared&ToolPaneView=2″.
4. Add a Content Editor Web Part (CEWP) to the main zone.
5. Open the web part’s tool pane and edit the source.
6. Paste in the following JavaScript:
   • Use a reference (src=) that does not include the server name, this will make the script call faster since the call avoids DNS resolution (the process of asking the name server for the IP address of a given server).
   • In production, you should use the compressed version of the jQuery scripts for better performance.

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript" src="/js/jquery.queryString.js"></script>
<script type="text/javascript">
$(function () {
  fillDefaultValues("ItemID","ItemID"); //two parameters
});
function fillDefaultValues(fieldName,value) {
  var qs = $.getQueryString({id:""+value+""});
  var x = $('input[title="'+fieldName+'"]');
  x.val(qs);
  x.change(function () {
  x.val(qs);
  })
  .change();
}
</script>

Now the exact same thing happens as in solution 1. What’s the difference? Well, for starters there’s a lot less code in our CEWP–this seems easier to maintain. Using the YSlow add-on for FireFox, I also noticed that Solution 1 downloaded 218.8k loading in .563s with a Performance Grade of D(67) while Solution 2 downloaded 274.7k in 0.807s, a Performance Grade of F(59).

So that’s a real-life example of the trade-offs a framework offers. Simpler, easier-to-maintain code in exchange for a larger “footprint” and lower performance. For some more tips implementing jQuery in SharePoint, check out Jan Tielens’ blog.

UPDATE (12/1/2008):
Based on the discovery of the JSRequest method in the SharePoint init.js file, we can rewrite Solution 2 without the additional plugin and reduce its footprint.

<script type="text/javascript" src="/js/jquery.js"></script>
<script type="text/javascript">
$(function () {
  fillDefaultValues("ItemID","ItemID"); //two parameters
});
function fillDefaultValues(fieldName,value) {
  JSRequest.EnsureSetup();
  var qs = JSRequest.QueryString[value];
  var x = $('input[title="'+fieldName+'"]');
  x.val(qs);
  x.change(function () {
  x.val(qs);
  })
  .change();
}
</script>

The YSlow result for this newer script is D(63); proving a smaller footprint than the original.