Here is how you can add very easily a ListViewWebPart to a SharePoint wiki page. I've used this code in a provider hosted app for SharePoint online, but of course this will work on-premise as well.
In this example I'm using again the powerfull extensions methods of OfficeAMS.
In SharePoint 2013 list view web parts are still the same xsltlistviewwebparts that we are used to work with. The only difference in this new version is that we have the ability to overwrite the rendering on the client side by making use of JS Link.
A little bit of background information: a remote event receiver is binded to a list, OnItemAdded, I'm creating a new SharePoint site which I'm provisioning with CSOM. I need a document library, a page and a ListViewWebPart of the document library on the wiki page.
You'll have noticed that the WebPartXml property of the WebPartEntity contains a reference to my globals class. In this class, I've created an xml snippet which I can reuse if I want to add a xsltlistviewwebpart to a page. Using this snippet requires 2 params, the List.Id and a title for the web part. Feel free to adapt this snippet for your requirements (toolbar, JS Link reference...)
In a next post, I'll show you how to adapt the view of the webpart.
Monday, July 21, 2014
Friday, July 11, 2014
Register remote event receiver (RER) with CSOM
I'm currently working on a provider hosted SharePoint 2013 app. The aim is to build a self provisioning app by making use of the client side object model (csom).
The remote event receiver is a .svc service hosted on the remote web of the provider hosted app. In my example I'm using Azure.
In fact, binding the RER isn't rocket science, but since the ReceiverUrl property is set to the absolute address of the .svc we won't be able to debug this thing. If we want to debug a remote event receiver hosted on Azure we have to make use of an azure service bus.
This is why I'm using the #if DEBUG directives of visual studio. If in debug mode, I'm overwriting the absolute .svc url in the following format:
https://server.servicebus.windows.net/computer/account/obj/guid/EventReceiver.svc
This raises the question, what are the computer, account and guid parameters in this URL? I figured out these values by opening the .debugapp package that is generated by visual studio during debugging.
While debugging you can find this package in the debug folder of your project.
Extract this .debugapp package and open the AppManifest.xml file in a text editor.
The InstalledEventEndpoint contains all the values your are looking for.
In an old fashion way, provisioning of site columns, content types, lists... was done with declarative coding. Unfortunately, declarative host web provisioning isn't possible. Luckily for us developers, the OfficeAMS contributors are working hard on building nice extension methods to speed up SharePoint development.
in the following example I'm provisioning the host web during the AppInstalled event.
- creating a new list
- binding the remote event receiver to the newly created list
In fact, binding the RER isn't rocket science, but since the ReceiverUrl property is set to the absolute address of the .svc we won't be able to debug this thing. If we want to debug a remote event receiver hosted on Azure we have to make use of an azure service bus.
This is why I'm using the #if DEBUG directives of visual studio. If in debug mode, I'm overwriting the absolute .svc url in the following format:
https://server.servicebus.windows.net/computer/account/obj/guid/EventReceiver.svc
This raises the question, what are the computer, account and guid parameters in this URL? I figured out these values by opening the .debugapp package that is generated by visual studio during debugging.
While debugging you can find this package in the debug folder of your project.
Extract this .debugapp package and open the AppManifest.xml file in a text editor.
The InstalledEventEndpoint contains all the values your are looking for.
Labels:
App,
CSOM,
Office365,
SharePoint Online,
Visual Studio
Thursday, July 3, 2014
Copy a file across site collections with REST
I had to give the users the possibility to copy a file from the SharePoint search results to a document library in another site collection. This requirement resulted in the following custom display template: when clicking the 'Copy to other site collection' button, a div is expanded and shows a text box to provide a new filename and 2 radio buttons to select the target document library.
This example was built for SharePoint 2013 online but works on premise as well.
All the code is based on the example from Mikael Svenson. Since he is copying a file from appweb to hostweb he is using the SP.REquestExector javascript library. When I first read his article I thought this technique wasn't usable for my problem because I was going to copy files within the same domain.
Altough the SP.RequestExecutor library is a cross-domain javascript libary, this library is perfectly usable to use within the same domain. And it is fixed, so the patching described by Mikael isn't required anymore :)
This example was built for SharePoint 2013 online but works on premise as well.
Labels:
Copy file,
CSOM,
JSOM,
Office365,
SharePoint,
site collection
Subscribe to:
Posts (Atom)