Løsning uden kode: visning af dage, siden et listeelement senest blev ændret

Oversigt: brugerdefinerede forældede rapporter uden kode

En af de ofte anmodede funktionelle dele af et SharePoint-websted er en aldersfordelt rapport for enten opgaver eller listeelementer. Hvor mange dage/måneder er det med det samme, at dette listeelement sidst blev ændret?

På overfladen er dette tilsyneladende en meget simpel anmodning. Efter alle har vi datoer for de elementer, der oprettes og ændres, har vi mulighed for at gemme brugerdefinerede datoer, når bestemte ændringer af elementer foregår via hændelsesmodtagere. Vi har beregnet kolonner, hvor vi kan inkludere Excel-lignende formler til at fungere sammen med vores oplysninger. Det ser ud til at være en ret lige stilling. Vi vælger et datofelt, opretter en beregnet kolonne og gør en formel noget langs linjerne i [DateField] – [i dag]. Ah, ikke så hurtigt, men Da alle, der har forsøgt at bruge denne "simple" opgave, ved at prøve at bruge noget som [i dag] i en beregnet kolonne, forårsager problemer. Prøv at indsætte [i dag] i formel feltet for den beregnede kolonne får du en fejlmeddelelse i stil med følgende:

Hvorfor er dette? Det skal du gøre med den måde, beregnede kolonner beregnes på.

Lad os tage en simpel formel, f. eks.:

= Hvis ( [Kolonne1] <= [Kolonne2], "OK", "ikke OK")

Dette siger, at hvis Kolonne1 er mindre end eller lig med Kolonne2, så vises OK, ellers vises der ikke OK. Dette er en forholdsvis typisk grundlæggende formel for en beregnet kolonne, og den foretager en grundlæggende antagelse af det listeelement, der indeholder disse kolonner: værdierne for Kolonne1 og Kolonne2 vil aldrig kunne ændres uden en opdaterings hændelse på listeelementet.

Det er rigtigt, beregnede kolonner genberegnes kun, når listen opdateres (eller oprettes), da de forudsætter, 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.

Nu var jeg ikke i møde, hvor de har besluttet, at dette er den måde, hvorpå beregnede kolonner ville fungere, men hvis jeg skulle have et uddannet bud, ville jeg skulle antage, at de fungerer på denne måde for ydeevne. Forestil dig, at du har en liste over flere tusinde elementer, som hver indeholder en beregnet kolonne, der har brug for en "live"-opdatering. Det vil sige, at nogle mekanismer, måske et timerjob, skulle gentage gennem hvert element, der indeholder den pågældende beregnede kolonne, hver gang og opdaterer dens værdi. Dette kan være særdeles taxingt med hensyn til ydeevnen, fordi du har større installationer, men det kan hele tiden køre og ændre ting. Det er kun mit gæt, men det er meget lidt fornuftigt, hvis du tænker på det.

Der er nogle forslag til lignende løsninger, der bevares her, som kan medføre, at SharePoint er ved at oprette en i dag-værdi ved først at oprette en kolonne med navnet idag og derefter tilføje den i formlen og derefter slette den. Det er både godt og godt, men husk, hvad jeg sagde om, når beregnede kolonner opdateres. Denne værdi ændres kun, når elementet opdateres, hvilket betyder, at værdierne snart er forkerte, især hvis der er tale om en datoberegning.

Jeg har set andre, der bruger intelligente JavaScript til at skrive værdierne til siden. Det fungerer også, men jeg er ret meget categorically mod klientscripts, når det kan undgås.

Installationen

Hvad skal jeg gøre? Beregnede kolonner er uden for spørgsmålet for det såkaldte "midlertidige" funktioner som i dag. Det er muligt, at vi kan udvikle en bestemt kode for at kunne gøre dette for os som en beregnet kolonne, et timerjob eller en planlagt proces til at komme sammen og opdatere alle enkeltvarer, der kræver denne beregning. Det giver os en løsning på det problem, jeg har nævnt i det sidste afsnit, og det er desuden en brittle løsning, der er meget specifik for det pågældende websted/den pågældende liste/kolonne. Øverst på disse to bekymringer skal du også finde en nerdy-Guy, f. eks selv, der ved, hvordan du kan kode og lokke ham til at udvikle denne løsning for dig. Men der er en nemmere måde!

Hvis du har tilladelse til at oprette felter og redigere sider på dit websted, og du har en smule viden om XSLT og oprette visninger, kan du sammensætte en XSL-skabelon, der kan medtages i en listevisning, og faithfully beregne din værdi, hver gang siden bliver bedt om det. Dette scenarie fjerner vores problem med ydeevnen og kræver ikke brugerdefineret kode til at blive udviklet og implementeret via en løsning.

Bedste. Hvordan gør vi det?

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

2. Opret det felt, der skal fungere som 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 den pågældende liste, der indeholder både kilde-og pladsholder kolonnerne.

5. Overfør XSL-skabelonen til typografibiblioteket.

6. Angive egenskaben "XSL-link" for webdelen Listevisning via BRUGERGRÆNSEFLADEN.

7. Det lykkedes!

Lad os prøve at gennemgå et eksempel på use case og gennemgå gennemførelsen. Vores kunde ønsker en visning af deres hovedliste, der fortæller, hvor lang tid et bestemt listeelement har været placeret på sin status. Denne liste indeholdt en brugerdefineret webstedsindholdstype, der er afledt af elementtypen og føjet til listen. Der var allerede en hændelsesmodtager på et sted, der registrerer, hver gang feltet status på listeelementet blev ændret og gemt den pågældende dato til en kolonne med navnet "dato status ændret". Det er ikke nødvendigt at bruge denne ledning, og du kan gøre det med et hvilket som helst datofelt (det sker på samme måde som i vores implementering, men det er gratis at eksperimentere). Det mindste, du skal bruge, er dit kilde datofelt og pladsholderfelt til din beregning (mere i næste afsnit) føjet til listen, men jeg foreslår, at du bruger webstedskolonner og webstedsindholdstyper, hvis du vil genbruge denne løsning på andre steder på dit websted.

Vi har vores kilde dato, som vi kan bruge i vores beregning mod dagens dato. Nu kan vi oprette en brugerdefineret webstedskolonne, der skal bruges som container 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 redigere element formularer, men du kan vælge at få vist i visningerne, fordi vi ikke vil have, at brugerne angiver vilkårlige værdier i til denne kolonne. Det kan være forvirrende, hvad det kan være, at det ikke vises i visningerne osv.

Nu hvor vi har vores websted-kolonne, kan vi tilføje den til vores indholdstyper, der skal bruges på vores liste. Derefter skal vi oprette den visning, der senere skal tilpasses med vores XSLT. Sørg for, at du opretter en standardvisning, der indeholder din kilde datokolonne, og den nye beregnede kolonne, der fungerer som pladsholder for den beregnede værdi.

Vi har nu alt det, vi skal bruge for at kunne understøtte vores brugerdefinerede aldersfordelings rapport. Alt det, der forbliver, opretter vores XSL-skabelon, overfører den til webstedets typografibibliotek og sammenkæder den med listevisningen. Den XSL-skabelon, vi bruger, skal indeholde nogle af de almindelig SharePoint-genererede markeringer for at oprette visningen samt vores egen brugerdefinerede markering, der bruges til at tilsidesætte visse dele af dette og beregne vores ønskede værdi for os.

Med kredit, hvor kredit er forfalden, er XSL-skabeloner til at foretage de faktiske beregninger, jeg bruger til denne løsning, graciously leveret af "swirch" i MSDN-foraene:
http://social.msdn.Microsoft.com/forums/en-us/sharepointcustomization/Thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Downloade XSL-typografien (aging.zip) Jeg har placeret sammen her:
https://OneDrive.live.com/?CID=c262e8e2d59a86d9&permissionsChanged = 1&-id = c262e8e2d59a86d9! 104

Hvis du åbner dette i din foretrukne teksteditor, får du vist masser af normal SharePoint XSL-kode til gengivelse af visningerne, hvis du fortsætter med at rulle ned til linje 357, vises starten på de brugerdefinerede skabeloner, som jeg har føjet til markeringen, den første, der er "DateDiff"-skabelonen, efterfulgt af "Beregn-juliansk-dag" og "FieldRef_printTableCell_EcbAllowed Days_x0020_At_x0020_Status. Disse er de tre skabeloner, der skal bruges til at få vist vores beregninger i vores visninger. Hvis du vil bruge forskellige feltnavne, end der er angivet tidligere i denne artikel, skal du gennemgå disse skabeloner og erstatte eventuelle referencer til de andre navne. Husk, at du skal bruge det interne navn på feltet ikke til visningsnavnet.

Når du er tilfreds med, at skabelonen er klar til at blive sendt, skal du gå til dit typografibibliotek og overføre det under mappen "XSL-typografiark" og derefter kopiere linket til filen. 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 din liste, og vælg 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 nedadvendt pil i øverste højre hjørne. Fra denne menu skal du vælge "Rediger webdel".

Der åbnes en menu med webdelen i højre side af browservinduet.

Klik på afsnittet + for afsnittet "Diverse", og Find egenskaben "XSL-link".

Indsæt linket til din XSL-fil i det typografibibliotek, 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 er konfigureret korrekt, bør du nu se tal i kolonnen "dage efter status".

Til sidst kan du se her, hvordan det ser ud med nogle testdata af forskellige datoer:

Oversigt:

Der er følgende: en passe, der er formateret, robust og bedre at udføre en aldersfordelt rapport i SharePoint., komplet med en simpel installation uden kode. Dette har ret meget nogle potentielle applikationer fra en use case, som vi udforskede her. Et andet almindeligt scenarie for denne type rapport vedhæfter det til en opgaveliste, så du kan se, hvor lang tid der er gået, da en opgave blev oprettet med et hurtigt overblik.

God fornøjelse!

--Justin

Justin Joyce, LANtek

Kommentarer

Manglende
trin 10/8/2012 3:51 AM
OK, jeg fulgte trinene, men der skal være noget, der mangler-hvordan er XSL ved, hvilken dato, du skal bruge, eller hvilket felt du vil tilføje dagene? hader det, når trinene mangler.

Ingen-kode, der er aftalt!
8/30/2012 12:12 PM
Jeg accepterer – jeg tror ikke, at dette tæller "ingen kode".
Med nogle screwup i SharePoint har jeg en arbejds-beregnet kolonne med i dag... Det er ikke sikkert, at du ikke kan få det til at gøre det igen, men det er stadig der og fungerer.

Formel for "dage ved status" beregnet kolonne?
5/2/2012 7:39 AM
Justin – hvad er den formel, du har brugt til din kolonne "dage ved status" beregnet webstedskolonne (pladsholder kolonne)? Var det "= Today"?

SharePoint 2007
12/2/2011 11:29 AM
Jeg har i øjeblikket ikke forsøgt at anvende denne løsning på SharePoint 2007, men jeg kigger på den. Der er desværre ingen XslLink-egenskab, der er over fladt i webdelen via BRUGERGRÆNSEFLADEN.

Flot indlæg
11/30/2011 9:53 AM
Hej,
Flot indlæg.
Jeg bruger SharePoint 2007.
Jeg har ikke en diverse sektion som nævnt ovenfor.
Har du trin til en SP2007-konfiguration?
Tak.

Sv: løsning uden kode: visning af dage, siden et SharePoint-listeelement senest blev ændret
10/11/2011 8:24 AM
Hej Chris.
flot søgning!
Jeg kigger på det, du har publiceret forhåbentlig, senere i dag, og du kan se, om jeg kan gøre denne løsning lidt mere robust.
Jeg er glad for, at du syntes godt om indlægget, og jeg er meget glad for at kunne finde en løsning til det europæiske datoformat. :)
-Justin

Løsning for europæiske datoformater
10/11/2011 6:45 AM
Hej Justin
Vi fandt en løsning til det problem, jeg tidligere har nævnt tidligere på denne side.
https://sharepointbydummies.wordpress.com/2011/07/13/Possible-work-around-to-date-format-Issue-SharePoint-2010/

Europæiske datoformater
10/7/2011 3:59 AM
Hej Justin
Dette er en virkelig god løsning tak, og du kan kun se, hvordan jeg har brugt de sidste to dage. Men jeg har lidt af et problem med det, og jeg var håber, du kunne hjælpe mig med.
Jeg har ændret din kode en smule for at calcultate antallet af dage, indtil der sker noget, i stedet for at skifte variablerne i den sidste linje i funktionen "DateDiff".

<xsl: value-of Select = "$JulianToday-$JulianStartDate" ></xsl: værdi-af>

Men jeg kan ikke få det til at caclulate forskellen korrekt i halvdelen af tiden. Så hvis du vil have en forekomst med denne dato (Formatér DD/MM/YYYY);

30/12/2011

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

12/10/2011

Det beregnes som om 10-dec-2011 i stedet for 12-okt-2011.
Jeg har prøvet blot at skifte placeringen af dage-og månedsværdier i variablen "JulianStartDate", som det er tilfældet.

<xsl: with-param Name = "month" Select = "understreng (ddwrt: Formaterdatoogklokkeslæt (String ($StartDate), 1033, ' ÅÅÅÅMMDD '), 7, 2)"/>
<xsl: with-param Name = "Day" Select = "understreng (ddwrt: Formaterdatoogklokkeslæt (String ($StartDate), 1033, ' ÅÅÅÅMMDD '), 5, 2)"/>

Og dette rettede problem med den anden dato, men den var derefter forkert for den første dato!
Jeg har også forsøgt at ændre Formaterdatoogklokkeslæt-opkald for at bruge europæiske LCID'ER og forskellige ændringer til den sidste parameter i Formaterdatoogklokkeslæt (f. eks. ddMMyyyy, MMddyyyy) med de relevante justeringer i under strengens positionsparametre uden succes.
Jeg er meget glade for eventuelle råd, du kan tilbyde.
Tak,
Claus

Ingen-kode
9/21/2011 4:27 AM
Jeg tror ikke, at XSL fungerer som en "uden kode"-løsning, da det er et XSL-sprog, der ikke er noget – men ikke omfatter programmering. Ud over det: flot løsning tak!