Liam Cleary [SharePoint MVP]: Posts http://blog.helloitsliam.com/Lists/Posts/AllPosts.aspx RSS feed for the Posts list. Sat, 18 May 2013 11:11:00 GMT Microsoft SharePoint Foundation RSS Generator 60 en-US Liam Cleary [SharePoint MVP]: Posts http://blog.helloitsliam.com/_layouts/images/siteIcon.png http://blog.helloitsliam.com/Lists/Posts/AllPosts.aspx SharePoint 2013 Hosted Apps – Do they really work? Part 3 http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=114 Body:

In our last post we made changes to our SharePoint 2013 Hosted App, to use the REST API to get list items that were selected from a list. When you clicked on the Ribbon button it sent the selected items to the "default.aspx" page of the App Web and rendered them accordingly. The code we used for rendering the selected items was not ideal as we just asked the REST service to give me everything and then filter out the ones that are not in the query string. As you can imagine not the most performing code you could write.

To make this better and faster one of the new features of the REST API is to pass filters directly to the call. Firstly let's look at the syntax, we can use. We can test this by using the following URL against our Office 365 site.

https://demo.sharepoint.com/sites/appdev/_api/web/lists('{List_ID}')/items

This will let you call the REST API directly and see an RSS feed type result come back. Some basic examples would be to specify the fields that come back. To do this the URL would need to be the following:

https://demo.sharepoint.com/sites/appdev/_api/web/lists('%7BB6F5FCC8-5102-4F1B-9F24-D8929162CB51%7D')/items?select=Title,Body

When this is ran you should see the following:

This does not really help us as we would like to see the core XML, I use Fiddler for this, so when you call the URL you are able to inspect the response. You will see a get request similar to this:

If you select that line and then select the "Headers" tab on the right and choose "XML" from the bottom you should see the returned XML response.

This just helps me see that the right XML is being returned. Using the "$select" parameter we can specify as many fields as we wish or simply remove it to show all fields.

Now back to the original issue, we want to only retrieve the selected items form the REST API call, not all of them and filter. So we can now use another parameter "$filter". As a simple example let's retrieve one of the items from our "Announcements" list.

https://demo.sharepoint.com/sites/appdev/_api/web/lists('%7BB6F5FCC8-5102-4F1B-9F24-D8929162CB51%7D')/items?$filter=ID eq 3&$select=Title,Body

This URL will render the following:

And out Fiddler trace shows the following:

So what if we wanted to filter on multiple values, so in our example let's say we had selected items 3 and 2. Our new filter URL would be the following:

https://demo.sharepoint.com/sites/appdev/_api/web/lists('%7BB6F5FCC8-5102-4F1B-9F24-D8929162CB51%7D')/items?$filter=ID eq 3 or ID eq 2&$select=Title,Body

Our fiddler trace will now return the following:

So to tie this all together we need to change out code in the "App.js" to be the following so it only returns the selected items. Firstly we need to modify the following code:

This creates a new variable to contain a dynamic query. We then modify the core document ready code to not run and simply show us an alert box saying the "selectedids" variable is not populated, in the real world you would change this behavior of course. We then wrap a call to the "getSelectedItemIDs" and the rest of the core code to ensure it does not run when nothing has been selected. Now we need to modify the core method "getSelectedList" to contain a filtering option.

We also need to remove the last code we used in the "getListSuccess" method as we are no longer getting all the items and filtering through the loop process.

Lastly we need to create the new method "getSelectedItemIDs" which simply splits the query string that contains the selected IDs from the list, loops through them and creates an output that renders like this:

Now when we run the code, we are able to select values and when we click the ribbon button will render only those, by using the REST API query to just get those items.

So to recap we have looked at using the selected items query string, passing it into the REST API call after dynamically create the filter clause then rendering the values out on the page. In the next post we will look at creating the rest of the user interface such as the grid for the specific fields we want to show.

Category: SharePoint 2013; Development; How To Code; Ramblings; SharePoint
Published: 4/10/2013 2:35 PM
]]> liam.cleary SharePoint 2013; Development; How To Code; Ramblings; SharePoint Wed, 10 Apr 2013 19:33:36 GMT http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=114 SharePoint 2013 Hosted Apps – Do they really work? Part 2 http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=113 Body:

So in part 1​ we looked at some basic concepts of creating a SharePoint 2013 Hosted App. In this post we will continue with our demonstration app and look to expand it further. We left off with a custom ribbon action that redirects to a page within the App Web and simply just uses the default code from the "App.js" to render your display name. As a recap the design we are looking for is to allow a user to select items from a list and then when they click the ribbon be redirected to the App Web and render a grid type view of just the selected items, which we learned from the last post we can get by using query string parameters. So to start we need to open the "App.js" file and look at the existing code.

 

This code is very straight forward, as it simple gets a context for SharePoint using the client object model, grabs the current web which in this case is the SharePoint site you clicked the ribbon button from and then gets the "Current User" which would be you right now. When the document is loaded which is checked with the following code:

 

A custom function called "getUserName()" is called which loads the current user and executes an asynchronous query which on success writes out the name that you see on the page.

 

So let's look at changing this to retrieve data about the SharePoint Site using the REST API that is now available in SharePoint 2013. First off we will need to add the following to the "Default.aspx" page markup.

 

Now we need to remove the current code from "App.js and add the following section first.

 

This code declares two variables, then loads them upon document ready from the query strings that are passed in the URL. It then loads a JavaScript files that is used to execute code, and we make a call to a custom method we create called "getSelectedList". The "getSelectedList" method for now is not actually getting a list, it will be retrieving the SharePoint Site Title, confusing I know but easier than changing all the code each time.

 

This method makes a call to the "_api" URL of SharePoint which an endpoint for the web services / WCF for the client object model components of SharePoint 2013. To read more about this, read the details on MSDN here:

http://msdn.microsoft.com/en-us/library/jj860569.aspx

In our custom method you will see that we have a success and error call to two methods shown below:

 

These methods simply either render an error or the SharePoint Site Title onto the "Default.aspx" page. We also have a helper method for parsing the query strings so we can use them through the code.

 

Now we have all the plumbing done we should be able to build and deploy our solution and it should render as shown below once we click the ribbon button.

 

If we debug the code by adding a break point in the "App.js" we can see that we are getting an "Access Denied" error.

 

 

This means that the current account is not allowed to access the root web properties. This is by design and this brings me to another consideration when designing a SharePoint 2013 Hosted App. You need to work out the permission level that you want to assign so when it is deployed the right trust level is set ready for use. To set the permission, double click the "AppManifest.xml" file in Visual Studio. Select the "Permissions" tab and you will be presented with the following screen:

 

Set this screen to the following:

 

Rebuild the solution deploy using "F5" as always from Visual Studio. This time when you deploy you get stopped halfway through and are asked to trust it.

 

Select the "Trust It" button and the page will load as shown below:

 

So the key here is that by design the end user who is accessing your application is NOT allowed to perform certain functions unless the trust level has been set in the App and accepted during installation. So now we have it working with SharePoint Site data, now let's change the code a little to retrieve a specific list from the site. First off ensure you have an announcements list with some items within the SharePoint Site you are using.

Modify the "Default.aspx" page to now have the following code, you can remove the last markup we added.

 

We now need to modify the custom function we wrote to now use the following:

 

The success and failure method also need to be changed slightly too.

 

As before now build and deploy using Visual Studio so we can debug if needed. Accept the "Trust" and it should render as shown below:

 

Now that we are able to render the values let's make some changes to the code so it will work for any list that we decide to click the ribbon button from. To do this lets first look at the URL:

https://demo-5551df50f28634.sharepoint.com/sites/appdev/DemoApp/Pages/Default.aspx?SPHostUrl=https%3A%2F%2Fdemo%2Esharepoint%2Ecom%2Fsites%2Fappdev&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4454%2E1034&SPAppWebUrl=https%3A%2F%2Fdemo%2D5551df50f28634%2Esharepoint%2Ecom%2Fsites%2Fappdev%2FDemoApp&SelectedList={B6F5FCC8-5102-4F1B-9F24-D8929162CB51}&SelectedItems=3,2

If we look in the link above we have the query string from the last post already in there, which is "SelectedList={B6F5FCC8-5102-4F1B-9F24-D8929162CB51}", this means we already have the list ID so if we modify the code a little we should be able to use this dynamic value, instead of hard coding "Announcements". To achieve this firstly add the following to "App.js".

 

This will get us the list ID loaded into a variable we can use throughout the code. Now we need to modify the "getSelectedList" method code to be the following:

 

Once complied and deployed you are then able to click any list and it should render details as shown below.

Announcement List

 

Contacts List

 

So now we have the code working for any list now we need to look at restricting the list of items that is renders to the selected items that are passed in the URL. We need to change the code in the "App.js".

 

Next we need to change the rendering code to be the following:

 

Now build and deploy from Visual Studio so you can debug and you should now be able to select items within the list and when the page renders it will only display the selected items. Of course there are better way of doing this but we will save that for another day.

In the next post we will look at the options available for rendering more than just "Title" and "Body" fields and actually create the grid view we need.

Category: SharePoint 2013; Development; How To Code; SharePoint; Ramblings
Published: 4/9/2013 9:43 PM
]]> liam.cleary SharePoint 2013; Development; How To Code; SharePoint; Ramblings Wed, 10 Apr 2013 02:42:34 GMT http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=113 SharePoint 2013 Hosted Apps – Do they really work? Part 1 http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=112 Body:

Recently I have spent some time working through building and converting demonstration code across to SharePoint 2013 Apps and have a fun time learning what can be done and really what can't be done. This post is based my practical experience so far of trying to use "SharePoint Hosted Apps" only. The reason for this was to make an App that would work on-premise and on Office 365 with no dependency on managed code but to use pure JavaScript.

So to create a new SharePoint 2013 Hosted App you need to ensure that when you create the project in Visual Studio you select the correct option.

Once the project is created you should get a structure similar to this:

The basic construct is the following:

  1. Feature Folder – Normal SharePoint Feature dialog you have used in the previous tooling
  2. Content Folder – Any specific content that will reside in the App Web, by default the App.CSS file
  3. Images Folder – Images that will reside in the App Web
  4. Pages Folder – The core pages that will reside in the App Web (Core User Experience)
  5. Scripts Folder – Contains all JavaScript files, such as jQuery and the core App.js, once again all hosted in the App Web
  6. AppManifest File – Base configuration and permission sets for the App

If we deploy this solution as is, it will render values that are called from the App.js file. This will display your current display name.

This page is loaded from the App Web, this is the separate web site that gets stood up as part of the new App Model. A SharePoint 2013 Hosted App when deployed does this automatically and crea6es a URL similar to this:

So the first things to note here is that the code and other assets do not live inside SharePoint, so that changes the overall design considerably. So the user experience becomes slightly more complicated than before. Whereas we would write code either full trust or even sandboxed code it would be deployed directly into SharePoint, so simple things such as deploying files like images, CSS or JavaScript to the style library was still supported, now it is not. Sean McDonough has a great blog post about imaging rendering and SharePoint 2013 Apps in General, I would suggest a read:

http://sharepointinterface.com/2013/01/22/custom-ribbon-button-image-limitations-with-sharepoint-2013-apps/

So let's think about an example app we could build. For this demonstration I would like an end user to access a list, see the list items, press a ribbon button, and then popup a dialog over the top listing out the selected items only and then allow the end user to perform some action. I can hear you thinking this is going to be easy. Write a full trust solution that does the following:

  1. Deploys JavaScript, CSS and Images
  2. Adds a Ribbon Button, maybe as a custom "Additional Page Head" control so it shows up on all Ribbon Bars
  3. Uses C# to get the currently viewed list
  4. Uses JavaScript to get the selected items
  5. Opens the Dialog
  6. Loads a custom page, maybe "_layouts" page
  7. Custom Page uses C# to get the currently selected list, renders only the selected items based on what is passed to it

Of course there are many ways of doing this same thing whether using Full Trust C# or Sandboxed Client Object Model code. So how do we do this for a SharePoint 2013 Hosted App. First off let's look at adding a ribbon button. In the Visual Studio right click he project and select "Add New Item". From the list select the "Ribbon Custom Action".

Once selected you are asked to define the type of Ribbon Action. The first thing is where you wish this custom action to reside. The Host Web is SharePoint, the App Web is the funny website that got created in my Office 365 Tenant when I deployed it. As we need this ribbon button to be in the current SharePoint, we will select the "Host Web" option. We also have the ability to scope the action to one of the following:

The interface does not allow for scoping actions to anything other than List Templates and List Instances. Selecting List Template will populate the second dropdown with the available list templates in the SharePoint site that is connected to Visual Studio. If you select List Instance it will populate the dropdown with available lists that are deployed and active in the SharePoint site. For this example we are going to choose "None" as I would like to associate this action to more than one list or template.

The tooling then let's you select the control location from a predefined list:

This list is great but once again does not list every location you would want to use. You can overtype this with your own values if needed. For this demonstration we will use "Ribbon.List.Actions", with the control navigation set to the default page.

Visual Studio will then create the custom action object in the project and the "elements.xml" file is loaded and will look similar to this:

The code looks fairly straight forward and what you would be used to seeing, however notice that the "CommandUIHandler" is a redirect to the following URL:

~appWebUrl/Pages/Default.aspx?{StandardTokens}

You will notice it is using a token for the URL, the "~appWebUrl" is a unique one that SharePoint 2013 understands and will replace at the build and deployment time into the full URL of the App Web, so it will end up being something like this:

You will also see an appended query string of "StandardTokens", this is one of the replacement tokens that are available. This specific one combines five other tokens. "SPHostUrl", "SPAppWebUrl", "SPLanguage", "SPClientTag" and "SPProductNumber". Sahil Malik has a list of all the tokens that are available in SharePoint 2013 Apps and when they can be used.

http://blah.winsmarts.com/2013-2-SharePoint_2013_apps_replacement_tokens.aspx

Let's say we wanted to change this mechanism to use a simple piece of JavaScript. SO something simple like this: "javascript:alert('Hello World');", we would change the XML to be the following:

Now if we build the application is Visual Studio all is well. Now if we try to deploy it something strange happens.

It errors with the deployment saying there are errors in the package. This is because you CANNOT run inline JavaScript inside ribbon actions at all. This is a big difference to the full trust and sandboxed design we currently have in SharePoint 2010. So from a user experience for something like this we would need to explain to the end user that every time they click the ribbon it will take them out of the SharePoint site to perform the task and then we would need to handle through code the redirect back or the end user would be stuck in the app not SharePoint. By default however you will notice that the App Web is styled with a similar chrome to SharePoint itself, along with a link to get back to the site you came from, this will help in the user experience.

So back to performing a redirect, this means we need to write the code in the App Web for getting list items etc. as per our design for this demonstration app. If we change the code back and build and deploy we should be back to the site now. To test the ribbon we can access a list and see in the "Actions" section our new button.

If you click this button it will redirect you to the App Web and show the default page. If we look at the URL we can see the token values:

https://demo-5551df50f2862e.sharepoint.com/sites/appdev/DemoApp/Pages/Default.aspx?SPHostUrl=https%3A%2F%2Fdemo%2Esharepoint%2Ecom%2Fsites%2Fappdev&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4454%2E1032&SPAppWebUrl=https%3A%2F%2Fdemo%2D5551df50f2862e%2Esharepoint%2Ecom%2Fsites%2Fappdev%2FDemoApp

This is great as it already passes a lot of information that we would need to us in the App Web, such as the actual site we are in. We can change our Visual Studio solution to also send us further details, such as the ID's of the selected items, the list ID and name. To do this we need to make changes to the "CommandAction" link. Modify the link to be the following:

Now build and deploy the solution and test the link this time. This time access the list and select a few items as shown below and click the ribbon link and the URL should now be similar to this:

https://demo-5551df50f28632.sharepoint.com/sites/appdev/DemoApp/Pages/Default.aspx?SPHostUrl=https%3A%2F%2Fdemo%2Esharepoint%2Ecom%2Fsites%2Fappdev&SPLanguage=en%2DUS&SPClientTag=0&SPProductNumber=15%2E0%2E4454%2E1032&SPAppWebUrl=https%3A%2F%2Fdemo%2D5551df50f28632%2Esharepoint%2Ecom%2Fsites%2Fappdev%2FDemoApp&SelectedList={B6F5FCC8-5102-4F1B-9F24-D8929162CB51}&SelectedItems=3,2

This time you will notice that we get the list ID and the selected ID's of the values we selected in the list, so now we just have to wire up the new page in the App Web to display these items in a list view type grid.

This design now means that we need to allow the end user to perform the required tasks such as selecting items in SharePoint, send that to the App Web and then re-connect to the SharePoint site and list or library using the client object model or the REST API features. This logic will be added to the "App.js" file which is referenced in the "default.aspx" page.

The "App.js" file allows us to add any JavaScript or JSOM code to connect or interrogate SharePoint. Be aware that this is a subset of the core API that is available in SharePoint. In the next post we will look at writing JavaScript code in the "App.js" along with the pro's and con's to this design.

Category: SharePoint 2013; Development; SharePoint; Ramblings; How To Code
Published: 4/8/2013 11:02 AM
]]> liam.cleary SharePoint 2013; Development; SharePoint; Ramblings; How To Code Mon, 08 Apr 2013 16:01:08 GMT http://blog.helloitsliam.com/Lists/Posts/ViewPost.aspx?ID=112