Narasimha SharePoint 2013: 2013

Tuesday, 24 December 2013

Pie charts using JQuery

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<script type="text/javascript" src="https://www.google.com/jsapi"></script>

</head>
<body>
<div id="piechart_3d" style="width: 900px; height: 500px;">
<script type="text/javascript">
google.load("visualization", "1", {packages:["corechart"]});
google.setOnLoadCallback(drawChart);
function drawChart() {
var Consumed = 5400;
var PlannedAvailable = 200;
var Unplanned = 400;
var data = google.visualization.arrayToDataTable([
['Hours', 'Hours per Day'],
['Consumed', Consumed],
['Planned Available', PlannedAvailable],
['Unplanned', Unplanned]
]);
var options = {
title: 'Project Hours',
is3D: true,
};
var chart = new google.visualization.PieChart(document.getElementById('piechart_3d'));
chart.draw(data, options);
}
</script>
</div>
</body>
</html>

Wednesday, 27 November 2013

Sandboxed solutions in SharePoint 2013

SharePoint 2013 introduces the new SharePoint App model that essentially replaces the sandbox model of solution development. Apps are self contained and easily deployable even more so than sandbox solutions ever were in SharePoint 2010. Microsoft recommends to use apps rather than farm solutions whenever you can. Apps have the following advantages over farm solutions.

They provide users with the easiest discovery, purchase, and installation process.
They provide administrators with the safest SharePoint extensions.
They provide you with the simplest marketing and sales system based on a Microsoft-provided online app store.
They maximize your flexibility in developing future upgrades.
They maximize your ability to leverage your existing non-SharePoint programming skills.
They integrate cloud-based resources in smoother and more flexible ways.
They enable your extension to have permissions that are distinct from the permissions of the user who is running the app.
They enable you to use cross-platform standards, including HTML, REST, OData, JavaScript, and OAuth.
They enable you to leverage the SharePoint cross-domain JavaScript library to access SharePoint data. Alternatively, you can use a Microsoft-provided secure token service that is OAuth-compliant.
They can extend SharePoint Online websites as well as on-premises SharePoint websites.

Of course, farm solutions are still required in some instances where you need to run code on the server directly. The app model does not allow running code on the Server object model but uses the following APIs to access SharePoint:

SharePoint REST/OData service to access SharePoint sites, lists, and other data.
SharePoint JavaScript, Silverlight, or .NET Framework client object models.
On Windows Phones, you can use the SharePoint Windows Phone object model.

The general guide is that farm solutions are still used for administrative type solutions that would deploy timer jobs, central administration features, PowerShell commands, etc. anything that would be of WebApplication, Farm, or Site Collection scoped. A guiding principle being that apps are for end-users and farm solutions for administrators.

For more specification please go through bellow link.

http://msdn.microsoft.com/en-us/library/jj163114(v=office.15).aspx

Types of Event Receivers in SharePoint 2013

As SharePoint 2013 offers App development as part of Office 365 development suite, which also replaces the traditional sand-boxed solutions available in SharePoint 2010, it becomes very easy to create apps and maintain them within SharePoint 2013.

Event receivers are somewhat modified for SharePoint 2013 into two parts, namely

Remote event receivers and
App Event receivers

I will write separately about how to create both of these event receivers in my future posts. In this blog I will explain what they are and how they can be used to suit our business needs.

Remote Event Receivers

These event receivers signify events that occur on items within any list or library. Say addition of an item, update of an item or deletion of an item. They can be synchronous and asynchronous in nature. Microsoft has modified a bit in this version of SharePoint, the way we deal this nature of event receivers. We will see it how later in this post.

App Event Receivers

These event receivers signify the events that occur to the app we are creating. Say app installation, app uninstalling or app upgrading.

As we create a new remote event receiver or app event receiver in Visual Studio 2012, we need a web application where we would be deploying our app. By default the scope of the app will be the host web application mentioned. A web service is added to this web application to handle the events which contains two methods

ProcessEvent()

Handles events that occur before an action occurs, such as when a user adds or deletes a list item

ProcessOneWayEvent().ProcessEvent()

Handles events that occur after an action occurs, such as after a user adds an item to a list or deletes an item from a list

Like in SharePoint 2010, we had synchronous and asynchronous event receivers, in 2013; we have these two methods which deals with the nature of the event receivers.

Many other things remains same the way we used to deal with them in SharePoint 2010 and VS 2010 environment like adding more events within your event receiver solution, changing the event receiver to point to either Document Library or an Announcement list and so on.

I will write more as and when I try new things within SharePoint 2013.