SharePoint Shop Talk åben Q&En Session torsdag 08/13 @ 12:30 PM EDT

Arcovis vil være vært for vores andet "SharePoint Shop Talk" session torsdag på 12:30 PM EDT. Dukke op med din SharePoint spørgsmål og vi vil gøre vores bedste til at underholde dig med banjo vittigheder, Smart men harmløse put-downs af vores kolleger paneldeltagere og måske selv besvare et spørgsmål eller to. Denne uges "officielle" panel omfatter jeres virkelig, min Arcovis partnere (Natalya Voskresenskaya og Harry Jones) og Laura Rodgers (af Twitter & EndUserSharePoint Fame). Bob fox truede med at tilslutte også, men jeg tage ikke det alt for alvorligt. Sidste gang, Vi havde en stor grad af publikumsdeltagelse, som sløret linje mellem paneldeltagere og deltagere, og jeg forventer det samme vil ske torsdag.

Denne begivenhed er co-sponsoreret af integrerede systemer og Services Group (www.issgroup.net).

Registrer dig her: https://www323.livemeeting.com/lrs/8000043750/Registration.aspx?pageName=9xrzxfs9x34sb0sm

Hvis du har spørgsmål, du vil have os til at tage, bare ringe til opkaldet og bede det. Hvis du vil have os til at tænke over det først, Send os en e-mail eller efterlade en kommentar her.

Se dig derefter!

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Eksisterende betingelser: SharePoint Alert skabeloner til undsætning (?)

En af mine klienter har arbejdet med en tidligere entreprenør til at bygge en lille, men nyttigt HR ansøgning for virksomheden. At kontrahenten brugt SharePoint Designer til at gennemføre arbejdsproces del af løsningen. Det er lidt af en rod. For eksempel, der er ni SPD arbejdsprocesser til støtte for en enkelt logisk arbejdsproces og op til fem af dem kan brand samtidig på ethvert givet tidspunkt givet de rette betingelser. It’s not easy to debug 🙂

Min kunde har en række stadig udestående krav, hvoraf den ene er generelt give mere sammenhæng, når systemet sender e-mail-advarsler – både i den e-mail, selv samt tilknyttede opgave former. Som SPD ved workflow implementers, Handlingen "indsamle data fra brugeren" SPD faktisk skaber en opgave med en brugerdefineret indholdstype. Når vi bruger denne handling, Vi får ikke at angive meget. Vi kan bede om nogle værdier (strømsparetilstand. "godkende" eller "Afvis") og vi kan angive en hårdt kodet værdi i titel og beskrivelse. Det er om det..

Min kundebehov er to folde:

  1. Når SharePoint sender en mail om en opgavetildeling, indeholde en masse oplysninger om opgaven i email legeme.
  2. Endnu vigtigere, langt – Når brugeren klikker på linket opgave i e-mailen, opgaveformularen bør have alle de oplysninger, godkenderen har brug for at gøre hendes/hans Godkend eller Afvis beslutning. Lige nu, manager skal du klikke på linket vare, selv at bore ned i de underliggende detaljer og kan lide ingen at. Du skal klikke i e-mailen. Derefter skal du klikke på en slags obskure link på opgaven. Derefter kan du se de underliggende data (en InfoPath-formular i dette tilfælde). Du klikke på ryg/ryg, osv. Alle hader det.

Jeg har arvet denne noget rodet tekniske løsning og jeg ønsker at foretage ændringer i den mindst indgribende måde muligt.

Den tilgang, jeg tager lige nu er at oprette en brugerdefineret alert skabelon. Du kan læse om det her. Strømmen fungerer som dette:

  • SPD workflow kører.
  • På et tidspunkt, det tildeler en opgave til en manager.
  • SharePoint system sender automatisk en advarsel til at manager. Dette er ikke en del af SPD workflow, men snarere "hvad SharePoint gør." (SharePoint-timertjenesten, Jeg mener).
  • En brugerdefineret alert handler påberåbes til fordel for den standard alert proces (efter magiske regler refererede som beskrevet i den ovenfor artikel).
  • Når min brugerdefinerede alert handler kører, Det genererer en smuk e-mail. Endnu vigtigere, da det har til opgave i hånd, det også pryder den faktiske opgave med alle den kontekstoplysninger nødvendige for at opfylde kravet om business.
  • Brugeren får e-mailen og den er fuld af nyttige kontekstoplysninger.
  • Brugeren klikker på linket opgave og opgaven, selv er fuld af nyttige kontekstoplysninger.
  • Alle går hjem at have vandmelon og is.

Jeg gjorde en hurtig test af koncept og det fungerer godt i et laboratoriemiljø. Jeg får min tilpasset e-mail alert som forventet. Jeg får også at opdatere opgavebeskrivelse og titel, selv.

Den kun tricky bit, hidtil, er at undgå en situation, hvor indberetningen opdateringer varen, udløse en anden besked. Dette gør ikke bekymre mig.

Ser lovende ud indtil videre...

Den store ting ved dette er, at jeg ikke behøver at nusse rundt med nogen af de eksisterende SPD arbejdsprocesser. De er lykkeligt uvidende om, at en alarm handler er"MERETE LØB I DA BAKGROUND, UDSMYK TEH OPGAVE LISTE WIF MOAR SAMMENHÆNG”.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Live SharePoint Q&En Session torsdag 07/30/09 @ 12:30 PM EDT slutter 1:30PM EDT

Opdatering: Formatet for dette er dybest set et telefonmøde med et par af PPT-dias til at sætte scenen. Vi har et SharePoint-miljø på stativ ved at fyre op, hvis det hjælper, men dette er primært folk taler højlydt. Der vil være muligheder for at følge op af e-mail.

Gå tilbage til min første nogensinde SharePoint konference, lidt over et år siden, Jeg har været ramt af hvor fantastisk en live Q&En session kan være. Konferencearrangører havde sat sammen en slags ad hoc-gruppe af "eksperter" (dvs. mennesker, der hang og ikke var bange for at kigge til fjollet op på scenen) at besvare eventuelle spørgsmål, der kom fra publikum på værelset. Det var i mit hoved dengang, og med jævne mellemrum siden da, at være vært for en lignende session, men gøre det på linje og telefonen. Jeg tror ikke, det kan være så god som en person Q&En session, men jeg tror det kunne være ret cool.

Jeg endelig kom rundt til det og næste torsdag, 07/30, min virksomhed (Arcovis) og samarbejdspartner, Integrerede systemer og tjenester gruppe, vil være vært for et Q&Et lignende. Jeg håber at gøre disse regelmæssigt, så ofte som ugentlige.

Dette åbningsmøde vil sandsynligvis være en smule ujævn, men konceptet er det:

  • Hvis du har spørgsmål, du gerne vil have besvaret under sessionen, bare dukke op og spørge.
  • Hvis du vil, Du kan e-maile spørgsmål på forhånd.

Vi planlægger at tilbringe den første halvdel af Q&A på mailede spørgsmål og derefter åbne det op til noget, som nogen spørger efter, at.

Sessionen finder sted på torsdag, 07/30 startende fra 12:30 og slutter på 1:30 PM EDT.

Hvis du er interesseret, venligst tilmelde dig her: https://www323.livemeeting.com/lrs/8000043750/Registration.aspx?pageName=pxlsd9fpsm2md7h9

Panelet vil omfatte mig og andre SharePoint skønånder. You’ll have to sign up to find out who they are 🙂

Hvis du gerne vil være en af disse lysarmaturer for en fremtidig Q&En session, Lad mig det vide.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Technorati Tags:

Integrere udvikler noter inde i dine InfoPath-formularer

Jeg stadig bor i InfoPath-formularer verden og jeg havde brug at gøre en af disse "små" ændringer til en form,, Desværre, bryder en navngivningskonvention jeg vedtaget med det for to uger siden. Jeg tænkte ved mig selv, "nogen kommer til at se på denne ting om året fra nu og sige, "Hvad tænkte Paul? Af Jove, hans navngivningskonvention giver ingen mening!”

Jeg indså, at jeg kunne skabe en visning i formularen for dette og derefter, En gang til, indså, at jeg kunne have gjort noget som dette hele tiden. Jeg har tilføjet "Udvikler noter" udsigt til InfoPath formularen som sådan:

image

Jeg har konfigureret formularen, så brugerne ikke kan komme til at se og derfor, Det er kun synlige med InfoPath-klienten i designvisning. Nu føler jeg mig lidt podede mod nogle fremtidige ukendt forfatter ser på min form og tænker dårlige tanker om mig. Pyha!

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Technorati Tags:

Administration af InfoPath-visninger

Jeg synes at gå gennem InfoPath faser hvor, ud af blå, Jeg skabelsen af en flok af formularer. Mine fingre lære at bruge værktøjet godt og derefter jeg gå gennem ni måneders tørke og nødt til at lære det hele igen.

Jeg er midt i en InfoPath-fase og jeg opretter InfoPath-formularer med masser af visninger. En ting du sikkert bemærke er, at InfoPath 2007 klienten viser visninger i alfabetisk rækkefølge. Dette er en reel gene nogle gange. Min bedste teknik er disse dage at prepend et tal til visningsnavnet, således at de altid vises i den ønskede rækkefølge, som illustreret her:

image

Jeg ville ønske, jeg havde gjort det hele tiden.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Technorati Tags:

InfoPath-formularen tilsagnsfaktura, Formularbaseret godkendelse (FORMULARBASERET GODKENDELSE) og unikke filnavne

Jeg har været arbejder på nogle InfoPath-formularer i en FBA miljø i denne uge i MOSS og lærde, da jeg gik til at installere formularer til et produktionsmiljø med en FBA zone som brugernavnet() funktionen funktion virker ikke. Jeg brugte det til at generere entydige filnavne.

Godt, Denne funktion virker ikke i en FBA miljø (mindst, ikke ud af boksen). Og, på refleksion, ved hjælp af brugernavnet på den måde, jeg havde planlagt ville have garanteret et entydigt filnavn under alle omstændigheder.

Min løsning var at bruge nu() funktion og en regel, der brande på indlæsning af formen. Jeg tildele filnavnet til dataelement, når den er tom:

image

image

Fordelen ved denne fremgangsmåde er, at filnavnet angives kun én gang. (Jeg vise ikke det i skærmbilledet, men sætte en betingelse i reglen kun brand når "myFilename" er tom). Jeg plejede at angive filnavnet på kildeniveau data. Typisk, Jeg ville gøre noget (Dårlig) Som dette:

image

Problemet med det er, at hvis bruger A åbner formen på mandag og bruger B ændrer det på tirsdag, du vil ende op med to forskellige former, da to forskellige brugerne gemte det med forskellige brugernavne.

Så, som irriterende da FBA kan være i almindelighed og med InfoPath navnlig, det fik mig til at genoverveje en lille, men virkelig vigtige tekniske detaljer og tilgang, som jeg ikke ville have gjort ellers!

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Technorati Tags:

Sikring af SharePoint-liste/dokument bibliotek synspunkter synes (slags) Muligt med jQuery

Dette er en anden post i mit igangværende serie om hvordan man bruger jQuery med SharePoint.
Hvis du ønsker at lære mere om jQuery, Jeg kan varmt anbefale: jQuery i aktion af Bjørn Bibeault og Yehuda Katz.

En af de første ting jeg troede, Når jeg begyndte at lege med jQuery, var, om vi kunne bruge det til at sikre en SharePoint-visning. Svaret er "nej" (eller i det mindste, Jeg påstår ikke det er muligt). Dog, Det er bestemt muligt at gøre det vanskeligt for folk at se en bestemt visning.

Jeg startede med min sandkasse miljø, når du arbejder på det. Jeg skrev om dette miljø her: Hurtig og nem: Opret din egen jQuery sandkasse til SharePoint.

Til at "sikre" en visning, Følg disse trin:

  1. Oprette en visning, der skal sikre. Jeg gjorde det, og kaldte det "Sikret Se".

    Dette er hvad det ser ud, når det ikke er "sikret":

    image

  2. Føje webdelen Indholdsredigering til visningens side benytter den nummer beskrives i artikel i sandkassen (dvs. tilføje "sidevisning = Shared&ToolPaneView = 2 "til URL-adressen).
  3. Finde ud af din SharePoint-_spUserId ved at følge disse skøre trin, tro eller ej:
    1. Log ind på dit SharePoint-miljø.
    2. I webbrowserens adressefelt, type: "javascript:alarm(_spUserId").
    3. Post resultatet (Det er "13" i mit tilfælde).

      image

  4. Tilføj den følgende javascript til din CEWP i kodevisning:

    <script type ="text/javascript"
        src =".. /.. /jQuery Library/jQuery-1.3.2.min.js">
    </script>
    
    <script type ="text/javascript">
      $(funktion() {
    
        alarm(_spUserId);
    
        varians theSecuredView = $(' iframe[FilterLink * = sikrede % 20View]');
    
        Hvis ((theSecuredView.length > 0) && (_spUserId == 13))
          $(' iframe[FilterLink * = sikrede % 20View]').forælder().forælder().forælder().HTML("<TR bgcolor = rød><TD>Nogen mening for dig!</TD></Tr>");
      });
    
    </script>
    

Jeg har inkluderet denne alarm(_spUserId) Line derinde at vise hvordan det ikke virkelig en "sikring" udsigt, men blot gør det sværere at se. Mere om det i et øjeblik.

Dybest set, jQuery er på udkig efter en iFrame på den side, der har en attribut, der indeholder "Sikret % 20View" i sin værdi. Når den finder det, vi kontrollere, hvis den aktuelle bruger er "13". Hvis det er, Vi vandrer op DOM til en <TR> Tag (som jeg regnede af gennemsyn kilde og sporing af det) og derefter erstatte TR mærke med min besked. Jeg ved virkelig ikke hvor robust er (Jeg er meget mistænkelige, Faktisk), men det virkede på min sandbox. Hvis jeg kan finde en bedre måde, Jeg vil blog om det.. Dette er resultatet:

image

Jeg klikker på knappen OK og data, der er erstattet med en stor rød besked:

image

Som du kan fortælle, den måde jeg har gennemføre denne "" sikkerhedsløsning er at tillade webdelen for at gøre sig selv. Når den er færdig, Jeg overskrive indholdet med min "ingen mening for dig!"besked.

Trods det faktum, at det ikke virkelig en "sikret" "Se, Det er potentielt nyttige og med nogle kloge arbejde, Det kan i sidste ende være securable i en mere formel forstand. Det grundlæggende spørgsmål er, at klienten bliver alle data og derefter, kun når det får dataene, det tørrer det. Hvis klienten er at få data, en klog bruger kan forhindre jQuery i at køre overhovedet og se, hvad han/hun ønsker at se.

Der er andre ulemper. Denne "sikkerhed" tilgang er baseret off en _spUserId. Vi ønsker at virkelig sikker baseret på den fulde SharePoint-sikkerhedsmodel, eller i det mindste af brugernavnet. Der bliver gradvist hårdere, men jeg ser nogle gode ting skrevet om dette emne, så jeg håber der er et godt svar på problemet.

Listen over visninger, sig burde være trimmet, Hvis det er muligt. Jeg har ikke prøvet at finde ud. Jeg formoder det er muligt, men ikke virkelig løse det grundlæggende sikkerhedsproblem, fordi nogen kunne stadig bare Skriv Webadressen på den visning, som de vil (Hvis de vidste det). Dog, trimning giver mening. Det er en god usability funktion og det hjælper til at sløre ting. Hvis slutbrugeren ikke ved at se begivenheden eksisterer, de vil ikke sandsynligvis forsøge at bruge det. Undertiden, Det er godt nok.

Med lidt held, Jeg vil have mere at skrive om dette emne over tid.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Hurtig og nem: En bedre måde at bruge jQuery at skjule et tekstfelt på en SharePoint-Form

Dette er en anden post i mit igangværende serie om hvordan man bruger jQuery med SharePoint.
Hvis du ønsker at lære mere om jQuery, Jeg kan varmt anbefale: jQuery i aktion af Bjørn Bibeault og Yehuda Katz.

Tidligere, Jeg skrev om, hvordan du bruger jQuery at lokalisere og skjule et felt i en formular. Jeg var ligeglad for den særlige tilgang (Jeg kæde forældre – det er simpelthen ikke er gjort disse dage, mindst i familier af kvalitet).

Da jeg først begyndte at tænke over det, Jeg vidste, jeg havde brug at finde en <TR> som jeg kunne påberåbe sig Skjul() metode. Min tidlige forsøg på at finde den korrekte <TR> var noget som dette:

$(«tr:har(input[titel = skjule mig!])');

Problemet med det er, at den ville finde hver <TR> Tag, der havde nogen overordnet-relation til Skjul mig! felt, selv om skjule mig! er indlejret mange niveauer dybt i <TR>'s. Det viser sig, at på min sandbox form, Dette udtryk finder 9 forskellige TR, der har skjule mig! som barn et sted i sin DOM-træet. Jeg indså, at jeg kunne gå tilbage op træet fra selve input feltet, så thats hvordan jeg endte med at misbruge forældre, men det gjorde ikke sidde godt med mig.

Jeg gav nogle tanke til dette og en af de ting jeg læste endelig gav mening: Jeg kunne bruge ikke() metode til at trimme ud <TR>er jeg ikke ønsker i min indpakket sæt. Det førte mig til dette:

$(«tr:har(input[titel = skjule mig!])').ikke(«tr:har(Tr)').Skjul();

Den første bit finder alle de <TR> koder, som har skjule mig! feltet overalt i deres egen hierarki. Det derefter strimler ud nogen <TR> der har også et barn <TR>. Det efterlader os med en enkelt <TR> der:

1) Ikke har nogen <TR> underordnede poster

2) Har input felt som barn.

Vi kan derefter anvende Skjul() metoden at den deraf følgende og vi er færdig.

Jeg er stadig en smule nervøs, men ikke så nervøs som kæde forældre.

Jeg ved ikke, om dette er en bedste praksis eller ikke. Der kan være en mere hensigtsmæssig måde at identificere netop den <TR> at vi interesserer os i en form, SharePoint. Hvis du kender, Skriv venligst en kommentar.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Hurtig og nem: Bruge jQuery til at skjule et tekstfelt på en SharePoint-Form

Dette er en anden post i mit igangværende serie om hvordan man bruger jQuery med SharePoint.
Hvis du ønsker at lære mere om jQuery, Jeg kan varmt anbefale: jQuery i aktion af Bjørn Bibeault og Yehuda Katz.

OPDATERING (allerede!): Jeg tror på en bedre måde at finde den <TR> Tag jeg ønsker at skjule og skrev om det her. Du kan stadig finde denne artikel interessant alligevel så jeg leavnig det op.

Jeg ønsker at skjule et tekstfelt, "Skjul mig!"som vist:

image

De følgende jQuery gør tricket for mig:

<script type ="text/javascript">

  $(funktion() {


    $(' input[titel = skjule mig!]').forælder().forælder().forælder().Skjul();

  });

</script>

Koden er at sige, "find mig alle input felter Hvis titel = skjule mig!. Derefter, få sin overordnede og derefter næste forælder og den * næste * overordnede (Pyha!) og påberåbe sig Skjul() metode på at ting, hvad det sker for at være.

Jeg regnede ud at overordnede struktur ved at få vist HTML-koden for formularen, SharePoint oprettes som vist:

<TR>
    <TD nowrap= "true" VAlign= "top" bredde= "190px" klasse= "ms-formlabel">
        <H3 klasse= "ms-standardheader">
            <nobr>Skjule mig!</nobr>
        </H3>
    </TD>

    <TD VAlign= "top" klasse= "ms-formbody" bredde= "400px">
        <!-- FieldName = "Skjul mig!"
                 FieldInternalName = "Hide_x0020_Me_x0021_"
                 FieldType = "SPFieldText"
        -->
        <span dir= "ingen">
            <input
                Navn= "ctl00$ m$ g_bdb23c2c_fde7_495f_8676_69714a308d8e$ ctl00$ ctl04$ ctl02$ ctl00$ ctl00$ ctl04$ ctl00$ ctl00$ TextField"
                type= "tekst"
                MaxLength= "255"
                id= "ctl00_m_g_bdb23c2c_fde7_495f_8676_69714a308d8e_ctl00_ctl04_ctl02_ctl00_ctl00_ctl04_ctl00_ctl00_TextField"
                titel= "Skjul mig!"
                klasse= "ms-lange" />
                <br>
        </span>


    </TD>
</TR>

Dette billede viser det samme, men markeret med forældrene:

image

Det første overordnede (1) er en span-kode. Spans overordnede (2) er TD tag og så endelig får vi til virkelige forældre jeg ønsker at skjule (3) der er TR-tag selv.

Dette er en temmelig forfærdeligt tilgang, jeg tror, fordi det er ekstremt afhængige af meget specifikke strukturen af denne formular. Når SharePoint 2010 kommer ud, denne hele struktur kunne ændre og bryde denne tilgang. Hvad jeg virkelig ønsker at gøre er håndværk en jQuery selector, der går i retning af "find mig alle TR (og eneste TR tags) der har et eller andet sted i deres underordnede elementer et inputfelt hvis titel = skjule mig!”. Jeg starter fra bunden og bevæger sig op. Antager jeg regne det ud, Jeg vil sende en opdateret "hurtig og nem ' post.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin

Hurtig og nem: Opret din egen jQuery sandkasse til SharePoint

Dette er en anden post i mit igangværende serie om hvordan man bruger jQuery med SharePoint.
Hvis du ønsker at lære mere om jQuery, Jeg kan varmt anbefale: jQuery i aktion af Bjørn Bibeault og Yehuda Katz.

Introduktion til jQuery i SharePoint er overraskende nemt (Til mig). (Jeg har alvorlige spørgsmål om en "bedste praksis" metode til implementering af disse ting til produktion, men det er til en anden dag). Jeg er lige begyndt at spille med denne teknologi og i forbindelse, Jeg skabt en sandkasse miljø at bruge. Hvis du søger at komme i gang med jQuery, Du kan finde denne tilgang nyttige.

1. Opret et tomt websted

Opretter et tomt websted et sted i dit websted og kalder det noget smart som "jQuery sandkasse".

2. Download jQuery

Du kan downloade jQuery javascript biblioteket fra her: http://docs.jquery.com/Downloading_jQuery

Gem det til på skrivebordet.

Jeg har blevet benytter den "minified" version.

3. Oprette et SharePoint-dokumentbibliotek

På webstedet sandkasse, oprette et dokumentbibliotek.

4. Uploade jQuery biblioteket til SharePoint

Adgang til biblioteket doc, du lige har oprettet, og uploade jQuery biblioteket.

5. Oprette en brugerdefineret SharePoint-liste

Jeg har startet med en brugerdefineret liste, fordi jeg ønsker at nusse rundt med SharePoint standardformularer. Du kan også oprette en side i et bibliotek for sider eller webdelssider og sandsynligvis en masse andre steder.

Tilføje nogle kolonner til den brugerdefinerede liste, så du har noget at køre jQuery mod. Mit oprindelige mål var at:

  1. Skjule et felt.
  2. Tildele en værdi til et felt.

Med dette mål for øje, Jeg har tilføjet to tekstfelter. Over tid, Jeg vil være at spille med links, billeder, opslag, osv.

6. Ændre siden NewForm.aspx webdel og føje webdelen Indholdsredigering

Dette er en lille sort magic-ish , i, at det er et nyt koncept til mig. Jeg første gang hørte om dette fra Paul Grenier, SharePoint jQuery Superstar, på hans CodePlex projektwebsted: http://spff.codeplex.com/.

Følg disse trin for at føje en CEWP til den samme side, der viser NewForm.aspx for enhver brugerdefineret liste:

  1. Få adgang til den brugerdefinerede liste og klik på ny.
  2. Føj følgende til URL-adressen: Sidevisning = delt&ToolPaneView = 2

Der vil omdanne din kedelige vanille dataindtastningsformular fra noget som dette:

image

Til dette:

image

Føje webdelen Indholdsredigering til siden.

7. Skriv din første jQuery kode

Lukke sig op CEWP i visningen kode og tilføje følgende:

image

Her er den faktiske kode hvis du copy/paste:

<script type ="text/javascript"
    src =".. /.. /jQuery Library/jQuery-1.3.2.min.js">
</script>

<script type ="text/javascript">
  $(funktion() {

    $('#resultsID').HTML('Der er' + $(«en»).størrelse() + 'en tags tags på denne side.');

  });
</script>

Resultat:
<div id ='resultsID'></div>
/resultat

Bemærk, at først <script> Tag referencing faktiske jQuery biblioteket. Formentlig, disse ting ændrer sig over tid, så du ønsker for at sikre dig en) Brug højre og b) pege på den korrekte SharePoint-dokumentbibliotek.

Bask i herligheden

Hvis du gjorde det korrekt, du vil se et resultat svarende til følgende:

image

Indpakning

Dette er ikke den eneste måde at komme i gang, men det er hurtig, nem og isoleret fra din eksisterende SharePoint-miljø.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin