Use the Tools You Have

Sometimes, the amount of script SharePoint loads staggers me.  We can only hope that the recent announcent that Microsoft plans to adopt jQuery will help reduce SharePoint’s script overhead in future releases.  But Itay Shakury recently pointed out a bit of script that it seems even Microsoft engineers had forgotten about.

JSRequest

Back in part 4, I discussed a script posted by the Microsoft SharePoint Designer Team that I used for over a year.  Part of that script involves grabbing and parsing the query string from the URL.  But Itay found this little method in the init.js file that already does that.

PreSaveAction

Another handy function, PreSaveAction(), comes undefined.  Edin Kapic pointed this out and I use it all the time now.  How does an undefined function help you? Well, SharePoint’s form buttons call PreSaveAction before they submit.  You can define PreSaveAction to check form values, for instance, and return true (allowing the user to submit) or false (alerting the user of an error).  By defining PreSaveAction differently for each page, you can introduce fancy validation logic without programming custom fields.

I would love to see the SharePoint community band together to map SharePoint’s JavaScript like we have the CSS.

Improve the Tools You Have

I bought some Ikea furniture and it came with an Allen wrench to tighten all the fasteners.  I took one look at the number of fasteners and decided to grab my cordless drill and a hacksaw.  Thirty seconds later, I inserted the modified Allen wrench in the end of my drill and finished assembly in record time.

Just because something you bought comes with tools, doesn’t mean you have to accept them.  They may not help you as much as they could if you modified them a little.

Hard core programmers have their gripes about SharePoint’s JavaScript.  Some of those complaints relate to exactly the same things we’ve talked about in this series.  But I usually don’t get too riled up unless something flat-out doesn’t work.  That’s the problem with FireFox and SharePoint (OOB).

I know of two troublesome failings of SharePoint’s core.js file in FireFox:

1. Modal popup windows do not pass their values back to the original page.  As a result, complex administrative tasks and the People Picker force you to use IE.
   • See the one line of code that fixes this problem here.
2. The script loaded when you create a Data View Web Part (SPD) with grouping will not expand and collapse groups properly because Microsoft only wrote it for IE.
   • Download the changes needed to core.js here: function-expgroupby
   • Credit to Marco Bellinaso.

These fixes are not supported by Microsoft and future service packs may overwrite them.  But sometimes the potential gain (like with a public-facing site or a user group with heavy Mac usage) makes that a small sacrifice.  So, what’s the best way to fix this?

Fix Single Instance

Sometimes, like with the DVWP grouping issue, you can add the updated function to the page in a Content Editor Web Part. Since it loads after the one in core.js, the IE-only version gets overwritten.  However, if  your problem involves modal pop-up windows like the People Picker control, you need to make the changes server-wide.

Fix Server-wide Issues

Probably the least obtrusive way to fix these issues involves adding a new script tag to the various .master pages calling a bunch of “repaired” functions.  As long as you place your fix script after core.js, the new functions will replace the old ones.  The additional script tag and “weight” of another JavaScript file means you sacrifice some performance.  If, on the other hand, you feel comfortable modifying core.js, I recommend keeping an original copy around and tracking your changes in case a service pack wipes them out.

Paul Grenier