Bar er stadig temmelig højt at udvide MOSS

I dag, Jeg arbejdede med en klient og beskriver hvordan du kan redigere webdelen indholdsforespørgsel og vise yderligere bits af oplysninger fra en indholdstype.

"Første, du konfigurere CQWP til at oprette forbindelse til dens datakilder, derefter eksportere du det til din arbejdsstation, ændre <CommonViewFields>, Upload, fjerne oprindelige og nu er det ' primet’ til at vise de andre kolonner. Næste, Åbn SharePoint designer, Naviger til site collection rod og Find ItemStyle.xsl. Kopiere en af skabelonerne som et nyttigt udgangspunkt. Gå tilbage og ændre CQWP at gøre brug af denne nye skabelon. Endelig, ændre skabelonen til at gengive dine nye felter! (Glem ikke at kontrollere det tilbage i så at andre brugere kan se resultaterne)."

Det er alle helt klart for mig (og de fleste af os SharePoint udvikler typer) Hvad der sker og hvordan det er helt rart, Virkelig, at data hentning aspekter af CQWP er så godt-separat fra data præsentation aspekter. Men, Det er ikke så let at forklare, er det?

<afslutning />

Vise indhold forespørgslen Web del resultater i et gitter / Tabel

Overblik og mål

Ud af boksen, MOSS’ Webdelen til indholdsforespørgsel (CQWP) viser sine resultater i en listeformat, ligner søgeresultater. Det er også muligt at få vist resultaterne i et gitter format (dvs. HTML-tabelformat). Gitter formater er bedre i nogle tilfælde. Jeg beskriver hvordan man opnår effekten i denne artikel.

Forretningsscenario

Jeg har arbejdet med en klienten på en enterprise-wide MOSS udrulningen. Vi har designet deres taksonomi, således at projekter er første klasses borgere i hierarkiet og har deres eget websted på øverste niveau. Projektledere opretholde en singleton liste over projekt oversigtsoplysninger, som titlen, budget, forventet afslutningsdato, resterende budget og andre opsummeringstype felter. Ved "singleton" Jeg mener en brugerdefineret SharePoint-liste garanteret indeholder kun ét element. Simplistisk, Det ser sådan ud:

billede

Den tekniske tilgang er meget det samme som beskrevet Her (http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!447.entry). CQWP bruger en XSL-transformering til at udlede HTML for browseren at gengive.

Jeg forestille altid resultatet før dykke ned i XSL, fordi XSL er et mareridt. Her er min ønskede resultat:

billede

HTML som dette genererer som følge:

<HTML>
 <kroppen>
 <Center>
 <tabel grænsen= 1>

<!-- Etiketter-->
 <Tr BgColor= blå>
 <TD><skrifttype farve= hvid><b>Projektnavn</b></skrifttype></TD>
 <TD Juster= højre><skrifttype farve= hvid><b>Komplet dato</b></skrifttype></TD>
 <TD Juster= højre><skrifttype farve= hvid><b>Budget</b></skrifttype></TD>
 <TD Juster= højre><skrifttype farve= hvid><b>Faktiske udgift</b></skrifttype></TD>
 <TD><skrifttype farve= hvid><b>Overordnede Status</b></skrifttype></TD>
 </Tr>

<Tr>
 <TD>Re-wire edb-rum.</TD>
 <TD Juster= højre>02/01/08</TD>
 <TD Juster= højre>22,500.00</TD>
 <TD Juster= højre>19,000.00</TD>
 <TD>I gang</TD>
 </Tr>

<Tr>
 <TD>Bestemmelse servere for SQL Upgrade</TD>
 <TD Juster= højre>04/01/08</TD>
 <TD Juster= højre>7,500.00</TD>
 <TD Juster= højre>0.00</TD>
 <TD>Planlagt</TD>
 </Tr>

</tabel>
 </Center>
 </kroppen>
</HTML>

Tilgang

Følg disse trin for at oprette gitteret:

  1. Identificere komponenter i gitteret (rækker/kolonner).
  2. Definere og oprette nødvendige webstedskolonner.
  3. Oprette sub websteder for projekter og singleton lister.
  4. Tilføje en CQWP til en webside og konfigurere den til at søge efter dine lister.
  5. Ændre den CQWP XML til at samle op på de yderligere kolonner.
  6. Redigere XSL-koden for at generere en tabel.

Jeg vil koncentrere mig om nummer seks. Tal en gennem fire er ligetil og noget, som enhver CQWP bruger allerede har gjort. Nummer fem er blevet veldokumenteret af andre, herunder denne udtømmende skærmbillede belæsset artikel fra MSDN Her (http://msdn2.microsoft.com/en-us/library/bb897399.aspx) og Heather Solomon's blog Her (http://www.heathersolomon.com/blog/articles/CustomItemStyle.aspx).

Møtrikker og bolte

Indlede og gennemføre trin et til fem ifølge dokumentationen til MSDN og Heather Solomons artikel.

På dette punkt, du har tilføjet din CQWP til siden og du har din <CommonViewFields> konfigureret efter behov.

Efter de sædvanlige fremgangsmåde, Jeg får disse mellemliggende resultater:

1. Opret en indholdstype, en templatized brugerdefineret liste for denne indholdstype og to websteder. Her er den type indhold:

billede

Her er lokationsstrukturen:

billede

2. Tilføj CQWP efter at skabe mit projekt underordnede websteder og singleton projekt sammenfattende lister:

billede

3. Tilføj alle de yderligere oplysninger, vil jeg via den <CommonViewFields>:

        <Egenskaben Navn="CommonViewFields" type="streng">Project_x0020_Name;Project_x0020_Expenses;Project_x0020_Status;Project_x0020_Start_x0020_Date;Project_x0020_End_x0020_Date;Project_x0020_Budget</Egenskaben>

Bemærk, at jeg var nødt til at holde alle egenskabsfelter på én linje, eller det ville ikke arbejde (CQWP ville fortælle mig, at forespørgslen returnerede ingen emner).

4. På dette punkt, Vi er klar til at bevæge sig ud over i MSDN-artiklen og flip på over til Heather Solomons artikel. Følg hende trin starter i nærheden af trin #5 oprette en tilpasset / unghosted version af ItemStyle.xsl. Jeg følger Heathers rådgivning, op gennem skridt 11 og få disse mellemliggende resultater:

4.1: Nævne min XSL-skabelon som følger:

<XSL:skabelonnavn = "gitter" matche = "træk[@Style = 'Grid']" mode = "itemstyle">

Jeg ændre også lidt hende foreslog <XSL:for hver …> ved at tilføje en <BR /> Tag til at give et renere notering:

    <XSL:for hver Vælg="@*">
      P:<XSL:værdi af Vælg="Navn()" /><br/>
    </XSL:for hver>

4.2: Jeg redigere webdelen, gå til udseende og vælge mine "gitter" stil:

billede

Anvende ændringen og her er resultatet:

billede

Vi kan se fra ovenstående, at felterne, vi vil (Projektnavn, udgift, status, osv) er tilgængelige for os at bruge, når vi udsender HTML. Ikke kun det, men vi se de navne, som vi skal henvise til disse kolonner i XSL. For eksempel, Vi henviser til projektets Status som "Project_x005F_x0020_Name".

På dette punkt, Vi afgår fra Heather's blog og fra skuldrene af disse giganter, Jeg tilføje min egen lille smule.

ContentQueryMain.xsl

NOTE: Når du foretager ændringer til både ContentQueryMain.xsl og ItemStyle.xsl, Du skal tjekke disse filer tilbage i, før du kan se effekten af dine ændringer.

Henblik på nettet-gøre, MOSS bruger to forskellige XSL-filer til at producere de resultater, vi ser fra en CQWP. Til at generere den tidligere bit output, Vi ændrede ItemStyle.xsl. MOSS bruger faktisk en anden XSL-fil, ContentQueryMain.xsl til i forbindelse med ItemStyle.xsl til at generere sin HTML. Som navnet antyder, ContentQueryMain.xsl er "vigtigste" XSL, der styrer den samlede strøm af Oversættelse. Det gentager listen over alle de fundne genstande og passerer dem én efter én til skabeloner i ItemStyle.xsl. Vi vil ændre ItemStyle.xsl for at generere åbne <tabel> Tag før udsender den første række af data og lukning <tabel> Tag efter udsender den sidste række. At opnå dette, ContentQueryMain.xsl er ændret for at passere to parametre til vores "gitter" skabelon i ItemStyle.xsl, "sidste række" og "aktuel række". ItemStyle.xsl bruger disse betinget udleder de nødvendige tags.

Ved hjælp af Heather Solomon teknik, vi finde ContentQueryMain.xsl. Det er beliggende i samme sted som ItemStyle.xsl. Dette skærmbillede bør hjælpe:

billede

Vi har brug for at foretage følgende ændringer:

  • Ændre en XSL-skabelon, "CallItemTemplate" der faktisk påberåber sig vores gitter skabelon i ItemStyle.xsl. Vi vil passere to parametre til skabelonen gitter, således at det får de data, det skal generere betinget åbning og lukning <tabel> Tags.
  • Ændre en anden lidt af ContentQueryMain.xsl, der kalder "CallItemTemplate" at give den en "LastRow" parameter, således at LastRow kan blive videregivet til vores gitter skabelon.

Find den skabelon opkaldt "OuterTemplate.CallItemTemplate" identificeret af strengen:

  <XSL:skabelon Navn="OuterTemplate.CallItemTemplate">

Erstatte hele skabelonen som følger:

  <XSL:skabelon Navn="OuterTemplate.CallItemTemplate">
    <XSL:Param Navn="CurPosition" />

    <!--
      Tilføj "LastRow" parameter.
      Vi kun bruger det når varen stil pass i er "Grid".
    -->
    <XSL:Param Navn="LastRow" />

    <XSL:Vælg>
      <XSL:Hvornår test="@Style = 'NewsRollUpItem'">
        <XSL:anvende skabeloner Vælg="." mode="itemstyle">
          <XSL:med param Navn="EditMode" Vælg="$cbq_iseditmode" />
        </XSL:anvende skabeloner>
      </XSL:Hvornår>
      <XSL:Hvornår test="@Style = 'NewsBigItem'">
        <XSL:anvende skabeloner Vælg="." mode="itemstyle">
          <XSL:med param Navn="CurPos" Vælg="$CurPosition" />
        </XSL:anvende skabeloner>
      </XSL:Hvornår>
      <XSL:Hvornår test="@Style = 'NewsCategoryItem'">
        <XSL:anvende skabeloner Vælg="." mode="itemstyle">
          <XSL:med param Navn="CurPos" Vælg="$CurPosition" />
        </XSL:anvende skabeloner>
      </XSL:Hvornår>

      <!--
              Pass aktuelle position og lastrow gitter itemstyle.xsl skabelon.
              ItemStyle.xsl vil bruge det til at udlede åbne og lukke <tabel> Tags.
      -->
      <XSL:Hvornår test="@Style = 'Grid'">
        <XSL:anvende skabeloner Vælg="." mode="itemstyle">
          <XSL:med param Navn="CurPos" Vælg="$CurPosition" />
          <XSL:med param Navn="Seneste" Vælg="$LastRow" />
        </XSL:anvende skabeloner>
      </XSL:Hvornår>

      <XSL:ellers>
        <XSL:anvende skabeloner Vælg="." mode="itemstyle">
        </XSL:anvende skabeloner>
      </XSL:ellers>
    </XSL:Vælg>
  </XSL:skabelon>

Kommentarer beskriver formålet med ændringerne.

Selvfølgelig, "OuterTemplate.CallItemTemplate" hedder sig selv fra en anden skabelon. Find skabelonen ved at søge efter denne tekststreng:

<XSL:skabelon Navn="OuterTemplate.Body">

Gennemse vejledningen i OuterTemplate.Body og indsætte parameteren LastRow som følger (vist som en kommentar i kursiv):

<XSL:Call-skabelon Navn="OuterTemplate.CallItemTemplate">
  <XSL:med param Navn="CurPosition" Vælg="$CurPosition" />
  <!-- Indsætte parameteren LastRow. -->
  <XSL:med param Navn="LastRow" Vælg="$LastRow"/>
</XSL:Call-skabelon>

Efter alt dette, Endelig har vi ting sat rigtigt op, således at vores ItemStyle.xsl kan udsende <tabel> Tags på det rigtige sted.

ItemStyle.Xsl

NOTE: Igen, Tjek i ItemStyle.xsl efter at gøre eventuelle ændringer, så du kan se effekten af ændringerne.

Vi har to opgaver her:

  • Erstatte skabelonen hele gitteret. Du kan kopiere/indsætte nedefra.
  • Tilføje nogle mumbo jumbo udenfor skabelondefinitionen, der giver mulighed for "formatcurrency" skabelon til arbejde. (Du kan fortælle, at jeg har en svag håndtag på XSL).

Første, nær toppen af ItemStyle.xsl, Tilføj denne linje:

  <!-- Nogle mumbo jumbo, der gør det muligt for os at vise os. valuta. -->
  <XSL:decimal-format Navn="personale" ciffer="D" />

  <XSL:skabelon Navn="Standard" match="*" mode="itemstyle">

Bemærk at jeg tilføjede det direkte før den <XSL:skabelonnavn = "standard" …> definition.

Næste, gå tilbage til vores gitter skabelon. Erstatte skabelonen hele gitteret med koden nedenfor. Det er grundigt kommenterede, men tøv ikke med at email mig eller efterlade kommentarer på min blog, hvis du har spørgsmål.

  <XSL:skabelon Navn="Gitter" match="Række[@Style = 'Grid']" mode="itemstyle">

    <!--
      ContentMain.xsl passerer CurPos og sidste.
      Vi bruger disse til betinget udsender åbne og lukke <tabel> Tags.
    -->
    <XSL:Param Navn="CurPos" />
    <XSL:Param Navn="Seneste" />

    <!-- Følgende variabler er uændret fra den standard ItemStyle.xsl -->
    <XSL:variabel Navn="SafeImageUrl">
      <XSL:Call-skabelon Navn="OuterTemplate.GetSafeStaticUrl">
        <XSL:med param Navn="UrlColumnName" Vælg="'ImageUrl'"/>
      </XSL:Call-skabelon>
    </XSL:variabel>
    <XSL:variabel Navn="SafeLinkUrl">
      <XSL:Call-skabelon Navn="OuterTemplate.GetSafeLink">
        <XSL:med param Navn="UrlColumnName" Vælg="'LinkUrl'"/>
      </XSL:Call-skabelon>
    </XSL:variabel>
    <XSL:variabel Navn="DisplayTitle">
      <XSL:Call-skabelon Navn="OuterTemplate.GetTitle">
        <XSL:med param Navn="Titel" Vælg="@Title"/>
        <XSL:med param Navn="UrlColumnName" Vælg="'LinkUrl'"/>
      </XSL:Call-skabelon>
    </XSL:variabel>
    <XSL:variabel Navn="LinkTarget">
      <XSL:Hvis test="@OpenInNewWindow = "True"" >_blank</XSL:Hvis>
    </XSL:variabel>

    <!--
      Her definere vi en variabel, "tableStart".  Dette indeholder HTML-koden, som vi bruger til at definere åbningen af tabellen samt kolonneetiketterne.  Bemærk, at hvis CurPos = 1, Det indeholder HTML-koden i et CDATA-tag.
      Ellers, det vil være tom.

      Værdien af tableStart er emited hver gang ItemStyle kaldes via ContentQueryMain.xsl.
    -->
    <XSL:variabel Navn="tableStart">
      <XSL:Hvis test="$CurPos = 1">
        <![CDATA[
        <tabel border = 1>
          <TR bgcolor = "blå">
            <TD><font color = "hvid"><b>Projektnavn</b></skrifttype></TD>
            <TD align = "right"><font color = "hvid"><b>Komplet dato</b></skrifttype></TD>
            <TD align = "right"><font color = "hvid"><b>Budget</b></skrifttype></TD>
            <TD align = "right"><font color = "hvid"><b>Faktiske udgift</b></skrifttype></TD>
            <TD><font color = "hvid"><b>Overordnede Status</b></skrifttype></TD>
          </Tr>
        ]]>
      </XSL:Hvis>
    </XSL:variabel>

    <!--
      En anden variabel, tableEnd simpelthen definerer afsluttende tabel tag.

      Som med tableStart, Det er altid emited.  Dette er grunden til, at dens værdi er tildelt betinget baseret på om vi har været forbi den sidste række ContentQueryMain.xsl.
    -->
    <XSL:variabel Navn="tableEnd">
      <XSL:Hvis test="$CurPos = $Last">
        <![CDATA[ </tabel> ]]>
      </XSL:Hvis>
    </XSL:variabel>

    <!--
      Altid udsende indholdet af tableStart.  Hvis dette ikke er den første række videre til os af ContentQueryMain.xsl, så vi ved dens værdi bliver tom.

      Deaktiverer output flygter fordi når tableStart det ikke tom, Det omfatter faktiske HTML, som vi ønsker skal gengives af browseren.  Hvis vi ikke fortæller output XSL-parseren til at deaktivere flygter, det vil generere ting som"&lt;tabel&gt;" i stedet for"<tabel>".
    -->
    <XSL:værdi af Vælg="$tableStart" Deaktiver-output-undslippe="Ja"/>


    <Tr>
      <!--
      P:Project_x005F_x0020_Name Pedersen:Project_x005F_x0020_End_x005F_x0020_Date Pedersen:Project_x005F_x0020_Budget Pedersen:Project_x005F_x0020_Expenses Pedersen:Project_x005F_x0020_Status
      -->
      <TD>
        <XSL:værdi af Vælg="@Project_x005F_x0020_Name"/>
      </TD>

      <TD Juster="højre">
        <XSL:værdi af Vælg="@Project_x005F_x0020_End_x005F_x0020_Date"/>
      </TD>

      <TD Juster="højre">
        <XSL:Call-skabelon Navn="FormatCurrency">
          <XSL:med param Navn="værdi" 
Vælg="@Project_x005F_x0020_Budget"></XSL:med param> </XSL:Call-skabelon> </TD> <TD Juster="højre"> <XSL:Call-skabelon Navn="FormatCurrency"> <XSL:med param Navn="værdi" Vælg="@Project_x005F_x0020_Expenses">
</XSL:med param> </XSL:Call-skabelon> </TD> <TD> <XSL:værdi af Vælg="@Project_x005F_x0020_Status"/> </TD> <!-- Alle de følgende er kommenteret ud for at afklare tingene. Dog, Bring det tilbage og kram det ind i en <TD> at se dets effekt. --> <!-- <div id = "linkitem" Class = "element"> <XSL:Hvis test = "strenglængde($SafeImageUrl) != 0"> <div class = "billede-området-venstre"> <en href = "{$SafeLinkUrl}" Target = "{$LinkTarget}"> <IMG class = "billede-fast-bredde" src = "{$SafeImageUrl}"
alt = "{@ImageUrlAltText}"/> </en> </div> </XSL:Hvis> <div class = "link-vare"> <XSL:Call-skabelon
Name="OuterTemplate.CallPresenceStatusIconTemplate"/> <en href = "{$SafeLinkUrl}"
Target = "{$LinkTarget}" title = "{@LinkToolTip}"> <XSL:værdien af Vælg = "$DisplayTitle" /> </en> <div class = "beskrivelse"> <XSL:værdien af select="@Description" /> </div> </div> </div>
--> </Tr> <!-- Udsender afsluttende tabel tag. Hvis vi ikke er på den sidste række, Dette vil være tom. --> <XSL:værdi af Vælg="$tableEnd" Deaktiver-output-undslippe="Ja"/> </XSL:skabelon> <XSL:skabelon Navn="FormatCurrency"> <XSL:Param Navn="værdi" Vælg="0" /> <XSL:værdi af Vælg='format-nummer($værdi, "$DDD,DDD,DDD. DD", "personale")' /> </XSL:skabelon>

Standard WSS/MOSS Data Entry skærme understøtter ikke overlappende Drop-downs (eller andre intra-meddelelse)

OPDATERING (04/2008): Denne store blog viser en god javascript-baseret tilgang til problemet: http://webborg.blogspot.com/2008/04/add-functions-and-events-to-sharepoint.html

UPDATE II: (04/2008): Denne blog ser lovende samt: http://www.cleverworkarounds.com/2008/03/13/free-mosswss-2007-web-part-hide-controls-via-javascript/

Flere gange om ugen, Hvis ikke daglige, forum brugere beskriver et krav, der normalt ville blive opfyldt via overlappende drop-downs. For eksempel, Jeg har to henlægge-nede Kontroller:

  • Liste over USA. stater
  • Liste over USA. byer.

Som ansvarlig UI udbydere, Vi vil have det til at fungere som denne:

  • Paul vælger en U.S. staten fra drop-down.
  • Dette forårsager byer drop-down til at filtrere kun de byer, der tilhører den valgte tilstand.
  • Paul vælger en by fra dette filtreret liste.

Der er ingen out-of-the-box understøttelse af denne funktion. Faktisk, der er ingen OOB support for enhver form for direkte handel-form kommunikation. Dette omfatter programmatisk skjule/aktivering/deaktivering felter feltændringer andre steder i formularen i forbindelse.

Det virkelige mål i denne artikel til at beskrive mulige løsninger og disse er valgmuligheder som jeg kender dem:

  1. Udvikle en brugerdefineret kolonnetype. Som en brugerdefineret-kolonne-udvikler, du har fuld kontrol over hele "verden" i den brugerdefinerede kolonne. Du kan implementere en cascading drop-down på den måde.
  2. Overvej at bruge arbejdsproces. I nogle tilfælde, du vil til automatisk at tildele en værdi til område baseret på en anden feltværdi. I dette tilfælde, du ville normalt forsøger at bruge en beregnet kolonne, men nogle gange, det få bare ikke arbejdet gjort. SharePoint Designer arbejdsprocessen er en relativt administrere-venligt alternativ til at droppe ned til kode og visual studio. Hvis du gå denne vej, være opmærksomme på spørgsmålet løses ved denne artikel (http://paulgalvin.spaces.live.com/blog/cns!CC1EDB3DAA9B8AA!405.entry).
  3. Hændelseshandlere: Ligesom arbejdsproces, Dette er en efter-the-fact løsning. Hændelseshandleren er en .NET forsamling (C#, VB.NET) til hvilke SharePoint passerer kontrol. Det objekt, du udvikler har adgang til data fra listen (og hele objektmodellen) og kan gøre eventuelle nødvendige beregning.
  4. Brug SharePoint Designer til at oprette brugerdefinerede blanketter. Jeg har ikke direkte erfaring med denne tilgang, but I hear they are doing good things with NewForm.aspx these days 🙂
  5. Roll din egen ASP.NET data entry funktion (som en stand-alone webside eller som en webdel) og bruge det i stedet.

Hvis nogen kender andre og/eller bedre muligheder, Skriv venligst en kommentar og jeg vil opdatere kroppen af dette indlæg.

<afslutning />

Technorati Tags:

Ja/Nej (afkrydsningsfeltet) filtrering i webdelen til indholdsforespørgsel

Til at filtrere efter en forespørgsel for ja/ingen afkrydsningsfeltet ret "PG milepæl", konfigurere CQWP som denne:

billede

Dette er endnu en af de indlysende-én gang-du-ved-it men hard-to-find-an-answer-to spørgsmål: Sådan filtreres på et ja/ingen afkrydsningsfelt ved hjælp af webdelen indholdsforespørgsel.

Først søgeresultat Jeg finde ved hjælp af den ransage periode "filter ja/nej indholdsforespørgsel webdel" er flade ud galt, så jeg tænkte ville jeg sætte dette deroppe og se, hvis det kan erstatte den forkert resultat i typiske søgeresultater.

Det er ganske let: Sande værdier = "1" og falske værdier lige ikke "1" (smukke retro, faktisk).

I eksemplet ovenfor, Jeg har oprettet webstedskolonne af typen ja/nej" (afkrydsningsfeltet)" navngivne "PG milepæl". Jeg har tilføjet det til en doc bibliotek, uploadet et par dokumenter, angive værdien for et par og prøvet det.

<afslutning />

Oprette søjlediagrammer i SharePoint

Oversigt:

(OPDATERING 12/04/07: Tilføjet en anden interessant ressource i slutningen sammenkædning med en anden blog, der løser dette via en meget interessant webdel)

Dette blogindlæg beskriver, hvordan du opretter et søjlediagram i SharePoint. Dette virker i både WSS og MOSS miljøer som det afhænger kun af webdelen datavisning.

Den overordnede tilgang er som følger:

  1. Oprette en liste eller et dokumentbibliotek, der indeholder de data, du vil afbilde.
  2. Sted det tilknyttede dokumentbibliotek / brugerdefineret liste på en side og konvertere det til en webdelen Datavisning (DVWP).
  3. Ændre den DVWP XSL til at generere HTML, vises som en graf.

Forretningsscenario / Installationsprogrammet:

Jeg har oprettet en brugerdefineret liste med kolonnen standard titel og en ekstra kolonne, "Status". Denne modeller (meget simplistisk) "tilladelse til udgift" scenario hvor titlen repræsenterer projektet og Status en værdi fra listen over:

  • Foreslået
  • I processen
  • Gået i stå

Målet er at producere en interaktiv vandrette søjlediagram, der viser disse statuskoder.

Jeg har udfyldt listen og det ser sådan ud:

billede

Oprette webdelen datavisning:

Oprette en DVWP ved at føje den brugerdefinerede liste til en side (webstedsside i mit tilfælde) og følg instruktionerne Her (http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!395.entry).

Ud over blot at oprette DVWP, Vi skal også angive egenskaben personsøgning til at vise alle tilgængelige rækker. For mig, Det ser nogenlunde sådan her:

billede

På dette punkt, Jeg lukke altid SPD og browseren. Jeg derefter åbne igen siden ved hjælp af browseren. Derved undgår du ved et uheld mucking op del Weblayout på siden.

Ændre XSLT:

Det er nu tid til at ændre XSLT.

Jeg bruge altid visual studio til dette. (Se Her for en vigtig bemærkning om intellisense, der vil hjælpe dig med en masse).

Jeg oprette et tomt projekt tilføje fire nye filer (erstatte ordene "Original" og "New" som det er relevant):

  • Original.XSLT
  • New.XSLT
  • Oprindelige Params.xml
  • Ny Params.xml

I mit tilfælde, Det ser sådan ud:

billede

Redigere webdelen og kopiere params og XSL til "oprindelige" version i Visual Studio.

Målet her er at forårsage XSL at omdanne de resultater, vi får tilbage fra forespørgslen DVWP til HTML, der gengiver som en graf.

Til dette formål, Det hjælper til at først for at overveje, hvordan HTML-koden skal se ud, før vi blive forvirret af de sindssyge, der er kendt som "XSL". (At være klar, følgende er blot et eksempel; ikke skrive det eller copy/paste i visual studio. Jeg giver et fuld slag udgangspunkt for senere i skrive-up). Følgende eksempel grafen er gengivet som HTML umiddelbart efter:

Eksempel søjlediagram

Tilsvarende HTML:

<HTML>
<kroppen>
<Center>
<tabel bredde = 80%>
<Tr><TD><Center>Vandret søjlediagram</TD></Tr>
<Tr>
<TD align = "center">
<tabel border = "1" bredde = 80%>
<Tr>
<TD bredde = 10%>Åben</TD>
<TD><tabel cellpadding ="0" CellSpacing ="0" Border = 0 width = 50%><TR bgcolor = rød><TD>&nbsp;</TD></Tr></tabel></TD>
</Tr>
<Tr>
<TD bredde = 10%>Lukket</TD>
<TD><tabel cellpadding ="0" CellSpacing ="0" Border = 0 width = 25%><TR bgcolor = rød><TD>&nbsp;</TD></Tr></tabel></TD>
</Tr>
<Tr>
<TD bredde = 10%>Gået i stå</TD>
<TD><tabel cellpadding ="0" CellSpacing ="0" Border = 0 width = 25%><TR bgcolor = rød><TD>&nbsp;</TD></Tr></tabel></TD>
</Tr>
</tabel>
</TD>
</Tr>
</tabel>
</kroppen>
</HTML>

Jeg brugte en død simpel tilgang til at skabe min barer ved at indstille baggrundsfarven for en række til "rød".

Den takeaway her er dette: I sidste ende, alt, hvad vi gør er at skabe HTML med rækker og kolonner.

Skabelon XSLT:

Jeg har kopieret den XSLT, der genererer en vandret bar graf. Det er ret godt kommenteret så jeg ikke vil tilføje meget her bortset fra disse noter:

  • Jeg startede med standarden XSL, at SharePoint Designer gav mig da jeg oprettede DVWP.
  • Jeg var i stand til at skære det fra SPDS 657 linjer til 166 linjer.
  • Jeg har ikke rodet rundt med parametre XML-fil (som er adskilt fra XSL og du ved hvad jeg mener når du går til at ændre DVWP, selv; der er to filer kan du ændre). Dog, for at forenkle det, Jeg har fjernet næsten alle af dem fra XSL. Dette betyder at hvis du ønsker at gøre brug af disse parametre, Du skal blot tilføje deres variable definitioner tilbage til XSL. Der vil være let, da du vil have de oprindelige XSL-variable definitioner i din visual studio-projekt.
  • Du burde være i stand til at kopiere og indsætte det direkte i din visual studio-projekt. Derefter, fjerne mit kald og indsætte dine egne opkald til "ShowBar".
  • Boret ned værker ved at skabe en <en href> Som dette: http://server/List?FilterField1=fieldname&FilterValue1=actualFilterValue. Denne teknik kan være af værdi i andre sammenhænge. I første omgang, Jeg troede, jeg skulle svare til et mere komplekst format: http://server/List/AllItems.aspx?View={guid}&FilterField1=blah&FilterValue1=blah, men det er ikke nødvendigt i mit miljø. Listens URL-adresse sendes til os af SharePoint, så det er ganske let at generalisere.

Her er det:

<XSL:stylesheet version="1.0" Udeluk-resultat-præfikser="RS z o s ddwrt dt msxsl" 
xmlns:msxsl="urne:schemas-microsoft-com:XSLT" xmlns:XSL="http://www.w3.org/ 1999/XSL/Transformer"
xmlns:SharePoint="Microsoft.SharePoint.WebControls" xmlns:__designer="http://schemas.microsoft.com/WebParts/v2/DataView/designer"
xmlns:ASP="http://schemas.microsoft.com/ASPNET/20" xmlns:ddwrt="http://schemas.microsoft.com/WebParts/v2/DataView/runtime"
xmlns:o="urne:schemas-microsoft-com:Office" xmlns:s="UUID:BDC6E3F0-6DA3-11D1-A2A3-00AA00C14882"
xmlns:dt="UUID:C2F41010-65B3 - 11d 1-A29F-00AA00C14882" xmlns:RS="urne:schemas-microsoft-com:Rækkesættet" xmlns:z="#RowsetSchema"
xmlns:ddwrt2="urne:FrontPage:interne"
> <XSL:output metode="HTML" led="Nej" /> <XSL:decimal-format NaN="" /> <XSL:Param Navn="ListUrlDir"></XSL:Param> <!-- Jeg har brug for dette til at støtte en drill-down. --> <XSL:skabelon match="/" xmlns:SharePoint="Microsoft.SharePoint.WebControls"
xmlns:__designer=http://schemas.microsoft.com/WebParts/v2/DataView/designer xmlns:ASP="http://schemas.microsoft.com/ASPNET/20"
> <XSL:variabel Navn="dvt_StyleName">Tabel</XSL:variabel> <XSL:variabel Navn="Rækker" Vælg="/dsQueryResponse/rækker/række" /> <XSL:variabel Navn="dvt_RowCount" Vælg="Grev($Rækker)" /> <XSL:variabel Navn="IsEmpty" Vælg="$dvt_RowCount = 0" /> <XSL:variabel Navn="dvt_IsEmpty" Vælg="$dvt_RowCount = 0" /> <XSL:Vælg> <XSL:Hvornår test="$dvt_IsEmpty"> Der er ingen data til grafen!<br/> </XSL:Hvornår> <XSL:ellers> <!-- Det interessante ting begynder her. Vi har brug at definere et par variabler til hver række i grafen: samlede antal elementer og procent af total. --> <XSL:variabel Navn="totalProposed" Vælg="Grev(/dsQueryResponse/rækker/række[normalisere plads(@Status) = 'Foreslog'])" /> <XSL:variabel Navn="percentProposed" Vælg="$totalProposed div $dvt_RowCount" /> <XSL:variabel Navn="totalInProcess" Vælg="Grev(/dsQueryResponse/rækker/række[normalisere plads(@Status) = 'I processen'])" /> <XSL:variabel Navn="percentInProcess" Vælg="$totalInProcess div $dvt_RowCount" /> <XSL:variabel Navn="totalStalled" Vælg="Grev(/dsQueryResponse/rækker/række[normalisere plads(@Status) = 'Stå'])" /> <XSL:variabel Navn="percentStalled" Vælg="$totalStalled div $dvt_RowCount" /> <!-- Vi definerer vores HTML-tabel her. Jeg låne fra nogle standard SharePoint stilarter her gøre det konsekvent. Jeg tror, det vil ære ændringer til den globale css fil samt tema tilsidesætter. --> <tabel bredde="100%" CellSpacing="0" CellPadding="2" stil="Border-højre: 1 solid #C0C0C0; grænse-bund: 1 solid #C0C0C0; grænse-venstre-stil: solid; grænse-venstre-bredde: 1; grænse-top-stil: solid; top-kantbredde: 1;"> <Tr> <TD Juster="Center"> <tabel grænsen="1" bredde="100%"> <!-- For hver status, som vi ønsker at grafen, Vi kalder "ShowBar" skabelon. Vi passerer det: 1. En etiket til rækken. Dette er omdannet til et hyperlink. 2. Procent (variabel fra oven). 3. Det faktiske feltnavn af koden fra den underliggende liste. Dette behøver ikke at matche visningsetiket. 4. Værdien i feltet afstemt for #3. 5. Samlede elementer af denne statuskode (ikke hovedtotalen af alle statuskoder). Det udsender en <Tr></Tr> og den vandrette søjlegraf linje. Vi kalder denne skabelon for hver statuskode, vi ønsker at se. --> <XSL:Call-skabelon Navn="ShowBar"> <XSL:med param Navn="BarDisplayLabel" Vælg="'Foreslog'"/> <XSL:med param Navn="BarPercent" Vælg="$percentProposed"/> <XSL:med param Navn="QueryFilterFieldName" Vælg="'Status'"/> <XSL:med param Navn="QueryFilterFieldValue" Vælg="'Foreslog'"/> <XSL:med param Navn="TotalItems" Vælg="$totalProposed"></XSL:med param> </XSL:Call-skabelon> <XSL:Call-skabelon Navn="ShowBar"> <XSL:med param Navn="BarDisplayLabel" Vælg="'Stå'"/> <XSL:med param Navn="BarPercent" Vælg="$percentStalled"/> <XSL:med param Navn="QueryFilterFieldName" Vælg="'Status'"/> <XSL:med param Navn="QueryFilterFieldValue" Vælg="'Stå'"/> <XSL:med param Navn="TotalItems" Vælg="$totalStalled"></XSL:med param> </XSL:Call-skabelon> <XSL:Call-skabelon Navn="ShowBar"> <XSL:med param Navn="BarDisplayLabel" Vælg="«I processen'"/> <XSL:med param Navn="BarPercent" Vælg="$percentInProcess"/> <XSL:med param Navn="QueryFilterFieldName" Vælg="'Status'"/> <XSL:med param Navn="QueryFilterFieldValue" Vælg="«I processen'"/> <XSL:med param Navn="TotalItems" Vælg="$totalInProcess"></XSL:med param> </XSL:Call-skabelon> </tabel> </TD> </Tr> </tabel> </XSL:ellers> </XSL:Vælg> </XSL:skabelon> <!-- Denne skabelon gør arbejdet vise individuelle linjer i søjlediagrammet. Du vil sandsynligvis gøre det meste af din tweaking her. --> <XSL:skabelon Navn="ShowBar"> <XSL:Param Navn="BarDisplayLabel" /> <!-- etiket for at vise --> <XSL:Param Navn="BarPercent"/> <!-- Procent af total. --> <XSL:Param Navn="QueryFilterFieldName"/> <!-- Bruges til at springe til forespørgslen & filter --> <XSL:Param Navn="QueryFilterFieldValue"/> <!-- Bruges til at springe til forespørgslen & filter --> <XSL:Param Navn="TotalItems" /> <!-- samlet antal denne barlabel --> <Tr> <!-- Baren mærke sig selv. --> <TD klasse="MS-formbody" bredde="30%"> <!-- Denne næste sæt af udsagn bygger en forespørgselsstreng, der tillader os at bore ned til en filtreret visning af de underliggende data. Vi gør brug af et par ting her: 1. Vi kan give FilterField1 og FilterValue1 til en liste til at filtrere på en kolonne. 2. SharePoint er forbi en central parameter for os, ListUrlDir, der peger på den underliggende liste som denne DVWP "kører". Er ikke XSL-sjov? --> <XSL:tekst Deaktiver-output-undslippe="Ja"> <![CDATA[<en href ="]]></XSL:tekst> <XSL:værdi af Vælg="$ListUrlDir"/> <XSL:tekst Deaktiver-output-undslippe="Ja"><![CDATA[?FilterField1 =]]></XSL:tekst> <XSL:værdi af Vælg="$QueryFilterFieldName"/> <XSL:tekst Deaktiver-output-undslippe="Ja"><![CDATA[&FilterValue1 =]]></XSL:tekst> <XSL:værdi af Vælg="$QueryFilterFieldValue"/> <XSL:tekst Deaktiver-output-undslippe="Ja"><![CDATA[">]]></XSL:tekst> <XSL:værdi af Vælg="$BarDisplayLabel"/> <XSL:tekst Deaktiver-output-undslippe="Ja"><![CDATA[</en>]]></XSL:tekst> <!-- Den næste bit viser nogle tal i formatet: "(i alt / % af den samlede)" --> (<XSL:værdi af Vælg="$TotalItems"/> / <!-- Dette skaber en dejlig procent etiket for os. Tak, Microsoft! --> <XSL:Call-skabelon Navn="percentformat"> <XSL:med param Navn="procent" Vælg="$BarPercent"/> </XSL:Call-skabelon>) </TD> <!-- Endelig, udsender en <TD> Tag til bar selv.--> <TD> <tabel CellPadding="0" CellSpacing="0" grænsen="0" bredde="{runde($BarPercent * 100)+1}%"> <Tr BgColor="rød"> <XSL:tekst Deaktiver-output-undslippe="Ja"><![CDATA[&nbsp;]]></XSL:tekst> </Tr> </tabel> </TD> </Tr> </XSL:skabelon> <!-- Dette er taget direkte fra nogle XSL, jeg fandt i en MS skabelon. --> <XSL:skabelon Navn="percentformat"> <XSL:Param Navn="procent"/> <XSL:Vælg> <XSL:Hvornår test="format-nummer($procent, '#,##0%;-#,##0%')= 'NaN'">0%</XSL:Hvornår> <XSL:ellers> <XSL:værdi af Vælg="format-nummer($procent, '#,##0%;-#,##0%')" /> </XSL:ellers> </XSL:Vælg> </XSL:skabelon> </XSL:stylesheet>

Resultaterne:

XSL ovenfra genererer denne graf:

billede

Foretag detaljeopløftning til de underliggende data ved at klikke på statuskoden:

billede

Afsluttende tanker:

Dette kan generaliseres?

Jeg elsker denne graftegning koncept, men jeg hader det faktum, at jeg er nødt til at gå ind og gøre så meget hånd-kodning. Jeg har givet en lille tanke til om det kan generaliseres og jeg er optimistisk, men jeg er også lidt bange, at der kan være en mur eller andet sted langs den sti, der ikke vil tilbyde en arbejde-omkring. Hvis nogen har nogle gode idéer på dette, venligst gøre en note i kommentarer eller e-mail mig.

Lodret grafer:

Dette er en horisontal søjlediagram. Det er bestemt muligt at oprette en lodret diagram. Vi skal bare ændre HTML-koden. Jeg ville starte på samme måde: Oprette en HTML-repræsentation af et lodret søjlegraf og derefter finde ud af hvordan man får der via XSL. Hvis nogen er interesseret i at, Jeg kunne blive overtalt til at prøve det og arbejde ud the kinks. Hvis nogen har allerede gjort det, fortæl mig det, så link jeg til din blog 🙂

Jeg tror, at udfordring med en lodret Graf er, at etiketterne for grafen er sværere at administrere, men bestemt ikke umuligt.

Feltet navn Gotcha:

Der er mindst to ting til at se ud med din feltnavne.

Første, et feltnavn med en plads er at være undsluppet i XSL. Dette vil sandsynligvis være et problem her:

        <XSL:variabel Navn="totalProposed" 
Vælg="Grev(/dsQueryResponse/rækker/række[normalisere plads(@Status) = 'Foreslog'])" />

Hvis din "Status" kolonne hedder faktisk "statuskode" så er du nødt til at henvise til det som "Status_x0020_Code":

   <XSL:variabel Navn="totalProposed" 
Vælg="Grev(/dsQueryResponse/rækker/række[normalisere plads(@Status_x0020_Code) = 'Foreslog'])" />

Anden, og jeg er lidt fuzzy på dette, men du skal også være på vagt for feltnavnet ændres. Hvis du navngiver din felt "statuskode" og så senere på, omdøbe den til "AFE Status", det "interne navn" ændrer ikke. Det interne navn vil stadig være "statuskode" og skal blive refereret til som "Status_x0020_Code". "Andre ressourcer" links kan hjælpe med at diagnosticere og løse slags problemer.

Om at farve:

Jeg tog "rød" fordi det er glædeligt for mig i øjeblikket. Det ville ikke være en big deal at vise forskellige farver for at give mere end blot en visuel beskrivelse af en række, men skal også indeholde et nyttig KPI. For eksempel, Hvis procentdelen af "gået i stå" AFES er > 10% derefter vise det røde, ellers Vis det i sort. Brug <XSL:Vælg> at opnå dette.

Andre ressourcer:

Happy omdanne!

<afslutning />

Abonner på min blog!

SharePoint giver ikke “Hvem har adgang” Rapporter

OPDATERING 01/28/08: Dette codeplex projekt løser problemet: http://www.codeplex.com/AccessChecker. Jeg har ikke brugt det, men det ser lovende, hvis dette er et problem, du har brug for til adresse i dit miljø.

OPDATERING 11/13/08: Joel Oleson skrev op en meget god stilling på større sikkerhed forvaltning spørgsmålet her: http://www.sharepointjoel.com/lists/posts/post.aspx?Liste = 0cd1a63d % 2D183c % 2D4fc2% 2 D 8320% 2Dba5369008acb&ID = 113. Det knytter sig til en række andre nyttige ressourcer.

Forum brugere og klienter stille ofte et spørgsmål i den retning: "Hvordan jeg genererer en liste over alle brugere med adgang til et websted" eller "hvordan kan jeg automatisk advare alle brugere med adgang til listen om ændringer af listen?"

Der er ingen ud af boksen løsning for dette. Hvis du tænker over det et øjeblik, Det er ikke svært at forstå hvorfor.

SharePoint sikkerhed er meget fleksibel. Der er mindst fire hovedkategorier af brugere:

  • Anonyme brugere.
  • SharePoint-brugere og grupper.
  • Active Directory-brugere.
  • Formularbaseret godkendelse (FORMULARBASERET GODKENDELSE) brugere.

Fleksibilitet betyder, at set fra et sikkerhedssynspunkt, enhver given SharePoint site bliver dramatisk anderledes fra en anden. For at generere en rapport over liste, et behov for at fastslå, hvordan webstedet er sikret, forespørge på flere forskellige bruger profil repositories og derefter præsentere det på en nyttig måde. Det er et svært problem at løse generisk.

Hvordan er organisationer beskæftiger sig med dette? Jeg ville elske at høre fra dig i kommentarerne eller e-mail.

</slutningen>

MOSS fortæller mig min kolonnenavn er reserveret eller i brug … Men det er ikke

OPDATERING 12/04/07: Se denne Microsoft KB (http://support.microsoft.com/kb/923589) Relaterede oplysninger.

Faktisk, Det viser sig, det er, Men tricksy MOSS var nødt til at gøre det vanskeligt.

Min kunde gør nogle udviklingsarbejde på hans MOSS site i weekenden. Det er lidt af et virvar, hvad han faktisk gjorde, Men slutresultatet er dette:

  • Han forsøger at tilføje en webstedskolonne, kaldet "mængde" og mos svar: "Kolonnenavnet, du indtastede er allerede i brug eller reserveret. Vælg et andet navn."
  • Han forsøger at føje det til et andet miljø og der virker. Derfor, "Antal" er ikke et reserveret navn.
  • Han forsøger at finde en eksisterende webstedskolonne opkaldt "mængde" i denne gruppe af websteder. Han kan ikke finde det.

Jeg gjorde nogle forskning, og endda nogle kodning, voksbehandlet filosofiske og endelig fandt at en kolonne med navnet mængde gjorde, Faktisk, findes. Det var i "_Skjult" gruppe. Dermed, Vi kunne ikke finde det via SharePoint-brugergrænsefladen.

Hvordan kom det der? Jeg ved det ikke, men jeg har en teori om (eller som min kone ville kalde det, "blah blah blah"). Et sted langs linjen, en fabelagtig fyrre skabelon blev tilføjet og sandsynligvis aktiveret på et websted i gruppen af websteder. Det blev derefter deaktiveret (eller webstedet fjernes). Webstedskolonnen, dog, forblev men i den "_Skjult" gruppe. Hvis nogen ved bedre, Lad mig vide via e-mail eller sende i kommentarerne.

SharePoint fortalte sandheden. Det er næppe værd at påpege, at denne meddelelse ikke er så hjælpsom som det kunne være. Det ville være rart at se at besked gaffel i to forskellige beskeder i fremtiden: 1) Sige, at kolonnenavn er reserveret eller det er ikke. 2) Hvis det ikke er forbeholdt, Vis sitet, eller i det mindste gruppen, hvor kolonnenavnet bruges allerede.

</slutningen>

Præsentere OM Data Via en brugerdefineret liste (eller, Endnu en anden OM Data Displayor [ligesom YACC, men forskellige])

I dag, Jeg tilbragte en håndfuld timer opspore den egentlige årsag bag meddelelsen "kolonnenavnet, du indtastede er allerede i brug eller reserveret. Vælg et andet navn."

Den pågældende kolonne kunne oprettes, slettes og genoprettes i et andet miljø, så jeg vidste, det ikke var et reserveret navn. Dog, Jeg ikke kunne simpelthen finde kolonnen overalt via standard SharePoint-brugergrænsefladen på alle websteder i gruppen af websteder.

Jeg indsendt til MSDN fora her og den ukuelige Andrew Woodward pegede mig i retning af de underliggende objekt modeldata.

Jeg gik til CodePlex at finde nogle værktøjer, der ville hjælpe mig peer i den underliggende OM data og hjælpe mig med at finde ulejlighed.

Jeg forsøgte flere værktøjer og de var meget cool og interessant men i sidste ende, UI ikke var god nok til mit formål. Jeg kritiserer ikke dem på nogen måde, men klart værktøj-beslutningstagere havde ikke mit problem i tankerne når de oprettet deres UI :). De fleste mennesker synes at investere en hel del tid og kræfter i at skabe arbejdsstation / klientprogrammer, som giver træet visninger, Højreklik på kontekstmenuer osv.. Disse er rart og alle, men det er en masse arbejde at oprette en top-of-the-line brugeroplevelse, der er også meget fleksibel.

Jeg har virkelig brug for et svar på dette problem. Det forekom mig, at hvis jeg kunne få alle webstedskolonner i gruppen af websteder i en brugerdefineret liste, Jeg kunne filtrere, sortere og oprette visninger, der ville hjælpe mig med at finde denne angiveligt eksisterende kolonne (som det gjorde, BTW). Jeg gik videre og gjorde, og en time eller to senere, havde alle mine webstedskolonner indlæses i en brugerdefineret liste med gruppering, sortering og så videre. Jeg fandt mit svar fem minutter senere.

Hvis og når jeg tager med succes over hele verden, Jeg tror jeg vil dekret om at alle SharePoint værktøjer udbydere alvorligt overveje surfacing deres objekt modeldata i en brugerdefineret liste. På den måde, Jeg har magt for at søge nogen vil måde jeg (begrænset, Selvfølgelig, af standard sharepoint-funktioner).

SharePoint Designer brugerdefineret arbejdsproceshandling — Bemærkning om <FieldBind Designer Type =”StringBuilder” … />

Bare en hurtig bemærkning, at der er en meget vigtig forskel mellem disse to definitioner:

<FieldBind felt = "InParam1" DesignerType = "StringBuilder" Id = "2" Tekst = "Input parameter #1" />

versus:

<FieldBind felt = "InParam1" Id = "2" Tekst = "Input parameter #1" />

Først viser gerne dette i SPD:

billede

mens de sidstnævnte shows som dette:

billede

Jeg er ikke sikker på, hvor nyttige disse skærmbilleder er, men jeg bestræber mig på at gøre dem, så du bliver nødt til at se dem 🙂

Observation er dette: StringBuilder tillader jer hen til opbygge en streng (naturligvis) ved at blande sammen Strengkonstanter og arbejdsprocesdata (via "Tilføj opslag" knappen i nederste venstre hjørne). Når du bruger knappen Tilføj opslag, det indsætter en token i form"[%token %]". Når SharePoint påberåber sig din brugerdefineret handling, (C# kode i mit tilfælde), SharePoint passerer tokenet, selv, ikke værdi af token. Hvis du bruger designer standardtypen (den anden type), SharePoint udvider token og passerer faktiske værdi af tokenet til din handling.

StringBuilder = dårlig, standard designer type = godt.

Selvfølgelig, Det er ikke, hvad jeg virkelig mener. Bare ikke prøve og passerer en parameter til din brugerdefineret handling, når designeren Skriv = StringBuilder. Bruge standardtypen designer og kæde en StringBuilder skal det op foran hvis du har brug at opbygge komplekse strenge i din arbejdsgang (hvilket i øvrigt er præcis, hvad man gør hen til skabe en dynamisk genstand for handlingen e-mail, men det er et emne til en anden blog-indtastning, har har).

<afslutning />

Tidlig arbejdsproces aktivering — En ikke-medicinsk løsning

OPDATERING: Se denne MSDN diskussion, især den sidste post: http://forums.microsoft.com/MSDN/showpost.aspx?postid=2631057&siteid=1. Det beskriver en tilstand, der kan kort sagt kredsløb hele denne ting. Kort sagt, Det kan være så simpelt som at gøre mindst et af felterne obligatorisk.

Jeg har et dokumentbibliotek, der understøtter otte indholdstyper.

Jeg har en SharePoint Designer arbejdsprocessen, der ønsker at beregne og tildele en "rykker dato" ved blot at fratrække 30 dage fra en anden kolonne, "forfaldsdato". Dette bør kun ske for én af de indholdstyper, "Forsikring". Business målsætning er at udarbejde en KPI, der viser to kategorier af forsikringsdokumenter: "ved at udløbe" og "er udløbet." (Du kan læse mere om denne form for KPI og flere betydelige drilldown Her).

Jeg har konfigureret arbejdsproces brand når et nyt element oprettes, og når et element er ændret. Ideen er, at når en forsikring dokument er uploadet, vi beregne en "advarsel dato" baseret på udløbsdato. Et par synspunkter arbejde i forbindelse med en KPI-liste til at fremhæve disse betingelser, når brugere trykker deres hjemme side.

Denne strategi virker ikke, når jeg uploader et dokument.

Jeg uploade dokumentet og forelagde jeg med meta data indrejse skærmen. På dette punkt, Jeg er allerede i knibe. SharePoint har allerede, for tidligt fra mit perspektiv, fyret arbejdsprocessen. Jeg har ikke haft en chance for at vælge den rigtige indholdstype eller tildele en forfaldsdato. På samme tid, arbejdsprocessen udløses ikke, når jeg ramt sendeknappen på dette tidspunkt. Der er nogle indbyggede logik, som "mener" der først indsende er en del af den "oprette" Event. Så … min arbejdsproces er fyret og hvornår det udføres, Det blev vedtaget standard meta dataværdier.

Det bedste arbejde-omkring jeg kender til er at indsætte en "pause indtil" aktivitet i arbejdsprocessen. Jeg har arbejdsproces pause for 1 minut. Mens det pauser, Jeg vælger den rigtige indholdstype, Angiv metadata. Pause fuldender og arbejdsprocessen provenu efter behov. (Bemærk, at i mine omgivelser, timeren arbejdsprocesaktiviteter fra SPD arbejde ikke ud af kassen. Du kan have den samme ulejlighed. Se Her for flere detaljer).

Jeg kan ikke lide "magiske forsinkelse" arbejde-omkring. Hvad sker der, hvis brugeren overfører et dokument og telefonen ringer og den efterfølgende samtale outlasts pause? Jeg kan gøre det længere pause, men jeg kan stadig lide ikke det.

Jeg skrev om dette på MSDN fora her: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2430725&SiteID=1