Developing, Integrating, and Building Applications in Sharepoint 2013 (part 4) - Events and Logic Integration

2.2 Events and Logic Integration

Providing a UI for users is usually the most prominent aspect of any application. However, responding to the actions users take either within an application, or to interact with an application, is also extremely important. SharePoint applications provide the ability to both respond to activities within your application (such as a button click) and respond to activities within SharePoint (such as a document being checked out).

Responding to activities within your application is very straightforward. Your application’s UI and code run remotely from SharePoint and are simply surfaced via App Parts and Pages. For that reason, responding to an event such as a button being clicked in your application is entirely tied to your application’s programming framework. For example, if your app is built with ASP.NET then you simply catch the OnClick event for an ASP.NET button. SharePoint does not get in your way for these types of events.

The following exercise shows you how to add code behind a button in your SharePoint application that responds when it is pressed.

Responding to Events Within Your Application (EventsandLogicintegreation.zip)

In this exercise you add a button to your application and include code that is run when it is pressed. You must have completed the “Building Your First SharePoint Application” in the “App Parts and Pages” section before starting this example.

1. Ensure you have the MyFirstSharePointApp solution open in Visual Studio 2012.

2. Open the Default.aspx file under the MyFirstSharePointAppWeb project.

3. Insert the following code directly after </div>.

<asp:Button ID="Button1" runat="server" Text="Do Something" 
OnClick="Button1_Click" /><br />
<asp:Label ID="txtUser" runat="server" Text=""></asp:Label>

4. Open the Default.aspx.cs file.

5. Replace the Page_Load method with the following code:

protected void Page_Load(object sender, EventArgs e)
{
    var contextToken = TokenHelper.GetContextTokenFromRequest(Page.Request);
    var hostWeb = Page.Request["SPHostUrl"];
 
    if (!IsPostBack)
    {
        Button1.CommandArgument = contextToken;
 
 
        using (var clientContext = 
TokenHelper.GetClientContextWithContextToken(hostWeb, contextToken,
 Request.Url.Authority))
        {
            clientContext.Load(clientContext.Web, web => web.Title);
            clientContext.ExecuteQuery();
            Response.Write(clientContext.Web.Title);
            clientContext.ToString();
        }
    }
}

The Button1.CommandArgument = contextToken; line ensures that the contextToken is stored for later use on postback events when the button is clicked. You need it to make subsequent CSOM calls.

6. Add the following new method after the Page_Load method:

protected void Button1_Click(object sender, EventArgs e)
{
    var contextToken = ((Button)sender).CommandArgument;
    var hostWeb = Page.Request["SPHostUrl"];
 
    using (var clientContext = 
TokenHelper.GetClientContextWithContextToken(hostWeb, contextToken,
 Request.Url.Authority))
    {
        clientContext.Load(clientContext.Web.CurrentUser);
        clientContext.ExecuteQuery();
 
        txtUser.Text = clientContext.Web.CurrentUser.LoginName; 
    }
}

7. Press F5 to package and deploy your application.

8. After your app deploys, add your app’s App Part to the homepage of your site by clicking Page ⇒ Edit ⇒ Insert ⇒ App Part. Select MyAppPart from the list and then click Add.

9. Inside your App Part you should now see a button called Do Something. Click it.

10. You should now see your full login name displayed directly below the button, as shown in Figure 14.

FIGURE 14

How It Works

In this exercise you added a button to your application and responded to it being clicked. Nothing is particularly special about this button over and above a standard ASP.NET button; however, it is worth understanding the role of the contextToken and the need to keep it between postbacks to your code so that further calls to the CSOM can be made. In the exercise you stored it in the CommandArgument for the button; however, the same could have been achieved in a variety of other ways, such as a hidden control on the page. The important thing is that it is in a location that you are able to retrieve at a later time during a postback event — you need this context in order to call SharePoint via the CSOM on subsequent requests.

---

For responding to events that occur inside SharePoint, such as a document’s being saved or updated, SharePoint provides event receivers. In SharePoint 2010 developers could use event receivers to receive events from SharePoint when a user took certain actions such as checking in a document or saving a list item. SharePoint 2013 also provides event receivers that allow applications to respond to events occurring within a SharePoint site. The primary difference from SharePoint 2010 is that event receivers now trigger code that runs remotely outside the SharePoint process in your application’s code. They do this via a commonly defined Web service interface. This means the code that you want to respond to events could reside in almost any system you like, as long as it is callable over HTTP/HTTPS from the SharePoint Server or Office 365. An example might be your application code that runs in Windows Azure.