Oplossing zonder code: de dagen weergeven sinds een lijstitem voor het laatst is gewijzigd

Overzicht: Aangepaste, naar ouderdom gerangschikte rapporten zonder code

Een van de meest gevraagde functionele onderdelen van een SharePoint-site is een naar ouderdom gerangschikt rapport voor taken of lijstitems. Met andere woorden, hoeveel dagen of maanden is het geleden dat het lijstitem voor het laatst is gewijzigd?

Op het eerste gezicht lijkt dit een zeer eenvoudige aanvraag te zijn. We hebben immers datums voor items die worden gemaakt en gewijzigd, we hebben de mogelijkheid om aangepaste datums op te slaan wanneer bepaalde wijzigingen in items plaatsvinden via gebeurtenisontvangers. We hebben berekende kolommen waarin we Excel-achtige formules kunnen opnemen om met onze informatie te werken. Dit lijkt een vrij eenvoudige stelling. We kiezen een datumveld, maken een berekende kolom en voeren vervolgens een formule uit zoals [DateField] – [Vandaag]. Ah, niet zo snel hoor! Zoals iedereen die deze 'eenvoudige' taak heeft geprobeerd, weet, veroorzaakt het gebruik van iets als [Vandaag] in een berekende kolom problemen. Als u [Vandaag] probeert in te voegen in het formulevak van de berekende kolom, krijgt u een foutbericht dat er ongeveer als volgt uitziet:

Waarom gebeurt dit? Dit heeft te maken met de manier waarop berekende kolommen worden berekend.

Laten we een eenvoudige formule als voorbeeld nemen:

= ALS( [Kolom1]<=[Kolom2], "OK", "Niet OK")

Dit betekent alleen dat als Kolom1 kleiner is dan of gelijk is aan Kolom2, ok wordt weergegeven, anders niet OK. Dit is een vrij typische basisformule voor een berekende kolom en maakt een basisaanname over het lijstitem dat deze kolommen bevat: De waarden voor Kolom1 en Kolom2 kunnen nooit worden gewijzigd zonder een update-gebeurtenis voor het lijstitem.

Berekende kolommen worden alleen opnieuw berekend wanneer de lijst wordt bijgewerkt (of gemaakt), omdat ze ervan uitgaan dat de gegevens die u berekent, zich in het item zelf bevinden. Dit veroorzaakt een probleem wanneer u iets probeert te gebruiken dat onafhankelijk van de velden van het item verandert, zoals de datum van vandaag.

Nu was ik niet in de vergadering waar ze besloten dat dit de manier is waarop berekende kolommen zouden werken, maar als ik een gefundeerde schatting moest maken, zou ik ervan uitgaan dat ze op deze manier functioneren voor prestaties. Stel dat u een lijst had met enkele duizenden items, die elk een berekende kolom bevatten die een 'live' update nodig had. Dit zou betekenen dat een bepaald mechanisme, zoals een timeropdracht, om de zoveel tijd alle items met die berekende kolom moet verwerken en bijwerken. Dit kan een enorme aanslag zijn op de prestaties, want in grotere implementaties kan dit ertoe leiden dat de opdracht doorlopend wordt uitgevoerd en er steeds dingen wijzigen. Dat is mijn schatting, maar het is nogal logisch als je erover nadenkt.

Er zijn enkele suggesties voor vergelijkbare oplossingen die er zijn, waarbij SharePoint wordt misleid om een Vandaag-waarde te accepteren door eerst een kolom met de naam Vandaag te maken, deze vervolgens toe te voegen aan uw formule en deze vervolgens te verwijderen. Deze zijn allemaal goed en goed, maar onthoud wat ik heb gezegd over wanneer berekende kolommen worden bijgewerkt. Deze waarde verandert alleen wanneer het item wordt bijgewerkt, wat betekent dat uw waarden binnenkort onjuist zijn, met name in het geval van een dagberekening.

Ik heb anderen gezien die slim JavaScript gebruiken om de waarden naar de pagina te schrijven. Dat werkt, maar ik ben absoluut tegen het gebruik van clientscripts zolang dat niet nodig is.

Implementatie:

Dus wat te doen? Berekende kolommen zijn niet aan de orde voor zogenaamde 'vluchtige' functies zoals Vandaag. Het is mogelijk dat we aangepaste code kunnen ontwikkelen om dit voor ons te doen, zoals een berekende kolom, timeropdracht of gepland proces om elk item bij te werken waarvoor deze berekening moet worden gemaakt. Dat brengt ons echter terug bij het prestatieprobleem dat ik in de vorige alinea heb genoemd, en bovendien is het een broze oplossing die zeer specifiek zou zijn voor de betreffende site/lijst/kolom. Naast deze twee zorgen, zou je ook een nerdy moeten zoeken, zoals ik, die weet hoe hij moet codeeren en hem kan overtuigen om deze oplossing voor jou te ontwikkelen. Maar er is een eenvoudigere manier!

Als u de rechten hebt om velden te maken en pagina’s te bewerken op uw site en iets weet van XSLT en het maken van weergaven, kunt u zelf een XSL-sjabloon in elkaar zetten die kan worden opgenomen in een lijstweergave, en die uw waarde netjes berekent telkens wanneer de pagina wordt opgevraagd. Dit scenario neemt onze zorgen over prestaties weg en vereist geen aangepaste code die via een oplossing wordt ontwikkeld en geïmplementeerd.

Perfect. Dus hoe doen we dat?

1. Maak of selecteer het veld dat fungeert als de bron. Het moet een datumtype zijn.

2. Maak een veld dat functioneert als tijdelijke aanduiding voor de waarde die wordt berekend.

3. Voeg beide velden toe aan een inhoudstype en voeg het inhoudstype toe aan een lijst.

4. Maak een weergave van de lijst die zowel de bronkolom en de tijdelijke kolom bevat.

5. Upload de XSL-sjabloon naar de stijlbibliotheek.

6. Stel de eigenschap 'XSL Link' in voor het webonderdeel Lijstweergave via de gebruikersinterface.

7. Gelukt!

Laten we een voorbeeld van een use-case bekijken en de implementatie doorlopen. Onze klant wilde een weergave van hun hoofdlijst waarin wordt aangegeven hoe lang een bepaald lijstitem op de status heeft gestaan. Deze lijst bevat een aangepast site-inhoudstype dat is afgeleid van het itemtype en is toegevoegd aan de lijst. Er was al een gebeurtenisontvanger die elke keer vastlegt dat het statusveld van het lijstitem werd gewijzigd en die datum opgeslagen in een kolom met de naam 'Status gewijzigd'. Al deze bedrading is niet vereist en kan worden gedaan met ELK datumveld (het is gewoon zo dat dit onze implementatie is, maar voel je vrij om te experimenteren). Het absolute minimum dat u nodig hebt, is het brondatumveld en het veld met tijdelijke aanduidingen om uw berekening (meer hierover in de volgende alinea) toe te voegen aan uw lijst, hoewel ik u voorstel sitekolommen en site-inhoudstypen te gebruiken voor het geval u deze oplossing op andere plaatsen op uw site opnieuw wilt gebruiken.

We hebben dus onze brondatum die we kunnen gebruiken in onze berekening ten opzichte van de datum van vandaag. Nu kunnen we een aangepaste sitekolom maken om te gebruiken als een container voor de berekende waarde. In dit geval heb ik ervoor gekozen om een berekende kolom te gebruiken omdat deze niet kan worden gewijzigd in de nieuwe of bewerkitemformulieren, maar kan worden geselecteerd voor weergave in de weergaven, omdat we niet willen dat gebruikers willekeurige waarden invoeren in deze kolom. Het kan verwarrend zijn waarom deze niet wordt weergegeven in de weergaven, enzovoort.

Nu we een sitekolom hebben, kunnen we die toevoegen aan de inhoudstypen die we in onze lijst gebruiken. Vervolgens moeten we de weergave maken die we later aanpassen met de XSLT. Maak een standaardweergave met de brondatumkolom en de nieuwe berekende kolom, die functioneert als tijdelijke plaatsaanduiding voor de berekende waarde.

Alles staat nu klaar voor het maken van ons aangepaste, naar ouderdom gerangschikte rapport. U hoeft alleen nog maar onze XSL-sjabloon te maken, deze te uploaden naar de stijlbibliotheek van de site en deze te koppelen aan onze lijstweergave. De XSL-sjabloon die we gebruiken, bevat de gebruikelijke door SharePoint gegenereerde opmaak voor het genereren van de weergave, en wat van onze eigen opmaak voor het overschrijven van bepaalde delen daarvan en het berekenen van de gewenste waarde.

De XSL-sjablonen voor het uitvoeren van de werkelijke berekeningen die ik voor deze oplossing gebruik, werden vriendelijk verstrekt door 'swirch' op de MSDN-forums:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

U kunt mijn XSL-opmaakmodel (aging.zip) hier downloaden:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9! 104

Als u dit opent in uw favoriete teksteditor, ziet u veel normale SharePoint XSL-markeringen voor het weergeven van de weergaven. Als u omlaag blijft schuiven naar regel 357, ziet u het begin van de aangepaste sjablonen die ik aan de opmaak heb toegevoegd. De eerste is de sjabloon 'DateDiff', gevolgd door 'calculate-julian-day' en 'FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status'. Dit zijn onze drie sjablonen die onze berekeningen maken en weergeven in onze weergaven. Als u andere veldnamen gaat gebruiken dan eerder in dit artikel is opgegeven, moet u deze sjablonen doorlopen en eventuele verwijzingen naar de andere namen vervangen. Vergeet niet dat u hiervoor de INTERNE naam van het veld wilt gebruiken, niet de weergavenaam.

Zodra u er zeker van bent dat de sjabloon klaar is om te worden gebruikt, gaat u naar uw stijlbibliotheek en uploadt u deze onder de map XSL-opmaakmodellen en kopieert u de koppeling naar het bestand. Hierdoor kunnen we later eenvoudig wijzigingen aanbrengen of de sjabloon in andere delen van de site hergebruiken.

Ga nu naar uw lijst en selecteer de weergave die u eerder in dit artikel hebt gemaakt. Klik in het menu Siteacties op Pagina bewerken.

Zoek het webonderdeel Lijstweergave op de pagina en open het menu Webonderdeel door te klikken op de kleine pijl-omlaag rechtsboven. Selecteer in dit menu 'Webonderdeel bewerken'.

Hiermee wordt het menu van het webonderdeel aan de rechterkant van het browservenster geopend.

Klik op de + voor de sectie 'Diversen' en zoek de eigenschap 'XSL Link'.

Plak de koppeling naar het XSL-bestand in uw stijlbibliotheek die u eerder hebt gekopieerd (dit kan een relatieve of absolute koppeling zijn).

Klik op OK om uw wijzigingen op te slaan en klik vervolgens op de knop Stoppen met bewerken op het lint Pagina bovenaan de pagina.

Als alles correct is geconfigureerd, ziet u nu getallen in de kolom 'Dagen bij status'.

Uiteindelijk moet het er als volgt uitzien met wat testgegevens van verschillende datums:

Samenvatting:

Alstublieft, een mooi opgemaakte, krachtige en goed presterende manier om een naar ouderdom gerangschikt rapport te maken in SharePoint, compleet met een eenvoudige implementatie zonder code. Dit kan op vele manieren worden toegepast naast de beschreven use case. Een ander veelvoorkomend scenario voor dit type rapport is het koppelen aan een takenlijst, zodat u in één oogopslag kunt zien hoe lang het geleden is dat een taak is gemaakt.

Veel plezier ermee!

--Justin

Justin Joyce, LANtek

Reacties

Stappen ontbreken
8-10-2012 3:51
Ok Ik heb de stappen gevolgd, maar er moet iets ontbreken. Hoe weet de XSL welke datum moet worden gebruikt of welk veld de dagen daarna moet worden toegevoegd? Ik haat het als stappen ontbreken.

No-Code, overeengekomen!
30-8-2012 12:12 PM
Ik ben het ermee eens - ik denk niet dat dit echt telt als "geen code".
Interessant is dat ik door wat verkijzeling van SharePoint een werkende berekende kolom heb met behulp van Vandaag... ik weet niet zeker hoe of waarom, want ik kan het niet opnieuw laten doen, maar de ene is er nog en werkt.

Formule voor berekende kolom 'Dagen bij status'?
02-5-2012 07:39
Justin - Wat is de formule die u hebt gebruikt voor de berekende sitekolom 'Days At Status' (kolom met tijdelijke aanduidingen)? Is dat '= vandaag'?

SharePoint 2007
2-12-2011 11:29
Op dit moment heb ik niet geprobeerd deze oplossing toe te passen op SharePoint 2007, maar ik zoek er wel naar. Helaas kan ik geen eigenschap XslLink vinden in het webonderdeel via de gebruikersinterface.

Geweldige post
30-11-2011 9:53
Hallo
Geweldige post.
Ik gebruik SharePoint 2007.
Ik heb geen Misc-sectie zoals hierboven vermeld.
Hebt u stappen voor een SP2007-configuratie?
Bedankt.

Re: Oplossing zonder code: de dagen weergeven sinds een SharePoint-lijstitem voor het laatst is gewijzigd
11-10-2011 8:24
Hallo Chris.
geweldige vinding!
Ik ga kijken wat je later vandaag hebt gepost en kijk of ik deze oplossing een beetje robuuster kan maken.
Ik ben blij dat je het bericht leuk vond, en ik ben erg blij dat je een oplossing kon vinden voor de Europese datumnotatie.
:) -Justin

Oplossing voor Europese datumnotaties
11-10-2011 6:45
Hoi nogmaals Justin,
Ter informatie, ik heb een oplossing gevonden voor het probleem dat ik eerder op deze pagina heb genoemd;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Europese datumnotaties
7-10-2011 3:59
Hallo Justin,
Dit is echt een goede oplossing bedankt, en precies het soort waar ik de afgelopen twee dagen naar heb gezocht! Ik heb er alleen wel een probleem mee, en ik hoop dat je me kunt helpen.
Ik heb uw code enigszins gewijzigd om het aantal dagen te berekenen totdat er iets gebeurt, in plaats van sindsdien, door de variabelen in de laatste regel van de functie 'DateDiff' te wijzigen;

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

Maar ik kan het verschil maar de helft van de tijd correct laten caclueren. Dus bijvoorbeeld met deze datum (notatie dd/MM/jjjj);

12-30-2011

Deze wordt correct berekend, maar met deze datum (dezelfde notatie)

10-12-2011

Het wordt berekend als 10-dec-2011 in plaats van 12-okt-2011.
Ik heb geprobeerd de posities van de dag- en maandwaarden in de variabele "JulianStartDate" te wijzigen, zoals deze;

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

En dit heeft het probleem met de tweede datum opgelost, maar het was toen onjuist voor de eerste date!
Ik heb ook geprobeerd de FormatDateTime-aanroepen te wijzigen om Europese LCID's te gebruiken en verschillende wijzigingen in de laatste parameter van FormatDateTime (bijvoorbeeld ddMMyyyy, MMddyyyyy) met de juiste aanpassingen aan de positieparameters van de subtekenreeks zonder succes.
Ik zou het zeer op prijs stellen als je advies kunt geven.
Bedankt
Chris

Geen code
21-09-2011 4:27
Ik denk niet dat XSL kwalificeert als een 'no-code'-oplossing, omdat het begrijpen van de XSL-taal niet voor iedereen is, maar het vereist geen programmering. Daarnaast: Leuke oplossing, bedankt!