This project is read-only.

.NET CSOM and Server load: profiling injections, massive JS libs, etc.

Mar 24, 2014 at 6:18 PM
Edited Mar 25, 2014 at 10:12 PM
I am a major fan of all of these new JavaScript libraries and injection patterns which are making things easier. Reluctantly I am giving up my desire to have everything be natively coded (and pre-compiled) Fully Trusted Code (FTC).

But I am concerned about pages becoming heavy server/browser load. Some of the JavaScript libraries (AngularJS, dataJS, Breeze, Knockout), added on top of SharePoint injections and then items such as web parts, the task of profiling a SharePoint page is getting tougher.

Specifically relative to the AMS, how do UserCustomAction's work? Do they run during the Page life-cycle every time or are they cached? Is there a tool for checking the status of how many UserCustomAction are installed on a Site? As we trend away from things like Web Parts and towards CSOM Apps with UserCustomAction and JavaScript libraries, I think I will want an easy way to manage this from within SharePoint Central Administration.
May 11, 2014 at 11:17 PM
I don't have much information about the page lifecycle, profiling, but for your question: "Is there a tool for checking the status of how many UserCustomAction are installed on a Site?"

There is not an OOTB tool that I know of, but there are API's to access this information and build your own tool. Most of the Office AMS sample use CSOM to add UserCustomActions but they can be managed through JavaScript as well. You could then use a UserCustomAction to put a link to your app in the settings drop down to make it feel like an OOTB tool.

For more details see:
I prototyped a SharePoint-hosted app for managing user custom actions using these APIs a while back but I found that there were other apps available in the Store which looked like they already had this capability and I stopped working on it.
The only tricks I came across was to ensure that you build the CommandUI XML properly. You have to make sure to use all the *NS (NameSpace) suffixed methods to create a document instead of the normal methods in order to preserve the casing of the elements. E.g. Use createElementNS not createElement, and use setAttributeNS not setAttribute. You can look at the XML generated by Visual Studio and this reference: Default Custom Action Locations and IDs to determine how to construct the document. Then it's a matter of POSTing the Xml to the correct endpoint.

Since JavaScript injection through user custom actions is becoming an important technique used more an more throughout the office AMS projects perhaps it would be good to include a more robust sample on doing this through Javascript instead of CSOM if the community wants it.