Løsning uden kode: Visning af de dage, der er gået, siden et listeelement sidst blev ændret

Oversigt: Brugerdefinerede forfaldsrapporter uden kode

Et af de ofte anmodede funktionelle dele af et SharePoint-websted er en forfalden rapport for enten opgaver eller listeelementer. Med andre ord, hvor mange dage/måneder har det været, siden dette listeelement sidst blev ændret?

På overfladen synes dette at være en meget simpel anmodning. Når alt kommer til alt har vi datoer for elementer, der oprettes og ændres, vi har mulighed for at gemme brugerdefinerede datoer, når visse ændringer af elementer finder sted via hændelsesmodtagere. Vi har beregnede kolonner, hvor vi kan medtage Excel-lignende formler for at arbejde med vores oplysninger. Dette virker som et ret lige fremad forslag. Vi vælger et datofelt, opretter en beregnet kolonne og laver derefter en formel i stil med [Datofelt] – [I dag]. Men ikke så hurtigt! Som alle, der har forsøgt denne "enkle" opgave, ved, at forsøg på at bruge noget i stil med [I dag] i en beregnet kolonne forårsager problemer. Prøv at indsætte [I dag] i formelfeltet for den beregnede kolonne, så du får en fejlmeddelelse i stil med følgende:

Hvorfor er det her? Det har at gøre med den måde, beregnede kolonner beregnes på.

Lad os tage en simpel formel som et eksempel:

= HVIS( [Kolonne1]<=[Kolonne2], "OK", "Ikke OK")

Alt dette siger er, at hvis Kolonne1 er mindre end eller lig med Kolonne2, så vises OK, ellers vises Ikke OK. Dette er en ret typisk basisformel for en beregnet kolonne, og den giver en grundlæggende antagelse om det listeelement, der indeholder disse kolonner: Værdierne for Kolonne1 og Kolonne2 kan aldrig ændres uden en Opdater-hændelse på listeelementet.

Det er rigtigt, beregnede kolonner genberegnes kun, når listen opdateres (eller oprettes), da de antager, at de oplysninger, du beregner, findes i selve elementet. Dette skaber et problem, når du forsøger at bruge noget, der ændres uafhængigt af elementets felter, f.eks. dags dato.

Nu var jeg ikke på mødet, hvor de besluttede, at det er den måde, som beregnede kolonner ville fungere på, men hvis jeg skulle lave et kvalificeret gæt, ville jeg gå ud fra, at de fungerer på denne måde for ydeevnen. Forestil dig, hvis du havde en liste med flere tusinde elementer, som hver indeholdt en beregnet kolonne, der havde brug for en "live" opdatering. Det ville betyde, at en mekanisme, måske et timerjob, skulle gentages gennem hvert element, der indeholdt den beregnede kolonne så ofte og opdatere dens værdi. Dette kan være ekstremt beskatning med hensyn til ydeevne, fordi med større installationer kan dette job konstant køre og ændre ting. Det er bare mit gæt, men det giver en hel del mening, hvis du tænker over det.

Der er nogle forslag til lignende løsninger, der flyder rundt derude, der involverer at narre SharePoint til at acceptere værdien I dag ved først at oprette en kolonne med navnet I dag og derefter føje den til din formel og derefter slette den. Disse er alle godt, men husk, hvad jeg sagde om, når beregnede kolonner opdateres. Denne værdi ændres kun, når elementet opdateres, hvilket betyder, at dine værdier snart vil være forkerte, især i tilfælde af en dagsberegning.

Jeg har set andre bruge kloge JavaScript til at skrive værdierne til siden. Dette ville arbejde også, men jeg er stort set kategorisk imod klient script, når det kan undgås.

Implementering:

Så hvad skal jeg gøre? Beregnede kolonner er udelukket for såkaldte "flygtige" funktioner som i dag. Det er muligt, at vi kan udvikle en brugerdefineret kode, så vi kan tage os af dette, f.eks. en beregnet kolonne, et timerjob eller en planlagt proces, så vi kan komme med og opdatere hvert enkelt element, der har brug for denne beregning. Det bringer os tilbage til problemet med ydeevne, jeg nævnte i sidste afsnit selv, og derudover er det en skør løsning, der ville være meget specifik for det pågældende websted / liste / kolonne. Oven i disse to bekymringer, ville du også nødt til at gå finde en nørdet fyr, såsom mig selv, der ved, hvordan man kode og overtale ham til at udvikle denne løsning for dig. Men der er en nemmere måde!

Hvis du har rettigheder til at oprette felter og redigere sider på dit websted og har lidt viden om XSLT og oprettelse af visninger, kan du sammensætte en XSL-skabelon, der kan medtages i en listevisning, og som nøjagtigt beregner din værdi, hver gang der anmodes om siden. Dette scenarie fjerner vores bekymring over ydeevnen og kræver ikke, at brugerdefineret kode udvikles og implementeres via en løsning.

Perfekt. Hvordan gør vi det?

1. Opret eller vælg det felt, der skal fungere som vores kilde. Det skal være en datotype.

2. Opret vores felt, der skal fungere som en pladsholder for den værdi, der beregnes.

3. Føj begge disse felter til en indholdstype, og føj den pågældende indholdstype til en liste.

4. Opret en visning af listen, der indeholder både kilde- og pladsholderkolonnerne.

5. Overfør XSL-skabelonen til typografibiblioteket.

6. Angiv egenskaben "XSL Link" for webdelen Listevisning via brugergrænsefladen.

7. Det lykkedes!

Lad os se nærmere på et eksempel på use case og gennemgå implementeringen. Vores kunde ønskede en visning af deres hovedliste, der ville fortælle dem, hvor længe et bestemt listeelement havde siddet på dets status. Denne liste indeholdt en brugerdefineret webstedsindholdstype, der er afledt af elementtypen og føjet til listen. Der var allerede en hændelsesmodtager på plads, der registrerer, hver gang statusfeltet på listeelementet blev ændret og gemt den pågældende dato i en kolonne med navnet "Datostatus ændret". Alle disse ledninger er ikke påkrævet, og kan gøres med enhver dato felt (det bare så sker dette er vores implementering, men du er velkommen til at eksperimentere). Det mindste, du skal bruge, er dit kildedatofelt og pladsholderfelt til at holde beregningen (mere om dette i næste afsnit) føjet til listen, selvom jeg foreslår, at du bruger webstedskolonner og webstedsindholdstyper, hvis du ønsker at genbruge denne løsning andre steder på dit websted.

Så vi har vores kildedato, som vi kan bruge i vores beregning mod dags dato. Nu kan vi oprette en brugerdefineret webstedskolonne til brug som en beholder til vores beregnede værdi. I dette tilfælde valgte jeg at bruge en beregnet kolonne, da den ikke kan ændres i de nye eller redigerede elementformularer, men kan vælges til visning i visningerne, da vi ikke ønsker, at brugere indtaster tilfældige værdier i denne kolonne. Det kan være forvirrende, hvorfor det ikke vises i visningerne osv.

Nu, hvor vi har vores webstedskolonne, kan vi føje den til vores indholdstyper, der skal bruges på vores liste. Dernæst skal vi oprette vores visning, der senere tilpasses med vores XSLT. Sørg for at oprette en standardvisning, der indeholder din kildedatokolonne og den nye beregnede kolonne, der skal fungere som pladsholder for den beregnede værdi.

Vi har nu alt på plads, som vi vil kræve for at støtte vores brugerdefinerede aldringsrapport. Det eneste, der er tilbage, er at oprette vores XSL-skabelon, uploade den til webstedets typografibibliotek og knytte den til vores listevisning. Den XSL-skabelon, vi skal bruge, vil indeholde nogle normale SharePoint-genererede markeringer til at generere visningen samt vores egne brugerdefinerede markeringer, der bruges til at tilsidesætte visse dele af dette og beregne vores ønskede værdi for os.

Give kredit, hvor kreditten er forfalden, XSL skabeloner til at gøre de faktiske beregninger, jeg bruger til denne løsning blev elskværdig leveret af "swirch" på MSDN fora:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Download XSL-typografiarket (aging.zip) Jeg har samlet her:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&tilladelserChanged=1&id=C262E8E2D59A86D9!104

Når du åbner dette i dit foretrukne tekstredigeringsprogram, får du vist masser af normal SharePoint XSL-markering til gengivelse af visningerne. Hvis du fortsætter med at rulle ned til linje 357, vil du se starten af de brugerdefinerede skabeloner, som jeg har føjet til markeringen, hvor den første er skabelonen "DateDiff" efterfulgt af "calculate-julian-day" og "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Dette er vores tre skabeloner, der vil lave og vise vores beregninger i vores synspunkter. Hvis du vil bruge andre feltnavne end dem, der er angivet tidligere i denne artikel, skal du gennemgå disse skabeloner og erstatte eventuelle referencer til de andre navne. Husk, at til dette skal du bruge det INTERNE navn i feltet og ikke det viste navn.

Når du er tilfreds med, at skabelonen er klar, skal du gå til dit typografibibliotek og uploade den under mappen "XSL-typografiark" og derefter kopiere linket til filen ned. Dette giver os mulighed for nemt at foretage ændringer i det senere eller føje det til forskellige dele af webstedet, som vi vil.

Gå derefter til listen, og vælg den visning, du oprettede tidligere i denne artikel. I menuen "Webstedshandlinger" skal du klikke på "Rediger side".

Find webdelen Listevisning på siden, og åbn menuen Webdel ved at klikke på den lille nedadpegende pil i øverste højre hjørne. Vælg "Rediger webdel" i denne menu.

Dette åbner webdelens menu i højre side af browservinduet.

Klik på + for sektionen "Diverse", og find egenskaben "XSL Link".

Indsæt linket til din XSL-fil i typografibiblioteket, som du kopierede ned tidligere (dette kan være et relativt eller absolut link).

Klik på "OK" for at gemme ændringerne, og klik derefter på knappen "Stop redigering" på båndet "Side" øverst på siden.

Hvis alt er konfigureret korrekt, får du nu vist tal i kolonnen "Dage ved status".

Og endelig er her, hvordan det ville se ud med nogle testdata med forskellige datoer:

Oversigt:

Der er den: en pænt formateret, robust og bedre ydeevne måde at oprette en aldersfordelt rapport i SharePoint., komplet med en simpel implementering uden brug af kode. Dette har en hel del potentielle applikationer bortset fra den ene use case, vi udforskede her. Et andet almindeligt scenarie for denne type rapport er at vedhæfte den til en opgaveliste, så du hurtigt kan se, hvor lang tid det har været, siden en opgave blev oprettet.

God fornøjelse!

--Justin

Justin Joyce, LANtek

Kommentarer

Manglende trin 8-10-2012 3:51
ok Jeg fulgte trinnene, men der skal være noget mangler - hvordan vil XSL vide, hvilken dato at bruge, eller hvilket felt at tilføje de dage siden ind? hade det, når trin er savnet.

Ingen kode, aftalt!
30-08-2012 12:12
Jeg er enig - jeg tror ikke, det virkelig tæller som "ingen kode".
Interessant, gennem nogle skrue op af SharePoint, jeg har en arbejder beregnet kolonne ved hjælp af I dag ... ikke sikker på hvordan eller hvorfor, fordi jeg ikke kan få det til at gøre det igen, men den ene er der stadig og arbejder.

Formel for den beregnede kolonne "Dage ved status"?
02-05-2012 7:39
Justin – Hvad er den formel, du brugte til den beregnede webstedskolonne "Dage ved status" (pladsholderkolonne)? Var det "=i dag"?

SharePoint 2007
02-12-2011 11:29
I øjeblikket har jeg ikke forsøgt at anvende denne løsning til SharePoint 2007, men jeg ser ind på det. Desværre er der ingen XslLink-egenskab vist på webdelen via brugergrænsefladen.

Great Indlæg
30-11-2011 9:53
Hej
Great Post.
Jeg bruger SharePoint 2007.
Jeg har ikke en Misc sektion som nævnt ovenfor.
Har du trin til en SP2007-konfiguration?
Tak.

Re: Løsning uden kode: Visning af de dage, der er gået, siden et SharePoint-listeelement sidst blev ændret
11-10-2011 8:24
Hej Chris.
fantastisk find!
Jeg har tænkt mig at tage et kig på, hvad du indsendt forhåbentlig senere på i dag og se, om jeg kan gøre denne løsning lidt mere robust.
Jeg er glad for du kunne lide stillingen, og jeg er meget glad for du var i stand til at finde en løsning på det europæiske datoformat.
:) -Justin

Løsning til europæiske datoformater
11-10-2011 6:45
Hej igen Justin,
Til orientering fandt jeg en løsning på det problem, jeg nævnte tidligere på denne side;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Europæiske datoformater
07-10-2011 3:59
Hej Justin
Dette er en rigtig god løsning tak, og bare den slags ting, jeg har brugt de sidste to dage på udkig efter! Men jeg har lidt af et problem med det, og jeg håbede du kunne hjælpe mig.
Jeg har ændret din kode en smule for at beregne antallet af dage, indtil der sker noget, i stedet for siden, ved at skifte variablerne i den sidste linje i funktionen "DateDiff";

<xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of>

Men jeg er kun i stand til at få det til at caclulate forskellen korrekt halvdelen af tiden. Så for eksempel med denne dato (format dd/MM/åååå);

12-30-2011

Den beregner korrekt, men med denne dato (samme format)

10-12-2011

Den beregner, som om 10-dec-2011 i stedet for 12-okt-2011.
Jeg forsøgte blot at skifte positionerne for dags- og månedsværdierne i variablen "JulianStartDate", sådan her;

<xsl:with-param name="Month" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),7,2)"/>
<xsl:with-param name="Day" select="substring(ddwrt:FormatDateTime(string($StartDate), 1033, 'yyyyMMdd'),5,2)"/>

Og dette løste problemet med den anden dato, men det var så forkert for den første dato!
Jeg har også forsøgt at ændre FormatDateTime-kald til at bruge europæiske LCID'er og forskellige ændringer af den sidste parameter i FormatDateTime (f.eks. ddMMyyyy, MMddyyyy) med de relevante justeringer af understrengens positionsparametre uden succes.
Jeg vil sætte stor pris på ethvert råd, du kan tilbyde.
Tak
Chris

Ingen kode
21-09-2011 4:27
Jeg tror ikke, at XSL kvalificerer som en "no-code" løsning, som forstå XSL sprog er ikke for alle - men det involverer ikke programmering. Ud over det: Dejlig løsning, tak!