SharePoint 2013: Toggling between minimized and debugged version of java scripts

There is no doubt that including a minimized versions of your scripts (and css files) is best practice, not only for SharePoint but for any Web Application. However, this practice is often ignored by many programmers. Minimized version of script significantly reduces the page’ payload, especially for large javascript (and css files). Just to give you a comparison, debug version of JQuery 2.0.3 version is 246KB but its minimized counterpart is only 82KB.

On the other hand, debugged version of scripts are convenient for developers because setting breakpoints and debugging using developer toolbars is easier.

Now, what if we could archive best of both the worlds! What if we could toggle between debugged version and minimized version without re-deploying anything? Well, I would love it and so I thought about using the technique that I described here.

Note following though:

• Even though this post uses some SharePoint 2013, with just a little tweak it can be applied to SharePoint 2010 as well.
• The technique here shows only one JavaScript file, but as many JavaScripts as you want can be included.
• Similar technique can be used for CSS files as well
• I have used a couple of site collection level FEATURES which are visible on Site Collection Features page. But if you prefer, you may make them hidden and activate them using PowerShell.

Let’s go to the business now!

The first step is to create a UserControl in your solution and put it under ControlTemplates mapped folder as shown below:

Define a property in your code behind of the User Control as shown below:

   1:   private bool _minimized = false;

   2:   

   3:          public bool Minimized

   4:          {

   5:              get { return _minimized; }

   6:              set { _minimized = value; }

   7:          }

Now refer your scripts on in the .ascx file as shown below:

<% if (Minimized == true) {%>
    <script type="text/javascript" src="/_layouts/MyApp/scripts/jquery-2.0.3.min.js"></script>
    <!-- Other files goes here-->
<% }else{ %>
    <script type="text/javascript" src="/_layouts/MyApp/scripts/jquery-2.0.3.js"></script>
    <!-- Other files goes here-->
<%} %>

You may have to provide your own script paths..

Next, create two FEATURES and Add two empty elements using VS.NET’s “Empty Element” project item as shown below:

Add one empty element to each feature. You may use your own naming conventions for your FEATUREs and Elements.

The content of MimimizedScript –> Elements.xml file would look like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Control Id="AdditionalPageHead" ControlSrc="/_controltemplates/15/MyApp/MyAppScriptReferences.ascx" Sequence="20">
    <Property Name="Minimized">true</Property>
  </Control>
</Elements>

And the content of RegularScripts—>Elements.xml file would look like this:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Control Id="AdditionalPageHead" ControlSrc="/_controltemplates/15/MyApp/MyAppScriptReferences.ascx" Sequence="21">
    <Property Name="Minimized">false</Property>
  </Control>
</Elements>

Note the path to my user control, in SharePoint 2010, the path would look different.

Deploy your solution and get ready to see it in action. I have two FEATURES and I have activated the minimized version as shown below:

 

When minimized version FEATURE is activated, I enjoy the performance benefits of minimized version of my scripts.

If I want to debug my JavaScript, all I need to do is deactivate the old feature and activate the feature which provisions regular debug version of scripts. As soon as I do that, regular JavaScript becomes available as shown below:

I think this is very convenient but it may not be necessarily the best option. If you find this useful or have a better idea, please leave comments below.

Technorati Tags: SharePoint,SharePoint 2013,SharePoint 2010

SharePoint Productivity Tip: Windows Search Service

As a SharePoint Developer, I often need to look into the SharePoint hive to look for Features, List Templates, Layouts etc. For instance, if you know the Feature ID and want to locate the Feature in SharePoint hive (14-hive for SP10, 15-hive for SP13), you are out of luck if you search for the Feature ID using windows explorer. Below is the screenshot:

So what do we do? It seems you have to depend on window’s search infrastructure which is not installed by default on most SharePoint development server.

At high level, you need to install the Windows Search Service and Add 14/15 hive to the indexed location and let the search service finish the indexing.

Here is what I did on Windows Server 2012:

• Go to Server Manager and Select “Add Roles and Features” from Manage option in top right corner.
• Select the Windows Search Service option and finish the installation

• You may have to restart the server at this time
• Locate the “Indexing Options” in the windows settings
• Add 14/15 hive to the indexing options as shown below

• Let windows finish the indexing. On my PC it took less than 5 minutes, the exact time may vary depending on your machine configuration!

Now, its time to get excited! Look for the original search term that you were looking for and see it yourself!

Here is another example: I wanted to see how does SharePoint use AdditionalPageHead delegate control and so I looked for that word now in 15-hive (another tip is to add 14/15 hives into Libraries as highlighted below in green) and wow here is exactly what I was looking for!

Trust me! Serious SharePoint developers need this frequently and I am sure it will increase your productivity! Good Luck…

And yes, feel free to leave comments and tell me how it helped you…

Spinning SharePoint Timer Jobs from Site Collection Configuration

My recent content management engagement required to have several long running jobs or tasks that must run in background. For instance:

1. Analyzing Checked out files and sending reminders to the individuals if the number of days (since the file was checked out) exceed certain threshold limits

2. Removing links from other content when a particular content is removed or archived from the system

3. User wants to see all the alerts that he subscribed in all webs in the site collection

4. Sending a reminders to authors to review the content when a review time was specified in the content and that date is approaching

wow, the list goes on…

Well, we could have created one timer job for each scenario and scheduled them at different time. While that is perfectly fine, had some additional design goals for which this approach fall short. Our primary goals were:

1. Ability to monitor the background job and check its status right from site collection, without logging on to server on which it was run and go through ULS logs

2. Ability to run the job on demand without requiring farm level permissions

3. Ability to look into all individual tasks that the job performed and receive an email if anything unusual happened during the execution.

4. Ability to spin up a one time timer job based on an action by an end user and the timer job sends the required information or processes the request later.

So, I came up with a custom architecture which satisfies all of the above goals and achieve even more. While, I won’t be able to share the code because of confidentiality, I can share the details of the architecture. Please feel free to leave comments or contact me if you like the approach and need additional detail.

Here are the main components of this timer framework:

1. When a feature is enabled at Site Collection level, the framework creates two lists: Task Definition List, Task Trace List.

In task The Task definition list contains at least following information:

• Title of the Task as it appears in the timer job definitions on central admin
• GUID to track this definition
• Schedule – to store an XML based schedule definition for the timer job
• Schedule Type: matches with SharePoint Schedule Types such as one time, hourly, weekly etc.
• Trace Level – one of the few trace level that my framework supports. A concept similar to OTB diagnostic logging
• Provisioning Status – a status which shows whether a corresponding SharePoint timer job is created or not
• Assembly – Full Name of the assembly which contains the execution code of this timer job
• Class – Full name of the class which is derived from our custom interface ITimerTask interface
• TaskData – A random XML data that your timer job needs. Framework will automatically make this data available when above Class is called when the timer job runs
• NotifyTo – Can contains email address of person(s) who is interested in knowing the status of the timer job. The framework takes care of sending the email notification when developer sets the status of the job to anything other than “Success”

The Task Trace list contains at least following columns:

• GUID – Identifies the corresponding timer job definition
• ExecutionDateTime – Date and time when the timer job was executed
• Status – Custom Status such as Success, Warning, Failed, SuccessWithWarning, FailedWithWarning etc.
• Trace – Contains detailed trace information registered by developer while implementing the execute method of custom ITimerTask interface. Framework takes care of putting the trace information in this list. All that developer needs to to is call a method. For example, .RegisterTrace (“required list was not found”, TraceLevel.Warning)

2. A Web Application level feature is installed by the framework which creates two timer job definitions at Web Application level: Timer Task Scheduler Job and Timer Task Cleanup job.

Let’s see what exactly they do!

TimerSchedulerJob runs at a regular interval (say 5 minutes) and looks for any un-provisioned job in the The Task definition list that I mentioned above. Once it finds, it create a SharePoint Timer Job and schedules it as specified in the definition list. This newly created timer job is a generic timer job, all it does is loads the assembly and the class specified in the definition, prepares the required data for the job and calls the execute method. That means developer’s implementation of Execute method of my custom interface gets called.

Developer of this framework is responsible for:

• Getting the required data passed as Execute method parameter, along with lot of other information like an instance of SPSite object in which the definition was created
• Write core logic
• Set the final status of the job
• Register all required trace messages by calling method parameter’s RegisterMessage method

After calling the execute method, framework looks at the registered trace messages and the status of the task set by developer. The framework sends email notification specified in the definition. The framework also creates an entry in the Timer Task Trace list at the site collection level that I specified above.

Aha! so finally all dots are connected!

Finally, the Timer Task Trace clean up job removes the trace older than pre configured number of days.

So here is the experience of creating a new timer job for a developer, once the framework is enabled using Web App and Site Collection level feature:

1. Create a class derived from ITimerTask class of my framework which has just one method called Execute
• The core responsibility of a developer in order to use the framework effectively are specified above..
2. Deploy the assembly to GAC
3. Create a definition in the Timer Task Definition list at site collection level. Alternatively, create the onetime definition dynamically on click of a user action
4. Monitor the log and see what happened when the framework executed the timer job defined in the definition.

This is one of the most useful framework that I have built and the developers in the team love it because it opens up a lot of possibilities. My developers don’t need to learn how to develop a timer job but they are able to create one and execute them with so much ease. Without a doubt this is my favorite too!