Lösning utan kod: Visa dagarna sedan ett listobjekt senast ändrades

Översikt: Anpassade föråldringsrapporter utan kod

En av de ofta efterfrågade funktionella delarna på en SharePoint-webbplats är en föråldringsrapport för antingen uppgifter eller listobjekt. Med andra ord, hur många dagar/månader har det varit sedan listobjektet senast ändrades?

På ytan verkar detta vara en mycket enkel begäran. Vi har trots allt datum för objekt som skapas och ändras, vi har möjlighet att lagra anpassade datum när vissa ändringar av objekt sker via händelsemottagare. Vi har beräknade kolumner där vi kan ta med Excel-liknande formler för att arbeta med vår information. Detta verkar vara ett ganska rakt förslag. Vi väljer ett datumfält, skapar en beräknad kolumn och gör sedan en formel i stil med [Datumfält] – [Idag]. Ah, inte så snabbt dock! Som alla som har försökt med den här "enkla" uppgiften vet orsakar försök att använda något i stil med [Idag] i en beräknad kolumn problem. Prova att infoga [Idag] i formelrutan för den beräknade kolumnen och ge dig ett felmeddelande som ser ut ungefär så här:

Varför är det här? Tja, det har att göra med hur beräknade kolumner beräknas.

Låt oss ta en enkel formel som exempel:

= OM( [Kolumn1]<=[Kolumn2];"OK";"Inte OK")

Allt detta säger är att om Kolumn1 är mindre än eller lika med Kolumn2 visar du OK, annars visas Inte OK. Det här är en ganska vanlig grundläggande formel för en beräknad kolumn och den gör ett grundläggande antagande om listobjektet som innehåller dessa kolumner: Värdena för Kolumn1 och Kolumn2 kommer aldrig att kunna ändras utan en Uppdatering-händelse på listobjektet.

Just det, beräknade kolumner beräknas bara om när listan uppdateras (eller skapas) eftersom de förutsätter att informationen du beräknar finns i själva objektet. Det här skapar ett problem när du försöker använda något som ändras oberoende av objektets fält, till exempel dagens datum.

Nu var jag inte i mötet där de bestämde att det är så här beräknade kolumner skulle fungera, men om jag var tvungen att göra en utbildad gissning skulle jag anta att de fungerar på det här sättet för prestanda. Tänk om du hade en lista med flera tusen objekt, som var och en innehöll en beräknad kolumn som behövde en "live"-uppdatering. Det skulle innebära att någon mekanism, kanske ett tidsinställda jobb, skulle behöva iterera genom varje objekt som innehöll den beräknade kolumnen så ofta och uppdatera dess värde. Detta kan vara extremt beskattande när det gäller prestanda eftersom det här jobbet med större distributioner ständigt kan vara igång och förändra saker. Det är bara min gissning, men det är ganska vettigt om du tänker på det.

Det finns några förslag på liknande lösningar som flyter runt där ute som innebär att du lura SharePoint att acceptera ett Värde i dag genom att först skapa en kolumn med namnet I dag, sedan lägga till den i formeln och sedan ta bort den. Allt detta är bra, men kom ihåg vad jag sa om när beräknade kolumner uppdateras. Det här värdet ändras bara när objektet uppdateras, vilket innebär att värdena snart blir felaktiga, särskilt vid en dagsberäkning.

Jag har sett andra använda smarta JavaScript för att skriva värdena på sidan. Detta skulle fungera också, men jag är ganska mycket kategoriskt mot klientskript när det kan undvikas.

Genomförande:

Så vad ska jag göra? Beräknade kolumner är uteslutna för så kallade "flyktiga" funktioner som I dag. Det är möjligt att vi kan utveckla en anpassad kod för att ta hand om detta åt oss som en beräknad kolumn, tidsinställda jobb eller schemalagd process för att komma och uppdatera varje enskilt objekt som behöver den här beräkningen. Detta för oss tillbaka till det prestandaproblem som jag nämnde i det sista stycket, och dessutom är det en spröd lösning som skulle vara mycket specifik för webbplatsen / listan / kolumnen i fråga. Utöver dessa två farhågor skulle du också behöva hitta en nördig kille, som jag själv, som vet hur man kodar och övertalar honom att utveckla denna lösning för dig. Men det finns ett enklare sätt!

Om du har rätt att skapa fält och redigera sidor på webbplatsen, och har lite kunskap om XSLT och att skapa vyer, kan du sätta ihop en XSL-mall som kan ingå i en listvy och troget beräkna ditt värde varje gång sidan begärs. Det här scenariot tar bort vår oro över prestanda och kräver inte att anpassad kod utvecklas och distribueras via en lösning.

Perfekt! Så hur gör vi det?

1. Skapa eller välj det fält som ska fungera som vår källa. Det måste vara en datumtyp.

2. Skapa vårt fält som ska fungera som platshållare för det värde som beräknas.

3. Lägg till båda fälten i en innehållstyp och lägg till den innehållstypen i en lista.

4. Skapa en vy av listan som innehåller både käll- och platshållarkolumnerna.

5. Ladda upp XSL-mallen till formatbiblioteket.

6. Ange egenskapen XSL-länk för listvywebbdelen via användargränssnittet.

7. Klart!

Låt oss utforska ett exempel på användningsfall och gå igenom implementeringen. Vår kund ville ha en vy över sin huvudlista som skulle berätta för dem hur länge ett visst listobjekt hade suttit vid dess status. Listan innehöll en anpassad webbplatsinnehållstyp som härletts från objekttypen och lades till i listan. Det fanns redan en händelsemottagare som registrerar varje gång statusfältet i listobjektet ändrades och sparade datumet i en kolumn som heter "Datumstatus har ändrats". Alla dessa ledningar inte krävs, och kan göras med VALFRITT datumfält (det bara så händer detta är vår implementering men gärna experimentera). Det minsta du behöver är källdatumfältet och platshållarfältet för att hålla beräkningen (mer om detta i nästa stycke) som lagts till i listan, även om jag föreslår att du använder webbplatskolumner och webbplatsinnehållstyper om du vill återanvända den här lösningen på andra platser på din webbplats.

Så vi har vårt källdatum som vi kan använda i vår beräkning mot dagens datum. Nu kan vi skapa en anpassad webbplatskolumn som ska användas som en behållare för vårt beräknade värde. I det här fallet valde jag att använda en beräknad kolumn eftersom den inte kommer att kunna ändras i de nya eller redigera objektformulären, men kan väljas för visning i vyerna eftersom vi inte vill att användare ska ange godtyckliga värden i den här kolumnen. Det kan vara förvirrande varför det inte visas i vyerna, etc.

Nu när vi har vår webbplatskolumn kan vi lägga till den i våra innehållstyper som kommer att användas i vår lista. Därefter måste vi skapa vår vy som senare kommer att anpassas med vår XSLT. Se till att du skapar en standardvy som innehåller källdatumkolumnen och den nya beräknade kolumnen som fungerar som platshållare för det beräknade värdet.

Nu har vi allt på plats som vi kommer att behöva för att stödja vår anpassade åldranderapport. Allt som återstår är att skapa vår XSL-mall, ladda upp den till webbplatsens formatbibliotek och länka den till vår listvy. XSL-mallen vi kommer att använda kommer att innehålla några vanliga SharePoint-genererade markeringar för att generera vyn samt vår egen anpassade markering som används för att åsidosätta vissa delar av detta och beräkna önskat värde för oss.

Ger kredit där kredit är förfallen, XSL mallar för att göra de faktiska beräkningar jag använder för denna lösning var vänligt tillhandahålls av "swirch" på MSDN forum:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Ladda ned XSL-formatmallen (aging.zip) som jag har sammanställt som finns här:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&behörigheterÄndra=1&id=C262E8E2D59A86D9!104

När du öppnar det här i din favorittextredigerare ser du många vanliga SharePoint XSL-markeringar för återgivning av vyerna. Om du fortsätter att rulla ned till rad 357 kommer du att se början på de anpassade mallar som jag lagt till i markeringen, den första är mallen "DatumDiff" följt av "calculate-julian-day" och "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Det här är våra tre mallar som kommer att göra och visa våra beräkningar i våra vyer. Om du kommer att använda andra fältnamn än vad som angavs tidigare i den här artikeln måste du gå igenom de här mallarna och ersätta eventuella referenser till de andra namnen. Kom ihåg att för detta kommer du att vilja använda internt namn på fältet, inte visningsnamnet.

När du är nöjd med att mallen är klar går du till formatbiblioteket och laddar upp den under mappen XSL-formatmallar och kopierar sedan länken till filen. Det gör att vi enkelt kan göra ändringar i den senare, eller lägga till den i olika delar av webbplatsen som vi vill.

Gå sedan till listan och välj den vy du skapade tidigare i den här artikeln. Klicka på Redigera sida på menyn Webbplatsåtgärder.

Leta reda på listvywebbdelen på sidan och öppna menyn Webbdel genom att klicka på den lilla nedåtriktade pilen i det övre högra hörnet. Välj Redigera webbdel på den här menyn.

Då öppnas webbdelens meny till höger i webbläsarfönstret.

Klicka på + för avsnittet "Övrig" och leta reda på egenskapen "XSL-länk".

Klistra in länken till XSL-filen i formatbiblioteket som du kopierade tidigare (det kan vara en relativ eller absolut länk).

Klicka på OK för att spara ändringarna och klicka sedan på knappen "Sluta redigera" i menyfliksområdet "Sida" högst upp på sidan.

Om allt var korrekt konfigurerat bör du nu se talen i kolumnen "Dagar vid status".

Och slutligen, så här skulle det se ut med några testdata för olika datum:

Sammanfattning:

Där är det: ett snyggt formaterat, robust och bättre fungerande sätt att skapa en åldrande rapport i SharePoint., komplett med en enkel implementering utan kod. Detta har en hel del potentiella program bortsett från en användning fall vi utforskas här. Ett annat vanligt scenario för den här typen av rapport är att bifoga den i en uppgiftslista så att du kan se hur lång tid det har gått sedan en uppgift skapades i korthet.

Njut!

--Justin

Justin Joyce, LANtek

Kommentarer

Steg saknas
2012-10-08 03:51
ok jag följde stegen, men det måste finnas något saknas - hur kommer XSL veta vilket datum att använda, eller vilket fält att lägga till dagarna sedan i? hatar det när steg missas.

Ingen kod, instämmd!
2012-08-30 12:12
Jag håller med - Jag tror inte att detta verkligen räknas som "ingen kod".
Intressant nog, genom några skruvade SharePoint, jag har en fungerande beräknad kolumn med hjälp av Idag ... inte säker på hur eller varför eftersom jag inte kan få det att göra det igen, men den är fortfarande där och arbetar.

Formel för beräknad kolumn av typen "Dagar vid status"?
2012-05-02 07:39
Justin – Vilken formel använde du för den beräknade webbplatskolumnen "Dagar vid status" (platshållarkolumn)? Var det "=idag"?

SharePoint 2007
2011-12-02 11:29
För närvarande har jag inte försökt tillämpa den här lösningen på SharePoint 2007, men jag tittar in på den. Tyvärr finns det ingen XslLink-egenskap som visas på webbdelen via användargränssnittet.

Great Post
2011-11-30 09:53
Hej
Bra inlägg.
Jag använder SharePoint 2007.
Jag har inte ett Misc avsnitt som anges ovan.
Har du anvisningar för en SP2007-konfiguration?
Tack.

Re: Lösning utan kod: Visa dagarna sedan ett SharePoint-listobjekt senast ändrades
2011-10-11 08:24
Hej Chris.
bra att hitta!
Jag ska ta en titt på vad du postat förhoppningsvis senare i dag och se om jag kan göra denna lösning lite mer robust.
Jag är glad att du gillade inlägget, och jag är mycket glad att du kunde hitta en lösning på det europeiska datumformatet.
:) -Justin

Lösning för europeiska datumformat
2011-10-11 06:45
Hej Justin,
Obs! Jag hittade en lösning på problemet jag nämnde tidigare på den här sidan;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Europeiska datumformat
2011-10-07 03:59
Hej Justin,
Detta är en riktigt bra lösning tack, och precis den typ av sak jag har tillbringat de senaste två dagarna letar efter! Men jag har lite problem med det och jag hoppades att du kunde hjälpa mig.
Jag har ändrat koden något för att beräkna antalet dagar tills något händer, snarare än sedan dess, genom att växla variablerna i den sista raden i funktionen "DatumDiff";

<xsl:värde för select="$JulianToday – $JulianStartDate"></xsl:värde för>

Men jag kan bara få det att caclulate skillnaden korrekt halva tiden. Så till exempel med detta datum (format dd / MM / åååå);

2011-03-12

Den beräknas korrekt, men med det här datumet (samma format)

12/10/2011

Den beräknar som om 10-dec-2011 i stället för 12-okt-2011.
Jag försökte helt enkelt byta positioner för dag- och månadsvärdena i variabeln "JulianStartDate", så här;

<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)"/>

Och detta korrigerade problemet med det andra datumet, men det var då felaktigt för det första datumet!
Jag har också försökt ändra FormatDateTime-anropen för att använda europeiska LCID:er och olika ändringar av den sista parametern i FormatDateTime (t.ex. ddMMyyyy, MMddyyyy) med lämpliga justeringar av understrängens positionella parametrar utan framgång.
Jag skulle uppskatta alla råd du kan ge.
Tack
Chris

Ingen kod
2011-09-21 04:27
Jag tror inte att XSL kvalificerar sig som en "ingen kod"-lösning, eftersom förståelse av XSL-språket inte är för alla - men det innebär inte programmering. Förutom att: Nice lösning, tack!