Kategori Arkiv: JavaScript

HTTP 406 Fel när du använder kantiga $http.get mot SharePoint resten slutpunkter

Uppdatering: Marc AD ndersson påpekade detta stor bit av information: http://blogs.Office.com/2014/08/13/JSON-Light-support-rest-SharePoint-API-Released/. Som förklarar en hel del :).

Det kan vara den värsta titeln på ett blogginlägg någonsin! Anyhoo.

Jag gör alla min prototyping mot en O365-instans. Jag har min personliga instans så att jag slipper vara orolig som påverkar någon annan. Som en parentes – kom ihåg när vi kallar burna runt virtuella maskiner på våra bärbara datorer med MOSS-SQL Server, IIS, beslutande Hyper-V vs. VMWare? Hur som helst...

Jag hade utvecklat en app som använder vinkelformig i denna miljö som gör, bland annat, Detta:

$http.get(serverUrl)
.framgång(funktionen(data, status, headers, config) {

var getLinksResponse = data;

getLinksResponse.value.forEach(funktionen(Resultatet) {

// och så vidare och så skum

Detta fungerade bara bra i två olika SharePoint online miljöer. Men, När min kollega portat det till en Cloudshare-instans, Han var att få en HTTP 406 fel (vilket var första gången jag någonsin fått det, så... yay, Tror jag). Vi gjorde lite forskning och märkte att "Acceptera" huvudet var off. SharePoint online var helt nöjd med:

Acceptera: Application/json

Utom den cloudshare instansen (som är SP på prem, värd i en virtual server) ville ha klassiskt "odata = verbose" tillagda i:

Acceptera: Application/json;OData = verbose

Att fixa det, Vi lade till i huvudet som sådan:

var config = {headers: {
"Acceptera": ' application/json;OData = verbose "
}
};

$http.get(serverUrl,config)
.framgång(funktionen(data, status, headers, config) {

var getLinksResponse = data;

getLinksResponse.value.forEach(funktionen(Resultatet) {

// och så vidare och så skum

Som fick bort den 406, men det ändras även formatet för svaret. Det var mer... verbose. (haha!) Fler ändringar var nödvändiga och här är slutresultatet:

var config = {headers: {
"Acceptera": ' application/json;OData = verbose "
}
};

$http.get(serverUrl,config)
.framgång(funktionen(data, status, headers, config) {

var getLinksResponse = data;

getLinksResponse.d.results.forEach(funktionen(Resultatet) {

// och så vidare och så skum

Detta bara förvandlats till en 30 minut problem för oss, så vi lucked ut. Förhoppningsvis hittar någon detta användbara.

</slutet>

Kantiga misslyckas att starta i IE9

Jag har spelat med Angular.js för sist långa samtidigt och för livet av mig, Jag kunde inte få min kantiga apps att lansera i IE9.  De alla fungerar bra i IE11 men IE9 skulle bara Visa klammerparenteser och liknande bitar.

Jag sökte runt och kunde inte hitta någon klaga på hans problem.  Det fungerade bra i Chrome, IE11, bara inte IE9.

Jag kastades av det faktum att konsolen IE gav mig fel så här:

SEC7111: HTTPS säkerhet äventyras av res://Ieframe.dll/forbidframing.htm

Detta fel hade jag tänka fanns vissa problem dataöverföring den kantiga eller andra bibliotek som jag behövde.  Som det visar sig, Detta var inte frågan.

Av peta runt internets, Slutligen fick jag veta att frasen jag behövde för att söka efter var "bootstrap" och att det verkade som den bootstrapping var inte.  I slutet, mitt problem var att jag hade dekorerat min <HTML> tagg med attributet ng-app, som i:

<HTML-ng-app = "MatrixApp">

Brunn, det fungerade för IE9.  I stället, Jag svepte alla resten av HTML i den <organ> inuti en div och referenser MatrixApp sätt.

Problemet löst.

Förhoppningsvis sparar detta någon lite sorg.

</slutet>

Växande medvetenhet / Antagandet av JavaScript-ramverk

Min kollega, Javed Ansari (http://www.bigapplesharepoint.com/team?showExpertName=Javed%20Ansari&rsource=pgblog), skrev en kort sammanfattande blogginlägg om ramar han gillar eller åtminstone har varit med med med SharePoint: http://www.bigapplesharepoint.com/pages/View-An-Insight.aspx?BlogID=53&rsource=PGBlog).

jQuery verkar ha varit victor på fältet, så att säga, i år nu, men de andra är fler nya och stillbilder slags slåss, som vinkelformig. (SPServices, Självklart, har varit en livräddare i år och kommer att fortsätta att vara så jag tror).

Vad använder folk? De fokuserar mer på Microsofts verktyg (CSOM / JSOM) eller går mer mot vinkelformig, Knockout, Glödande kol, m.m.?

Jag har en växande slagsida mot dessa icke-Microsoft-ramar. Jag tror MSFT grejer är svårare och svårare att arbeta med, kräver nästan lika mycket av inlärningskurva som gammaldags SSI-dev.

Posta en kommentar här eller över på Big Apple SharePoint Om du vill diskutera (Big Apple kommer att ha mer sannolikheten för en bra diskussion).

</slutet>

Övervinna irriterande Problem med relativa URL-adresser i SharePoint Quick Launch

Jag ville lägga till en länk till Snabbstart navigeringen häromdagen och SharePoint berättade:

image

Ren textversion av som är:

Kontrollera att Webbadressen är giltig och börjar med antingen ett giltigt tecken (ett nummertecken (#) eller snedstreck (/)) eller ett giltigt protokoll som stöds (till exempel, "http://’, ' https://’, "filen://’, "ftp://’, "mailto:’, "nyheter:’).

"Blech och pox!"Jag sa.

En lösning på detta är att använda JavaScript för att hitta en känd länk i den snabb sjösätta och åsidosätta sitt beteende.

Att testa detta, lägga till en ny länk på webbplatsen test thusly:

image

Jag använde jQuery. Att lösa det, få lite JavaScript och jQuery till sidan med hjälp av din favorit teknik och med en kodrad som denna:

 

$(dokument).redo( funktionen () {

    $("en:innehåller("Test URL ersättning")").Klicka på(funktionen () { Alert("ändrade klicka beteende!"); återvändande falskt;});

});

Och Bob är din farbror.

JQuery väljaren finner varje <en> -tagg som har "Test URL ersättning" i namnet. Du kanske vill hitta-tune som beroende på din länk och sådant.

.click(funktionen() åsidosätter vad SharePoint skulle ha gjort när användaren klickar på. Se till att du "return false" annars det kommer att göra dina grejer och sedan försöka href saken alltför, vilket är nästan säkert inte ditt mål.

Detta gjordes och test i en SharePoint online-miljö men bör fungera bra i 2010 och tidigare alltför.

</slutet>

undefinedPrenumerera på min blogg.

Följ mig på Twitter vid http://www.twitter.com/pagalvin

Stackars mannen cachelagring i JavaScript

[TL;DR version: Använd cookies för att lagra resultaten av async samtal; göra resultaten av tidigare async samtal omedelbart och sedan validera dem efter sidan.]

Jag har jobbat på SharePoint intranät-webbplats för en klient som har, bland annat, en stiliserad sekundär navigering vars menyalternativ hanteras via en vanlig gammal anpassad lista.  Tanken är att klienten får styra "sina" webbplats-menyn utan att påverka eller påverkas av den globala navigeringen som tas ut av det.

(finns det något otroligt omstörtande om att lägga till en CEWP som pekar på en HTML-fil som laddar lite CSS- och JS att i grunden förändra nästan allt om en webbplats beteende... men det är för en annan tjänst)

Koden för denna ganska enkla:

Öm plats här är att varje gång någon träffar en av webbplatsens sidor, användarens webbläsare är att nå ut till få poster i listan.  När dev är komplett och tester har visat att vara stabil och komplett, denna uppmaning är onödigt mer än 99% av tiden eftersom menyn sällan ändras.  Det har också en konstig UI påverka som är vanligt i denna sköna nya värld av hyper-ajaxy webbplatser – sidan återger och först då gör menyn.  Det är skakis och störande i min mening.  Och skakis. Så, cachelagring. 

Jag ändrade logiken thusly:

  • Leta efter cookies i webbläsaren som innehåller menyn när jag senast läste det
    • Om hittade, göra det omedelbart.  Vänta inte på att sidan laddas.  (Du måste se till att din HTML är strategiskt placerad här, men det är inte svårt att göra).
  • Vänta på att sidan laddas och göra en asynkrona anrop till ladda upp menyn objekt från en lista med resten eller lists.asmx eller vad
  • Jämför vad jag fick mot cookie
    • Om det matchar, Stanna
    • Annars, med hjälp av jQuery, dynamiskt fylla ett gäng om <Li>är i en <UL>
  • Använd CSS för att göra all formatering
  • Vinst!

Några av er kommer att säga, "hey! Det finns ingen riktig caching pågår här eftersom du läser menyn ändå varenda gång.”  Och du har rätt – jag tänker inte ge servern någon form av paus.  Men eftersom samtalet är asynkrona och händer efter sidan inledande HTML-nyttolast gör helt, Det känns"" mer lyhörd för användaren.  Menyn gör ganska mycket som sidan drar.  Om menyn händer till förändring, användaren utsätts för en skakis åter dra på menyn, men bara att en gång.

Det finns några sätt att göra detta caching effektivare och hjälpa till servern samtidigt:

  • Sätta i en regel att den "cookie cachen" är giltigt i minst 24 timmar eller några andra tidsram. Så länge det finns ingen utgångna cookie, Använd Kakans menyn ögonblicksbild och aldrig träffa servern.

Tja... det är allt som kommer att tänka på just nu :). 

Om någon har några smarta idéer här skulle jag älska att veta dem.

Och slutligen – denna teknik kan användas för andra saker.  Denna klient sidan har ett antal datadrivna saker på olika sidor, många av dem ändra förhållandevis sällan (som en gång i veckan eller en gång i månaden).  Om du riktar särskilda områden av funktioner, Du kan ge en mer lyhörd UI genom att dra innehåll från lokala cookie butik och rendering omedelbart.  Det känns snabbare att användaren även om du inte sparar servern alla cykler.  Du kan Spara server cykler genom beslut på vissa villkor och utlösare att ogiltigförklara denna lokala cookie cache.  Det är alla situationsanpassat och konstnärliga saker och verkligen den roligaste :). 

</slutet>

undefinedPrenumerera på min blogg.

Följ mig på Twitter vid http://www.twitter.com/pagalvin