Beginner HTML5, JavaScript, jQuery, Backbone, and CSS3 Resources
http://www.elijahmanor.com/2013/01/beginner-html5-javascript-jquery.html
Sent via Flipboard
Sent from my iPad
Wednesday, January 30, 2013
Article: Beginner HTML5, JavaScript, jQuery, Backbone, and CSS3 Resources
Beginner HTML5, JavaScript, jQuery, Backbone, and CSS3 Resources
http://www.elijahmanor.com/2013/01/beginner-html5-javascript-jquery.html
Sent via Flipboard
Sent from my iPad
Article: Enabling modern SharePoint experiences on Windows 8 for students and teachers
Enabling modern SharePoint experiences on Windows 8 for students and teachers
http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=1057
Sent via Flipboard
Sent from my iPad
Article: Using JSLink to change the UI of a SharePoint list/view
Using JSLink to change the UI of a SharePoint list/view
http://www.sharepointnutsandbolts.com/2013/01/using-jslink-to-change-ui-of-sharepoint_20.html
Sent via Flipboard
Sent from my iPad
Thursday, January 24, 2013
Sunday, January 20, 2013
SharePoint 2010: Changing the cookie expiration
$sts = Get-SPSecurityTokenServiceConfig
$sts.FormsTokenLifetime = (New-TimeSpan -Days 90)
$sts.WindowsTokenLifetime = (New-TimeSpan -Days 90)
$sts.ServiceTokenLifetime = (New-TimeSpan -Days 90)
$sts.Update()
Article: Configuring Active Directory Import for a SharePoint 2013 User Profile Service Application using PowerShell
Configuring Active Directory Import for a SharePoint 2013 User Profile Service Application using PowerShell
http://www.benjaminathawes.com/blog/Lists/Posts/Post.aspx?ID=42&List=c4ef5a3d-6f2b-40cf-a53d-04e9f3beedd4&Web=b5c13492-56d6-4868-90bf-a96d72070f07
Sent via Flipboard
Sent from my iPad
Monday, January 14, 2013
Sunday, January 13, 2013
Article: Sharing a Workflow Manager 1.0 farm between multiple SharePoint 2013 farms
Sharing a Workflow Manager 1.0 farm between multiple SharePoint 2013 farms
http://www.wictorwilen.se/sharing-a-workflow-manager-1.0-farm-between-multiple-sharepoint-2013-farms
Sent via Flipboard
Sent from my iPad
Thursday, January 10, 2013
Calling SharePoint search using REST (e.g. from JavaScript or an app)
Sent to you by Tinh Do via Google Reader:
via Chris O'Brien by Chris O'Brien on 1/6/13
Sidenote - although this article focuses on search, I've tried to generalize slightly so that it may also be useful for:
- Understanding the pattern for working with *any* SharePoint 2013 REST API (e.g. profiles, taxonomy, querying lists/libraries etc.) – the URL used for the REST call is the main piece that would change
- Seeing (broadly) how to process REST API results formatted in the two available formats - JSON or XML
- Understand how to call a REST API from both a SharePoint-hosted app (JavaScript) and a cloud app (provider-hosted or auto-hosted – C#)
- Briefly discuss using CSOM to call search instead of REST
Often it's valuable to leverage SharePoint services such as search, user profiles, Managed Metadata and so on from an app. With search specifically, an example I've been giving recently is my 'learner' time-tracking app, which displays a 'Related content' bar with links to documents and other things which relate to completing timesheets:
My search query is somewhat simplistic (I'm currently just searching for any documents and pages which contain the term 'timesheets'), but it's easy to imagine that with some refinement we could return only highly-relevant items. A nice approach in real-life could be to have a configurable value to allow each client (who installs the app) to edit/store the search query that works best for them. Regardless, I think the main point is that search can be a valuable 'bridge' between an app and the rest of the SharePoint environment. In my example, consider that:
- As the app vendor, I have no idea what your organization's timesheet policy/guidelines are
- If I can bring in some of your content around this, users will have more success with my app, and that's good for everyone
In terms of implementation, I'll now talk about the basics of accessing search via REST, and also how to do this from an app.
Broadly, the process is:
- Identify (and test) the REST URL to use
- Deal with app authentication if necessary (i.e. you're calling from outside SharePoint, e.g. a cloud app)
- Add a Permission Request to your app, so that a request to use search is successful
- Develop the success handler code to process the results
Accessing search via REST (_api)
The beauty of REST is that it's just a URL, and you can test/refine it in the browser before writing a single line of code. From SharePoint 2013, such a URL takes the format:
[site]/_api/[name of SP API]/[name of operation]?[parameters]
So in the case of search, a basic query can be executed with the following:
[site]/_api/search/query?querytext='timesheets'
If such a URL is entered into the browser address bar, then you should see an XML response like this – you'll find some interesting properties, like those I've highlighted in the images:
Common operations
So far we've just looked at executing a basic query where the query text is specified. Here are a couple of other common operations you might want to do:
| Operation | Sample REST URL |
| Use a search Result Source (i.e. a scope) | /_api/search/query?querytext='search term'&sourceid='B09A7990-05EA-4AF9-81EF-EDFAB16C4E31' (this example is to search the 'People' result source) |
| Specify a start row (i.e. in paging) | /_api/search/query?querytext='search term'&startrow=11 |
| Specify a number of results to return | /_api/search/query?querytext='search term'&startrow=11&rowlimit=10 (but note 10 is the default) |
| Specify particular (managed) properties to return | /_api/search/query?querytext='search term'&selectproperties='Author,Path,Title,Url' |
For a more comprehensive reference, the best source I can find is the SharePoint 2013 Search REST API post in the 'Search Space' blog by 'nadeemis' on MSDN – kudos to the author.
Working with the data
As with other SharePoint REST operations, you can choose to have the data in XML or JSON – and JSON might be preferable if you are in JavaScript. As I've mentioned before, this is accomplished with the "Accept" header – specify one of the following:
- headers: { "Accept": "application/json; odata=verbose" }
- headers: { "Accept": "application/xml" }
Your code which processes the results will need to deal with JSON/XML as appropriate. In either case, you'll usually have some drilling down to do to get the valuable data – for example, the main result rows are in a property called jsonObject.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results (where jsonObject is the object which was parsed from the JSON string). And when you're iterating through the results, if you want the URL for the item, then you can get that from the cell at index 6 with result.Cells.results[6].Value. The title is at index 3, so result.Cells.results[3].Value. These are basically just the things you work out with a JavaScript debugger, or from a code sample like mine below.
Calling the search REST service from the JavaScript Object Model (JSOM)
In this sample, I have a web page which has a DIV waiting to output the search results:
<div id="related-content-results"></div>
If I'm in a page running on SharePoint (including a SharePoint-hosted app), I can use SP.RequestExecutor (as opposed to a jQuery.get() or jQuery.getJson() for instance) and this simplifies things by meaning I don't have to worry about adding an OAuth header to my request. So, this code would look like:
** N.B. My newer code samples do not show in RSS Readers - click here for full article **
Notice a couple of things:
- The URL we're using is the app web, rather than needing to reference the host web somehow – this is fine for search (but isn't for accessing data in the host web, for example)
- We need something to iterate over the result items within the JSON – jQuery's each() operator is a good choice here
- There are some 'magic numbers' in processing the JSON results to get to the values e.g. result.Cells.results[6] to get to the URL of the item. That's just a reflection of the data structure SharePoint returns, and you'll see the same if you're working with XML instead
Calling the search REST service from a cloud app (provider-hosted/auto-hosted) in .NET CSOM
Accessing the search REST API (just like any SP2013 REST API) in other contexts can be a bit more involved. The main consideration is that if your page isn't on the SharePoint server, you'll need to deal with OAuth and adding the 'Authorization' token to the REST request. If you're in C# (i.e. the .NET CSOM), then the TokenHelper class automatically added to your Visual Studio project simplifies this – you'll need to use a HttpWebRequest object (or similar) to call the REST URL, and then process the response. Since I'm on the server this time and have access to .NET, XML could be a better choice here:
And just for clarity, here's my ASPX page which renders this – as you can see, I'm using an ASP.NET ListView control to put the results on the page:
Sidenote: Other contexts – calling SP2013 REST APIs using jQuery in a cloud app
As I worked through these samples, I realized that another useful approach would be calling the REST API client-side from a cloud app (in an AJAX way). In this case, we'd probably be coding in jQuery, and would need to deal with obtaining an OAuth token and adding it to the web request – but in this case, we don't have TokenHelper to support us. Sure, you could perhaps wrap TokenHelper in a WCF service and call that from jQuery, but that would mean an inefficient process of multiple web requests (firstly to the service, then the exchange to get the OAuth token, and finally the call to the SharePoint REST API).
Far better would be to eliminate the extra call and just directly obtain the OAuth token and call the REST URL directly from jQuery – but some work is needed to facilitate this. I'm sure someone will look at this soon as I expect it to be a common pattern for SharePoint 2013 app development.
Using CSOM instead of REST
I actually can't think of too many reasons to do this any more, but if CSOM is your client-side preference you'll want Microsoft.SharePoint.Client.Search.Query.SearchExecutor.ExecuteQuery().
Permission Request for an app to use search
In order to be able to call the search REST API from an app (of any hosting type), the app needs to be granted permission to use the search service – this doesn't happen by default. Like any permission which relates to "core SharePoint" rather than the app itself, the developer must specify the requirement in the form of a Permission Request, and the administrator installing the app must agree to granting this permission at install time.
So, the developer needs to add the following to the appmanifest.xml file:
Note that the value specified for the Right attribute gives a very descriptive string reminding you what's being asked for – although most actions within an app run "as the app's identity" (i.e. as the 'app principal'), the search will instead be performed as the user (with the associated security-trimming).
In the Visual Studio designer for the appmanifest.xml file, this looks like this:
And, of course, when someone is installing (or upgrading) the app, they'll see search listed as one of the permissions that the app requires – and can make an informed decision on whether they are OK with this:
An issue for on-premises deployments?
So everything above works great for Office 365 environments. However, I see something weird when I deploy an app which uses search to my local developer environment. I haven't yet tested the app against another on-premises environment, but I'd be interested to hear if anyone else sees this – the app in fact cannot be added, and I see a message saying "Sorry, only tenant administrators can add or give access to this app":
This is curious to me for a couple of reasons:
- An internet search reveals only one real result (at the time of writing), which discusses this issue happening with Office 365 tenancies during the beta phase - http://social.msdn.microsoft.com/Forums/en-US/appsforsharepoint/thread/97f77aff-e2dc-47eb-be02-22d6c28abfd9
- As a concept, I understand "tenant administrator" to apply to Office 365 environments but not on-premises
So, does anyone else see this? Am I missing something? Please let me know in the comments.
Finally, it's worth pausing to consider – that fetching content via search across an entire SharePoint environment is a fairly elevated level of permission. The app is basically being given access to content created within your business, and anything in the search index is available. Clearly an app could potentially do some 'interesting' things with this, so it might be prudent to do some evaluation of such apps before blindly installing.
Conclusion
Calling into search from an app can be valuable, and here we've looked at how to do it from both a SharePoint-hosted app (in JavaScript) and a cloud app (in C#). The template used here for making such REST calls can be applied to many other operations – ultimately the pattern is to identify the URL, deal with authentication if outside SharePoint, ensure a permission request exists, then drill down in the JSON/XML response to get to the valuable data.
Things you can do from here:
- Subscribe to Chris O'Brien using Google Reader
- Get started using Google Reader to easily keep up with all your favorite sites
Introducing the Content Search Web Part
Sent to you by Tinh Do via Google Reader:
via SharePoint Team Blog by sharepointblog@live.com on 1/9/13
Hi there. I'm Kerem Yuceturk, a program manager in the SharePoint Enterprise Content Management team. I am truly excited to start talking about the Content Search Web Part, one of the most interesting features that we added to SharePoint 2013, and the many scenarios it enables for SharePoint aficionados around the world.
Before I start to talk about Content Search, let me first set the stage by briefly outlining what this Web Part is trying to accomplish. If you ever dealt with publishing scenarios like creating an intranet portal or a knowledge management solution back in SharePoint 2007 and 2010 days, there is a good chance that you were using the Content Query Web Part. Content Query is great for showing dynamic content based on a set of criteria that you've set. So if you wanted to show a list of news articles on the intranet homepage, or to roll up a list of sales reports on your knowledge center, Content Query was the way to do it.
There was one catch though: If you ever wanted to show items that were not in the same site collection, you were out of luck. The scope of the Content Query Web Part was (and still is) limited to the site collection that the Web Part is placed in.
In SharePoint 2013, FAST Search and SharePoint Search fused together and got deeply integrated into SharePoint. As part of that change, we added a new tool for publishing content for your intranet or Internet site that knows no site-collection boundaries. This tool is the Content Search Web Part.
Content Search can show anything that's in the search index including content across site collections, and even content that comes from outside of SharePoint as long as it was crawled and placed in the search index. If search crawls it, you can display it, no matter where the content lives—provided the user viewing the page has permissions to see the item in question. Plus, thanks to the analytics capabilities that are built into SharePoint 2013, it can also show recommendations and popular items based on usage patterns.
If this sounds like something you want to try out, you can find Content Search in your SharePoint farms by going to the Web Part adder, and choosing the Content Rollup category. (Content Search is not available on Office 365 right now, but we are working on enabling it in the future.)
Figure 1. Two Content Search Web Parts from different contexts: on the left an intranet site that displays some PowerPoint files from another site collection, on the right the Contoso Electronics site that displays some items from the product catalog
At a very high level, using Content Search is easy by following these two steps:
- Choose the items to show (formulate a search query that will return those items as results).
- Format the items the way you want (use Display Templates to customize how items look).
Choosing the items to show
The Content Search Web Part boasts a full-screen query builder that has several preconfigured queries to get you started, and a panel for previewing the results to enable you to tweak your query. It's fully integrated with the new search concepts of SharePoint 2013, like Results Sources and Query Rules, and can use these to get to results. It also has an advanced mode: basically, an enlarged search box where you can write any query using Keyword Query (KQL) syntax, which you can then try out by using the preview panel.
Figure 2. Query builder with tools on the left and preview of results on the right
Content Search also supports a rich set of dynamic values (also called query variables) to be used in queries such as today's date, the name of the current user, any field from the current page, or a custom property from the current web's property bag. Query Builder and dynamic values each deserve blog posts of their own, but for now, you can try out the following query variables in your queries if you want to explore some of the possibilities:
{Today-7}: The date for a week ago, great for "what's new this week" queries.
{User.Name}: The name of the current user. Great for surfacing content for the user who is viewing the page. Also works for any property, including custom properties from the current user's profile.
{Page.MyCustomTextField}: Gets the value of a field that you added to the content type you're using on the page.
{Site.URL}: Gets the current site's URL, or any custom property. Also works for SiteCollection.
{Term}: The current term from managed navigation. For more information, see the blog post Getting friendly with FURLs.
Formatting the items the way you want: Display templates
One of the main pain points we kept hearing from customers was about how irritating it is to use XSL to format the output of a Content Query Web Part. XSL is a relatively obscure web technology and it has a reputation for making most seasoned folks go scratch their heads about the syntax whenever they try to do something a little unusual while formatting the results.In SharePoint 2013, there is a new way to format items shown in Content Search Web Parts using HTML and JavaScript instead of XSL: Display templates.
Display templates make it significantly easier to:
- Specify what managed properties to retrieve from search.
- Manipulate values of the retrieved managed properties in JavaScript, as needed.
- Display the values in HTML in the browser.
Figure 3. Same search results displayed using three different sets of display templates in each of the columns
Display templates are located in the master page gallery of your site collection. There are several display templates that come pre-installed in a folder named Display Templates for your convenience, so feel free to browse around that folder if you'd like to get a feel for them. The best way to create a new display template is to copy one of the existing ones, and change its properties and content. Note that you should always deal with the .html files in those folders; .js files are auto-generated by SharePoint whenever you modify an .html file of the same name.
Display templates also deserve another blog post to do that topic any justice, so let me wrap this section up here to keep this post short and sweet.
Conclusion
I hope this gave you a taste of what the Content Search Web Part can do for you in your SharePoint deployments. Be sure to look for future posts that will go into more detail about some of the concepts introduced here.Things you can do from here:
- Subscribe to SharePoint Team Blog using Google Reader
- Get started using Google Reader to easily keep up with all your favorite sites
Subscribe to:
Posts (Atom)