Løsning uten kode: Viser dagene etter at et listeelement sist ble endret

Oversikt: Egendefinerte aldersfordelingsrapporter uten kode

En av de ofte forespurte funksjonsdelene på et SharePoint-område er en aldersfordelingsrapport for oppgaver eller listeelementer. Med andre ord, hvor mange dager/måneder har det vært siden dette listeelementet sist ble endret?

På overflaten ser dette ut til å være en veldig enkel forespørsel. Tross alt har vi datoer for elementer som opprettes og endres, vi har muligheten til å lagre egendefinerte datoer når visse endringer i elementer finner sted gjennom hendelsesmottakere. Vi har beregnede kolonner der vi kan inkludere Excel-lignende formler for å arbeide med informasjonen vår. Dette virker som et ganske rett frem forslag. Vi velger et datofelt, oppretter en beregnet kolonne og gjør deretter en formel noe langs linjene i [DateField] – [Today]. Ah, ikke så fort skjønt! Som alle som har forsøkt denne "enkle" oppgaven vet, forårsaker det problemer å prøve å bruke noe sånt som [I dag] i en beregnet kolonne. Prøv å sette inn [Today] i formelboksen i den beregnede kolonnen, og du får en feilmelding som dette:

Hvorfor er dette? Vel, det har å gjøre med måten beregnede kolonner beregnes på.

La oss ta en enkel formel som et eksempel:

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

Alt dette sier at hvis Kolonne1 er mindre enn eller lik Kolonne2, viser du OK, ellers vises Ikke OK. Dette er en ganske vanlig grunnleggende formel for en beregnet kolonne, og den gjør en grunnleggende antagelse om listeelementet som inneholder disse kolonnene: Verdiene for Kolonne1 og Kolonne2 vil aldri kunne endres uten en Oppdatering-hendelse på listeelementet.

Det stemmer, beregnede kolonner beregnes bare på nytt når listen oppdateres (eller opprettes), siden de antar at informasjonen du beregner, finnes i selve elementet. Dette skaper et problem når du prøver å bruke noe som endres uavhengig av elementfeltene, for eksempel dagens dato.

Nå var jeg ikke i møtet hvor de bestemte seg for at dette er måten beregnede kolonner ville fungere på, men hvis jeg måtte gjøre en utdannet gjetning, ville jeg anta at de fungerer på denne måten for ytelse. Tenk deg om du hadde en liste over flere tusen elementer, som hver inneholdt en beregnet kolonne som trengte en "live"-oppdatering. Det ville bety at en mekanisme, kanskje en tidtakerjobb, måtte gjenta gjennom hvert element som inneholdt den beregnede kolonnen så ofte og oppdatere verdien. Dette kan være svært beskattende når det gjelder ytelse, fordi med større distribusjoner kan denne jobben hele tiden kjøre og endre ting. Det er bare min gjetning, men det gir ganske mye mening hvis du tenker på det.

Det finnes noen forslag til lignende løsninger som flyter rundt der ute som innebærer å lure SharePoint til å godta en I dag-verdi ved først å opprette en kolonne kalt I dag, og deretter legge den til i formelen, og deretter slette den. Alt dette er vel og bra, men husk hva jeg sa om når beregnede kolonner oppdateres. Denne verdien endres bare når elementet oppdateres, noe som betyr at verdiene snart blir feil, spesielt når det gjelder en dagsberegning.

Jeg har sett andre bruke smart JavaScript til å skrive verdiene til siden. Dette vil også fungere, men jeg er ganske mye kategorisk imot klientskript når det kan unngås.

Implementering:

Så hva skal jeg gjøre? Beregnede kolonner er utelukket for såkalte «flyktige» funksjoner som I dag. Det er mulig at vi kan utvikle en egendefinert kode for å ta vare på dette for oss som en beregnet kolonne, tidtakerjobb eller planlagt prosess for å komme sammen og oppdatere hvert eneste element som trenger denne beregningen. Det bringer oss tilbake til problemet med ytelse jeg nevnte i det siste avsnittet skjønt, og i tillegg er det en sprø løsning som ville være svært spesifikk for nettstedet / listen / kolonnen i spørsmålet. På toppen av disse to bekymringene, må du også gå finne en nerdete fyr, for eksempel meg selv, som vet hvordan å kode og overtale ham til å utvikle denne løsningen for deg. Men det finnes en enklere måte!

Hvis du har rettigheter til å opprette felt og redigere sider på nettstedet, og har litt kunnskap om XSLT og opprettelsesvisninger, kan du sette sammen en XSL-mal som kan inkluderes i en listevisning, og vil trofast beregne verdien hver gang siden blir forespurt. Dette scenarioet fjerner vår bekymring over ytelse, og krever ikke at egendefinert kode utvikles og distribueres via en løsning.

Perfekt. Så hvordan gjør vi det?

1. Opprett eller velg feltet som skal fungere som vår kilde. Det må være en datotype.

2. Opprett feltet vårt som skal fungere som en plassholder for verdien som beregnes.

3. Legg til begge disse feltene i en innholdstype, og legg til innholdstypen i en liste.

4. Opprett en visning av listen som inneholder både kilde- og plassholderkolonnene.

5. Last opp XSL-malen til stilbiblioteket.

6. Angi XSL-koblingsegenskapen for nettdelen for listevisning via brukergrensesnittet.

7. Vellykket!

La oss utforske et eksempel på brukstilfelle og gå gjennom implementeringen. Kunden vår ønsket en oversikt over hovedlisten som ville fortelle dem hvor lenge et bestemt listeelement hadde sittet på statusen. Denne listen inneholdt en egendefinert områdeinnholdstype avledet fra elementtypen og lagt til i listen. Det var allerede en hendelsesmottaker på plass som registrerer hver gang statusfeltet på listeelementet ble endret og lagret den datoen i en kolonne kalt «Datostatus endret». All denne ledningen er ikke nødvendig, og kan gjøres med ALLE datofelt (det skjer bare dette er implementeringen vår, men eksperimenter gjerne). Det minste minimumet du trenger, er kildedatofeltet og plassholderfeltet for å holde beregningen (mer om dette i neste avsnitt) lagt til i listen, selv om jeg foreslår at du bruker områdekolonner og områdeinnholdstyper i tilfelle du vil bruke denne løsningen på andre steder på nettstedet.

Så vi har vår kildedato som vi kan bruke i beregningen mot dagens dato. Nå kan vi opprette en egendefinert områdekolonne som skal brukes som en beholder for vår beregnede verdi. I dette tilfellet valgte jeg å bruke en beregnet kolonne fordi den ikke kan endres i skjemaene for nye eller redigere elementer, men kan velges for visning i visningene siden vi ikke vil at brukere skal skrive inn vilkårlige verdier i denne kolonnen. Det kan være forvirrende hvorfor det ikke vises i visningene osv.

Nå som vi har områdekolonnen vår, kan vi legge den til i innholdstypene våre som skal brukes i listen vår. Deretter må vi opprette vår visning som senere vil bli tilpasset med vår XSLT. Kontroller at du oppretter en standardvisning som inneholder kildedatokolonnen og den nye beregnede kolonnen som skal fungere som en plassholder for den beregnede verdien.

Vi har nå alt på plass som vi vil kreve for å støtte vår egendefinerte aldersfordelingsrapport. Alt som gjenstår er å opprette XSL-malen vår, laste den opp til nettstedets stilbibliotek og koble den til listevisningen vår. XSL-malen vi skal bruke, vil inneholde noen vanlige SharePoint-genererte markeringer for generering av visningen samt våre egne egendefinerte markeringer som brukes til å overstyre bestemte deler av dette og beregne ønsket verdi for oss.

Hvis du gir kreditt der kreditten forfaller, ble XSL-malene for å gjøre de faktiske beregningene jeg bruker for denne løsningen, nådig levert av "swirch" på MSDN-foraene:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Last ned XSL-stilarket (aging.zip) jeg har satt sammen, her:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

Hvis du åpner dette i favoritttekstredigeringsprogrammet ditt, ser du mange vanlige SharePoint XSL-markeringer for gjengivelse av visningene. Hvis du fortsetter å rulle ned til linje 357, ser du starten på de egendefinerte malene som jeg har lagt til i markeringen, den første som er DateDiff-malen etterfulgt av «calculate-julian-day» og «FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status». Dette er våre tre maler som vil gjøre og vise våre beregninger i våre visninger. Hvis du skal bruke andre feltnavn enn det som ble angitt tidligere i denne artikkelen, må du gå gjennom disse malene og erstatte eventuelle referanser med de andre navnene. Husk at for dette vil du bruke INTERN-navnet på feltet, ikke visningsnavnet.

Når du er fornøyd med at malen er klar, går du til stilbiblioteket og laster den opp under mappen XSL-stilark og kopierer koblingen til filen. Dette gjør at vi enkelt kan gjøre endringer i det senere, eller legge det til i ulike deler av nettstedet som vi ønsker.

Deretter går du til listen og velger visningen du opprettet tidligere i denne artikkelen. Klikk rediger side på Områdehandlinger-menyen.

Finn nettdelen for listevisning på siden, og åpne nettdelmenyen ved å klikke på den lille nedovervendte pilen øverst til høyre. Velg Rediger webdel på denne menyen.

Dette åpner nettdelmenyen på høyre side av nettleservinduet.

Klikk på + for inndelingen Diverse, og finn egenskapen XSL Link.

Lim inn koblingen til XSL-filen i stilbiblioteket som du kopierte ned tidligere (dette kan være en relativ eller absolutt kobling).

Klikk OK for å lagre endringene, og klikk deretter Stopp redigering på Side-båndet øverst på siden.

Hvis alt var riktig konfigurert, skal du nå se tall i kolonnen Dager med status.

Og til slutt, her er hvordan det ville se ut med noen testdata av ulike datoer:

Sammendrag:

Der er det: en pent formatert, robust og bedre måte å opprette en aldersfordelingsrapport i SharePoint på., komplett med en enkel implementering uten kode. Dette har ganske mange potensielle programmer bortsett fra det ene brukstilfellet vi utforsket her. Et annet vanlig scenario for denne typen rapport er å knytte den til en oppgaveliste, slik at du kan se hvor lenge den har vært siden en oppgave ble opprettet med et øyekast.

Kos deg!

--Justin

Justin Joyce, LANtek

Kommentarer

Mangler trinn 08.10.2012 kl.
03:51 ok jeg fulgte trinnene, men det må være noe som mangler - hvordan vil XSL vite hvilken dato som skal brukes, eller hvilket felt som skal legges til dagene siden? hater det når du går glipp av trinnene.

No-Code, avtalt!
30.08.2012 kl.
12:12 Jeg er enig - jeg tror ikke dette virkelig teller som "ingen kode".
Interessant, gjennom noen skrue av SharePoint, jeg har en fungerende beregnet kolonne ved hjelp av i dag ... ikke sikker på hvordan eller hvorfor fordi jeg ikke kan få det til å gjøre det igjen, men den er der fortsatt og arbeider.

Formel for beregnet kolonne for dager med status?
02.05.2012 kl.
07:39 Justin – Hva er formelen du brukte for den beregnede områdekolonnen for dager med status (plassholderkolonne)? Var det "=i dag"?

SharePoint 2007
02.12.2011 kl. 11:29
For øyeblikket har jeg ikke prøvd å bruke denne løsningen på SharePoint 2007, men jeg ser på den. Dessverre er det ingen XslLink-egenskap som vises på nettdelen gjennom brukergrensesnittet.

Flott innlegg
30.11.2011 kl. 09:53
Hei
Flott innlegg.
Jeg bruker SharePoint 2007.
Jeg har ikke en Misc-inndeling som nevnt ovenfor.
Har du trinn for en SP2007-konfigurasjon?
Takk.

Re: Ingen kodeløsning: Viser dagene etter at et SharePoint-listeelement sist ble endret
11.10.2011 kl. 08:24
Hei, Chris.
flott finn!
Jeg skal ta en titt på hva du postet forhåpentligvis senere i dag og se om jeg kan gjøre denne løsningen litt mer robust.
Jeg er glad du likte innlegget, og jeg er veldig glad for at du kunne finne en løsning på det europeiske datoformatet.
:) -Justin

Løsning for europeiske datoformater
11.10.2011 kl. 06:45
Hei igjen Justin,
Til orientering: Jeg fant en løsning på problemet jeg nevnte tidligere på denne siden.
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Europeiske datoformater
07.10.2011 kl. 03:59
Hei, Justin,
Dette er en veldig god løsning takk, og bare den slags ting jeg har brukt de siste to dagene på jakt etter! Men jeg har et problem med det, og jeg håpet du kunne hjelpe meg.
Jeg har endret koden litt for å beregne antall dager til noe skjer, i stedet for siden, ved å bytte variablene i den siste linjen i DateDiff-funksjonen.

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

Men jeg er bare i stand til å få det til å kakludere forskjellen riktig halvparten av tiden. Så for eksempel med denne datoen (format dd/MM/åååå);

12.30.2011

Den beregnes riktig, men med denne datoen (samme format)

10.12.2011

kl. Den beregner som om 10-des-2011 i stedet for 12-oktober-2011.
Jeg prøvde ganske enkelt å bytte posisjonene for dag- og månedsverdiene i «JulianStartDate»-variabelen, slik som dette.

<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 andre datoen, men det var da feil for første dato!
Jeg har også prøvd å endre FormatDateTime-kall for å bruke europeiske LCID-er og ulike endringer i den siste parameteren for FormatDateTime (f.eks. ddMMyyyyy, MMddyyyy) med de riktige justeringene av de delstrengposisjonsparameterne uten å lykkes.
Jeg vil sette stor pris på eventuelle råd du kan tilby.
Takk
Chris

Ingen kode
21.09.2011 kl.
04:27 Jeg tror ikke at XSL kvalifiserer som en "no-code" løsning, da det å forstå XSL-språket ikke er for alle - men det involverer ikke programmering. Dessuten: Fin løsning, takk!