Штомесячны архіў: Студзень 2015

HTTP 406 Памылка пры выкарыстанні Вуглавая $ http.get супраць REST End SharePoint кропак

2 адказы

Абнаўленне: Marc AD ndersson pointed out this great piece of info: HTTP://blogs.office.com/2014/08/13/json-light-support-rest-sharepoint-api-released/. That explains a lot :).

That may be the worst title of a blog post ever! Anyhoo.

I typically do all of my prototyping against an O365 instance. I have my personal instance so that I don’t have to be worried about affecting anyone else. As an aside – remember when we call carried around virtual machines on our laptops with MOSS – SQL Server, IIS, deciding Hyper-V vs. VMWare? Anyhoo…

I had developed an app using Angular in this environment that does, між іншым, гэта:

$http.get(serverUrl)
.success(функцыя(дадзеныя, статус, headers, конфіг) {

var getLinksResponse = data;

getLinksResponse.value.forEach(функцыя(theResult) {

// and so on and so froth

This was working just fine in two different SharePoint online environments. Аднак, when my colleague ported it to a Cloudshare instance, he was getting an HTTP 406 памылка (which was the first time I ever got that one, so … yay, I guess). We did a bit of research and noticed that the “Accept” header was off. SharePoint online was perfectly happy with:

Accept: application/json

But the cloudshare instance (which is SP on prem, hosted in a virtual server) wanted the classic “odata=verbose” added in as well:

Accept: application/json;odata=verbose

To fix that, we added the header as such:

var config = {headers: {
‘Accept’: ‘application/json;odata=verbose’
}
};

$http.get(serverUrl,конфіг)
.success(функцыя(дадзеныя, статус, headers, конфіг) {

var getLinksResponse = data;

getLinksResponse.value.forEach(функцыя(theResult) {

// and so on and so froth

That got rid of the 406, but it also changed the format of the response. It was more … verbose. (haha!) More changes were required and here’s the final result:

var config = {headers: {
‘Accept’: ‘application/json;odata=verbose’
}
};

$http.get(serverUrl,конфіг)
.success(функцыя(дадзеныя, статус, headers, конфіг) {

var getLinksResponse = data;

getLinksResponse.d.results.forEach(функцыя(theResult) {

// and so on and so froth

This only turned into a 30 minute problem for us, so we lucked out. Hopefully someone finds this useful.

</канец>

Як да: Дазволіць некалькі Вуглавая вэб SharePoint частак на той жа старонцы

5 адказы

This blog posts describes how you can have multiple Angular.js based SharePoint web parts (referenced via a content editor web part) on the same page. I’m calling a content editor web part (CEWP) that references JavaScript built using the Angular.js framework an “Angular Web Part.”

Angular’s bootstrap process is super easy and just about every example you find on the internets goes something like this:

<html ng-app=’myApp’>

<blah/><blah/><blah/>

</HTML>

This breaks down, аднак, if you want to enable multiple CEWP’s representing multiple angular web parts on the same page. Angular will only automatically bootstrap against the first ng-app directive it finds – at least as of angular version 1.3.6. The solution is pretty simple – manually bootstrap your code instead. The above now changes to something like this:

<цела>
<рэiv id=”bootstrapHere” ng-controller=”myController as theController”>
<blah/><blah/><blah/>
</спраў>
</цела>

<script src=”//ajax.googleapis.com/ajax/libs/angularjs/1.3.6/angular.js”></сцэнар>

<сцэнар>
angular.bootstrap(angular.element(document.getElementById(“bootstrapHere”)),[‘myApp’]);
</сцэнар>

У асноўным, instead of using ng-app on the element to do your bootstrapping, you slap an ID onto that element. Затым, use the bootstrap() method on angular itself to control the bootstrapping process at run-time. I’ve tested this with three different Angular web parts on the same page and it works a charm.

</канец>

undefinedПадпісацца на мой блог.

Выконвайце за мной на Twitter у http://www.twitter.com/pagalvin