Tag Archives: JavaScript

Snel en eenvoudig: Een SharePoint-Site met behulp van REST maken

Er zijn een heleboel middelen rond die laten zien hoe dit te doen, maar ik kon het niet vinden een uitgebreide Ga-naar-link, Dus hier zijn we.

U kunt een SharePoint-site met behulp van de REST API.  Hier is een volledig gebakken voorbeeld:

<!--
    SiteRequestForm.html: Informatie verzamelen en een site maken voor de gebruiker.
-->

<Center>
<tabel>
    <tr>
        <TD>Naam van de site:</TD>
        <TD><input type= "tekst" naam"SiteName =" id"SiteName =" /></TD>
    </tr>
    <tr>
        <TD ColSpan= "2">
            <input type= "submit" id"CreateSiteButton =" waarde= "Maak de Site" />
        </TD>
    </tr>
</tabel>
</Center>

<script src="../Plugins/jQuery-1.11.0.min.js"></script>

<script>
var CreateSiteLogicContainer = {

    createSiteData: {
            "parameters": {
                __metadata: { "type": "SP.WebInfoCreationInformation" },
                URL: "Paultest1",
                Titel: "Paultest1",
                Beschrijving: "rest-gemaakt web door Paul!",
                Taal: 1033,
                WebTemplate: "St",
                UseUniquePermissions: vals
            }
    },

    createSite: functie () {

        jQuery.support.cors = True;

        CreateSiteLogicContainer.createSiteData.parameters.Url = $("#SiteName").Val();
        
        $.Ajax({
            URL: "https://bigapplesharepoint.sharepoint.com/NBAIADev/_api/web/webinfos/add",
            methode: "POST",

            headers: {
                "accept": "application/json; odata = verbose",
                "content-type": "application/json;odata = verbose",
                "X-RequestDigest": $(#__REQUESTDIGEST"").Val()
            },

            gegevens: JSON.stringify(CreateSiteLogicContainer.createSiteData),

            succes: functie () { waarschuwing("succes"); },
            fout: functie () { waarschuwing("fout"); }

        });
    },

    wireUpForm: functie () {
        $("#CreateSiteButton").Klik op(functie () {
            waarschuwing("Ongeveer om te proberen en de site hebt gemaakt.");
            CreateSiteLogicContainer.createSite();
        });
    }


}

CreateSiteLogicContainer.wireUpForm();

</script>

Wanneer succesvol, krijg je een pakje JSON in reactie als dit:

image

Mijn belangrijkste gedachten en lessen uit deze opnemen:

  • Deze aanpak maakt gebruik van jQuery.  In mijn geval, mijn jQuery bibliotheek bevindt zich "../ plugins. "  U zult willen veranderen om te wijzen op uw favoriete JQ locatie.
  • U kunt kopiëren en plakken dat hele fragment in een webonderdeel Inhoudseditor op een pagina en het zou moeten werken prima.  U zult willen wijzigen het eindpunt van de API-aanroep en zorg ervoor dat u verwijst naar JQ correct.
  • De URL is ten opzichte van uw API eindpunt.  In mijn geval, het het creëren van subsites onder https://bigapplesharepoint.com
  • U hoeft niet te bieden een inhoud-lengte. Sommige blog posts en MSDN document impliceert dat jij, maar gebeurde voor mij automatisch, die ik neem aan dat wordt afgehandeld door de $.ajax aanroep zelf.
  • Deze regel is nodig om te voorkomen dat een "verboden" antwoord: "X-RequestDigest": $(#__REQUESTDIGEST"").Val().  Er zijn andere manieren om het te doen, maar dit is vrij aardig.  Ik heb de link naar blog die deze snelkoppeling verloren.  H/T aan u, mysterieuze blogger!

Veel geluk en hoop dat die dit helpt iemand uit.

</einde>

undefinedAbonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Snelle en eenvoudige: SharePoint REST gesprek enige Returns 100 Records

Ik heb gewerkt op een openbare geconfronteerd met web site voor mijn SharePoint praktijk hier in New York en het maakt gebruik van veel JavaScript en REST oproepen naar inhoud weergeven.

Tijdens de mainline ontwikkeling, Ik maak een kleine dataset met net 10 of zo rijen in een aangepaste lijst en mijn aanroepen REST alle trok vanaf daar.  Eens ik gestoten op de lijst dat een paar honderd rijen met gegevens om te testen voor verwachte groei, Ik vond dat ik kreeg precies 100 rijen geretourneerd terug op mijn aanroepen REST.

Dit is een heel simpel ding naar adres.  In mijn geval (en ik denk dat in de meeste gevallen), de standaard REST roept naar SharePoint (en eventueel als een industriestandaard?) terugkeer 100 rijen.  Om terug te keren meer dan de standaard, Gebruik de parameter $top voor uw oproep, Als in:

KRIJGEN /Insights Dev/_api/web/lists/GetByTitle('MockBlog')/items?$Selecteer = ID,Titel,Categorieën/titel,Blog_x0020_Author/titel,DatePublished,BlogSummary&$Vouw = Blog_x0020_Author,Categorieën&$filter =&$Top = 9999

Ik pakte 9999 in dit geval omdat ik weet dat growth-wise, Er zal niet meer dan 200 of zo rijen toegevoegd aan deze lijst in een jaar.  Als het wordt logge, We kunnen sommige wisselbestand op de weg.

</einde>

undefinedAbonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Arme Man de Caching in JavaScript

[TL;DR versie: gebruik van cookies voor het opslaan van de resultaten van asynchrone oproepen; de resultaten van afgelopen async oproepen onmiddellijk renderen en vervolgens valideren ze na het laden van de pagina.]

Ik heb gewerkt op SharePoint intranet-site voor een client die functies, onder andere, een gestileerde secundaire navigatie waarvan menu-opties worden beheerd via een regelmatige oude aangepaste lijst.  Het idee is dat de client krijgt om "hun" site systeemmenu zonder te tasten of wordt beïnvloed door de wereldwijde navigatie stak door het.

(Er is iets ongelooflijk subversieve over het toevoegen van een CEWP die verwijst naar een HTML-bestand dat ladingen sommige CSS en JS fundamenteel veranderen bijna alles over van een site probleem... maar dat is voor een andere post)

De code voor dit vrij eenvoudig:

De zere plek hier is dat elke keer als iemand hits een pagina van de site, webbrowser van die gebruiker is het bereiken uit om items uit de lijst.  Zodra dev voltooid is en dingen te testen heeft bewezen stabiel en voltooien, deze oproep is onnodig meer dan 99% van de tijd sinds het menu zelden verandert.  Heeft ook een raar UI invloed die gebruikelijk is in deze heerlijke nieuwe wereld van hyper-ajaxy websites-de pagina maakt en alleen dan heeft het menu maken.  Het is zenuwachtig en afleidend in mijn mening.  En zenuwachtig. Dus, opslaan in de cache. 

Ik heb gewijzigd de logica thusly:

  • Zoek naar een cookie in de browser die het menu bevat als ik laatst lezen
    • Als gevonden, maken het onmiddellijk.  Wacht niet op de pagina te laden voltooien.  (U moet ervoor zorgen dat uw HTML-code wordt strategisch geplaatst hier, maar het is niet moeilijk om te doen).
  • Wachten op de pagina te laden voltooien en maak een async oproepen voor vracht opwaarts menu-items uit een lijst met behulp van REST of lists.asmx of wat dan ook
  • Vergelijken wat ik heb tegen de cookie
    • Als het overeenkomt met, STOP
    • Anders, met behulp van jQuery, dynamisch vullen een bos als <Li>de in een <UL>
  • Gebruik CSS te doen alle opmaak
  • Winst!

Sommigen van u zullen zeggen, "hey! Er is geen echte in het voorgeheugen onderbrengende gaat hier omdat je het lezen van het menu hoe dan ook elke keer.”  En je hebt gelijk-ik ben niet het geven van de server elke soort pauze.  Maar omdat de oproep async is en gebeurt na de pagina's eerste HTML-nettolading volledig maakt, het voelt"" ontvankelijker voor de gebruiker.  Het menu maakt vrij veel als de pagina vestigt.  Als het menu aan de verandering gebeurt, de gebruiker is onderworpen aan een zenuwachtig opnieuw te tekenen van het menu, maar slechts die één keer.

Er zijn een aantal manieren aan deze cache doeltreffender maken en helpen de server op hetzelfde moment:

  • Zet in een regel dat de cache"cookie" geldig voor een minimum van is 24 uren of sommige andere tijdsbestek. Zolang er geen verlopen cookie is, gebruik van de cookie menu momentopname en nooit hit de server.

Nou... dat is alles wat die te binnen schieten nu :). 

Als iemand slimme ideeën hier heeft zou ik graag willen weten ze.

En tot slot – deze techniek kan worden gebruikt voor andere dingen.  Deze client pagina heeft een aantal data-gedreven dingen op verschillende pagina 's, velen van hen veranderen relatief zelden (zoals een keer per week of eenmaal per maand).  Als u zich richten op specifieke gebieden van functionaliteit, u kunt een meer responsieve UI geven door trekken inhoud uit de lokale cookie store en meteen renderen.  Het voelt sneller aan de gebruiker, zelfs als u niet de server elke cycli opslaat.  U kan Sla de server cycli door te besluiten op een aantal voorwaarden en triggers om deze lokale cookie cache ongeldig te maken.  Dat is allemaal situationele en kunstzinnige spullen en echt de leukste :). 

</einde>

undefinedAbonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin