Løsning uden brug af kode: viser antallet af dage, siden et listeelement sidst blev ændret

af Justin Joyce, LANtek

Oversigt: Brugerdefinerede aldersfordelte rapporter uden kode

En af de mange funktionelle dele af et SharePoint-websted, er en aldersfordelt saldoliste for enten opgaver eller listeelementer. Med andre ord, hvor mange dage/måneder er det siden, at dette listeelement sidst blev ændret?

På overfladen ser dette ud til at være en meget simpel anmodning. Vi har trods alt datoer for elementer, der oprettes og ændres, vi har mulighed for at gemme brugerdefinerede datoer, når visse ændringer af elementer finder sted gennem begivenhedsmodtagere. Vi har beregnede kolonner, hvor vi kan medtage Excel-lignende formler til at arbejde med vores oplysninger. Dette virker som et ret ligetil forslag. Vi vælger et datofelt, opretter en beregnet kolonne og laver derefter en formel noget i stil med [Datofelt] – [I dag]. Ah, dog ikke så hurtigt! Som alle, der har prøvet denne "enkle" opgave, ved, giver det problemer at prøve at bruge noget som [I dag] i en beregnet kolonne. Hvis du forsøger at indsætte [I dag] i formelfeltet for den beregnede kolonne, får du en fejlmeddelelse i retning af dette:

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

Lad os tage en simpel formel som eksempel:

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

Det eneste, der betyder, er, at hvis Kolonne1 er mindre end eller lig med Kolonne2, så vis OK, ellers vis Ikke OK. Dette er en ret typisk basisformel for en beregnet kolonne, og den opstiller en grundlæggende antagelse om det listeelement, der indeholder disse kolonner: Værdierne for Kolonne1 og Kolonne2 kan aldrig ændres uden en opdateringshændelse for listeelementet.

Det er rigtigt, beregnede kolonner genberegnes først, når listen opdateres (eller oprettes), da de antager, at de oplysninger, du beregner er indeholdt 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.

Jeg var ikke med på det møde, hvor de besluttede, at det er den måde, beregnede kolonner fungerer på, men hvis jeg skulle komme med et kvalificeret gæt, ville jeg antage, 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 skulle opdateres "live". Det ville betyde, at en eller anden mekanisme, måske et timerjob, skulle gentage gennem hvert element, der indeholdt den beregnede kolonne en gang imellem og opdatere dens værdi. Dette kan være ekstremt krævende med hensyn til ydeevne, fordi med større installationer kan dette job hele tiden køre og ændre ting. Det er bare mit gæt, men det giver ret meget mening, hvis du tænker over det.

Der findes nogle forslag til lignende løsninger, der flyder rundt derude, som involverer at narre SharePoint til at acceptere en værdi 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. Alt dette er fint, men husk, hvad jeg sagde om, hvornå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 dagsberegning.

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

Gennemførelse:

Så hvad skal jeg gøre? Beregnede kolonner er udelukket ved såkaldte "flygtige" funktioner som Today. Det er muligt, at vi kunne udvikle noget brugerdefineret kode til at tage sig af dette for os, f.eks. en beregnet kolonne, timerjob eller planlagt proces til at opdatere hvert enkelt element, der kræver denne beregning. Det bringer os dog tilbage til problemet med ydeevne, jeg nævnte i sidste afsnit, og derudover er det en skrøbelig løsning, der ville være meget specifik for det pågældende websted/liste/kolonne. Ud over disse to bekymringer ville du også være nødt til at finde en nørdet fyr, som mig selv, der ved, hvordan man koder og overtaler 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 inkluderes i en listevisning, og som fuldt ud beregner værdien, hver gang der anmodes om siden. Dette scenarie fjerner vores bekymring over ydeevnen og kræver ikke, at der udvikles og installeres brugerdefineret kode via en løsning.

Perfekt. Så hvordan gør vi det?

1. Opret eller vælg det felt, der skal fungere som vores kilde. Det skal være af datotypen.
2. Opret vores felt, der skal fungere som pladsholder for den værdi, der beregnes.
3. Føj begge disse felter til en indholdstype, og føj indholdstypen til en liste.
4. Opret en visning af listen, der indeholder både kilde- og pladsholderkolonnerne.
5. Upload XSL-skabelonen til biblioteket Typografier.
6. Angiv egenskaben "XSL-link" for webdelen Listevisning via brugergrænsefladen.
7. Det lykkedes!

Lad os se nærmere på et eksempel på en use case og gennemgå implementeringen. Vores kunde ønskede en visning af deres hovedliste, der fortæller dem, hvor længe et bestemt listeelement har ligget på sin status. Denne liste indeholdt en brugerdefineret webstedsindholdstype, der var afledt af elementtypen og blev føjet til listen. Der var allerede en hændelsesmodtager på plads, der registrerer, hver gang statusfeltet på listeelementet blev ændret, og gemte datoen i en kolonne med navnet "Datostatus ændret". Al denne ledningsføring er ikke påkrævet og kan udføres med ETHVERT datofelt (det er tilfældigvis vores implementering, men eksperimenter gerne). Det absolutte minimum, du skal bruge, er kildedatofeltet og pladsholderfeltet for at holde din beregning (mere om dette i næste afsnit) føjet til din liste, 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 af dags dato. Vi kan nu oprette en brugerdefineret webstedskolonne, der kan bruges som en beholder for vores beregnede værdi. I dette tilfælde valgte jeg at bruge en beregnet kolonne, da den ikke vil kunne ændres på formularerne for nyt eller redigeret element, men kan vælges til visning i visningerne, da vi ikke ønsker, at brugere indtaster vilkårlige værdier i denne kolonne. Det kan være forvirrende, hvorfor det ikke bliver vist i visningerne osv.

Nu hvor vi har vores webstedskolonne, kan vi føje den til vores indholdstyper, der skal bruges på vores liste. Derefter skal vi oprette vores visning, der senere vil blive tilpasset med vores XSLT. Sørg for, at du opretter en standardvisning, der indeholder kildedatokolonnen og den nye beregnede kolonne, der fungerer som pladsholder for den beregnede værdi.

Vi har nu alt på plads, som vi kræver for at understøtte vores brugerdefinerede aldersrapport. Det eneste, der er tilbage, er at oprette vores XSL-skabelon, uploade den til webstedets stilbibliotek og linke den til vores listevisning. Den XSL-skabelon, vi kommer til at bruge, kommer til at indeholde nogle normale SharePoint-genererede markeringer til at generere visningen samt vores egen brugerdefinerede markering, der bruges til at tilsidesætte visse dele af dette og beregne vores ønskede værdi for os.

XSL-skabelonerne til at lave de faktiske beregninger, jeg bruger til denne løsning, blev elskværdigt leveret af "swirch" på MSDN-foraene:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Download det XSL stylesheet (aging.zip), jeg har sammensat her:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

Hvis du åbner dette i din foretrukne teksteditor, vil du se masser af normal SharePoint XSL-markering til gengivelse af visningerne, hvis du bliver ved med at rulle ned til linje 357 vil du se starten på de brugerdefinerede skabeloner, som jeg tilføjede til markeringen, den første er "DateDiff"-skabelonen efterfulgt af "calculate-julian-day" og "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Dette er vores tre skabeloner, som kan foretage og vise vores beregninger i vores visninger. Hvis du skal 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 feltets INTERNE navn, ikke det viste navn.

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

Derefter skal du gå til listen og vælge den visning, du oprettede tidligere i denne artikel. Klik på "Rediger side" i menuen "Webstedshandlinger".

Find webdelen Listevisning på siden, og åbn menuen Webdel ved at klikke på den lille nedadvendte 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 biblioteket Typografier, som du kopierede 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 var konfigureret korrekt, bør du nu se tal i kolonnen "Status Dage kl.".

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

Oversigt:

Der var den: en flot formateret, robust og bedre ydende måde at oprette en forældelsesrapport på i SharePoint, komplet med en simpel implementering uden brug af kode. Dette har en hel del potentielle anvendelser 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, der er gået, siden en opgave blev oprettet.

God fornøjelse!

--Justin

Justin Joyce, LANtek

Kommentarer

Manglende trin
08-10-2012 03:51
ok jeg fulgte trinene, men der må mangle noget - hvordan ved XSL, hvilken dato der skal bruges, eller hvilket felt der skal tilføjes dage siden i? hader, når man misser skridt.

No-Code, enig!
30-08-2012 12:12
Jeg er enig - jeg tror ikke, at dette tæller som "ingen kode".
Interessant nok har jeg gennem nogle skruer op i SharePoint en fungerende beregnet kolonne, der bruger I dag... Jeg er ikke sikker på hvordan eller hvorfor, fordi jeg ikke kan få den til at gøre det igen, men den er der stadig og virker.

Formel for den beregnede kolonne med statussen "Dage kl."?
02-05-2012 07:39
Justin – Hvilken formel brugte du til den beregnede webstedskolonne "Status "Dage kl."-kolonne (pladsholderkolonne)? Var det "=idag"?

SharePoint 2007
2/12/2011 11:29
I øjeblikket har jeg ikke forsøgt at anvende denne løsning til SharePoint 2007, men jeg undersøger den. Desværre vises der ingen XslLink-egenskab på webdelen via brugergrænsefladen.

Fantastisk indlæg
2011/11/30 09:53
Hej!
Fantastisk indlæg.
Jeg bruger SharePoint 2007.
Jeg har ikke en Diverse-sektion som nævnt ovenfor.
Har du trin til en SP2007-konfiguration?
Tak.

Re: Løsning uden kode: Viser antallet af dage, siden et SharePoint-listeelement sidst blev ændret
10/11/2011 08:24
Hej Chris.
Fantastisk fund!
Jeg vil tage et kig på, hvad du postede forhåbentlig senere i dag og se, om jeg kan gøre denne løsning lidt mere robust.
Jeg er glad for, at du kunne lide indlægget, og jeg er meget glad for, at du var i stand til at finde en løsning på det europæiske datoformat. :)
-Justin

Løsning til europæiske datoformater
10/11/2011 06:45
Hej igen Justin,
FYI, jeg fandt 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 03:59
Hej Justin
Det er en rigtig god løsning tak, og lige den slags ting, jeg har brugt de sidste to dage på at lede efter! Men jeg har lidt af et problem med det, og jeg håbede, at du kunne hjælpe mig.
Jeg har ændret din kode lidt for at beregne antallet af dage, indtil der sker noget, snarere end siden, ved at skifte variablerne i den sidste linje af "DateDiff"-funktionen;

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

Jeg er dog kun i stand til at få den til at beregne forskellen korrekt halvdelen af tiden. Så for eksempel med denne dato (format dd/MM/åååå);

30/12/2011

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

12/10/2011

Den beregner som om 10-dec-2011 i stedet for 12-okt-2011.
Jeg prøvede simpelthen at skifte positionen 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 rettede problemet med den anden dato, men det var derefter forkert for den første dato!
Jeg har også forsøgt at ændre FormatDateTime-kaldene 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 held.
Jeg vil sætte stor pris på ethvert råd, du kan give.
Venlig hilsen
Karl

No-Code
21-09-2011 04:27
Jeg tror ikke, at XSL kvalificerer sig som en "no-code"-løsning, da det ikke er for alle at forstå XSL-sproget - men det involverer ikke programmering. Udover det: Fin løsning, tak!