Office
Aanmelden
Oplossing zonder code: Weergeven van de dagen sinds een SharePoint-lijstitem voor het laatst is gewijzigd

Oplossing zonder code: Weergeven van de dagen sinds een SharePoint-lijstitem voor het laatst is gewijzigd

Opmerking:  We willen u graag zo snel mogelijk de meest recente Help-inhoud in uw eigen taal bieden. Deze pagina is automatisch vertaald en kan grammaticale fouten of onnauwkeurigheden bevatten. Wij hopen dat deze inhoud nuttig voor u is. Kunt u ons onder aan deze pagina laten weten of de informatie nuttig voor u was? Hier is het Engelstalige artikel ter referentie.

20-9-2011 15.01 uur

door Justin Joyce, LANtek

Opmerking:  Dit artikel maakt deel uit van een verzameling berichten van de vier jaar lopende blog Get the Point voor eindgebruikers van SharePoint.

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?

Dit lijkt een vrij eenvoudig verzoek. We hebben tenslotte al de datums waarop items zijn gemaakt en gewijzigd, en we kunnen aangepaste datums opslaan wanneer bepaalde wijzigingen worden aangebracht in items via ontvangers van gebeurtenissen. We hebben berekende kolommen waarin we Excel-achtige formules kunnen gebruiken om met onze informatie te werken. Dat lijkt dus allemaal niet zo ingewikkeld. We nemen een datumveld, maken een berekende kolom en schrijven een formule, zoiets als [DatumVeld] - [Vandaag]. Maar wacht even, niet zo snel! Iedereen die deze ‘eenvoudige’ klus wel eens heeft geprobeerd, weet dat het gebruik van [Vandaag] in een berekende kolom problemen oplevert. Probeer [Vandaag] maar eens in te voegen in het formulevak van de berekende kolom. Dat geeft een foutmelding zoals deze:

Foutbericht

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

We nemen een eenvoudige formule als voorbeeld:

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

Deze formule stelt dat wanneer de waarde in Kolom1 lager is dan of gelijk is aan de waarde in Kolom2, er “OK” wordt weergegeven. Zo niet, dan wordt “Niet OK” weergegeven. Dit is een vrij normale en basale formule voor een berekende kolom, gebaseerd op een aanname over het lijstitem dat deze kolommen bevat: De waarden voor Kolom1 en Kolom2 kunnen nooit wijzigen zonder een gebeurtenis Bijwerken op het lijstitem.

Inderdaad, berekende kolommen worden alleen opnieuw berekend wanneer de lijst wordt bijgewerkt (of gemaakt), omdat wordt aangenomen dat de informatie die u berekent, zich in het item zelf bevindt. Dit zorgt voor problemen als u probeert iets te gebruiken dat verandert en niet afhankelijk is van de velden van het item - bijvoorbeeld de actuele datum.

Ik was er niet bij toen werd besloten dat berekende kolommen op deze manier zouden werken, maar ik vermoed dat deze functie zo werkt omwille van de prestaties. Stel dat u een lijst hebt met duizenden items die allemaal een berekende kolom bevatten die ‘live’ moet worden bijgewerkt. 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. Dit lijkt mij een logische reden voor de manier waarop het nu werkt.

Er zijn vergelijkbare oplossingen voorgesteld, waarmee wordt geprobeerd SharePoint de waarde Vandaag wel te laten accepteren door middel een truc: maak een kolom genaamd Vandaag, voeg die toe aan de formule en verwijder vervolgens de kolom. Dat is allemaal leuk en aardig, maar denk aan wat er gebeurt wanneer de berekende kolommen worden bijgewerkt. De waarde wijzigt alleen wanneer het item wordt bijgewerkt. Dit betekent dat de waarden al snel niet meer zullen kloppen, zeker als het om een datumberekening gaat.

Er zijn mensen die een vernuftig stukje 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 moeten we doen? Berekende kolommen kunnen dus niet worden gebruikt met zogenaamde 'vluchtige' functies zoals Vandaag. We zouden waarschijnlijk wat aangepaste code kunnen gebruiken om het op te lossen en een berekende kolom, timeropdracht of gepland proces gebruiken om elk afzonderlijk item waarvoor de berekening nodig is, bij te werken. Maar dan zijn we weer terug bij de prestatieproblemen uit de vorige alinea. Bovendien zou dit een zeer fragiele oplossing zijn, puur en alleen voor de betreffende site, lijst of kolom. Ook moet u dan op zoek naar een nerd (zoals ik) die code kan schrijven, en hem overhalen deze oplossing voor u te ontwikkelen. Het kan makkelijker!

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. In dit scenario hoeven we ons geen zorgen te maken over de prestaties en hoeft er geen aangepaste code te worden geschreven en geïmplementeerd via een oplossing.

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-koppeling' in voor het webonderdeel Lijstweergave via de gebruikersinterface.

  7. En voilà!

We nemen een use case als voorbeeld en nemen de implementatie door. Onze klant wilde een weergave van hun hoofdlijst, waarin werd getoond hoe lang een bepaald lijstitem al dezelfde status had. De lijst bevatte een aangepast site-inhoudstype afgeleid van het itemtype en toegevoegd aan de lijst. Er was al een ontvanger van gebeurtenissen aanwezig, die vastlegde wanneer het statusveld van het lijstitem wijzigde en die datum opsloeg in een kolom genaamd 'Datum status gewijzigd'. Dit is allemaal niet noodzakelijk, en het kan worden gedaan met ELK datumveld (dit is zoals wij het hebben gedaan, dus experimenteer er gerust op los). De minimale vereiste is dat u een brondatumveld en een tijdelijk veld voor de berekening (meer hierover in de volgende alinea) hebt toegevoegd aan de lijst. Het is overigens handig om sitekolommen en site-inhoudstypen te gebruiken voor het geval u deze oplossing elders op uw site wilt hergebruiken.

We beschikken dus over een brondatum die we kunnen gebruiken voor de berekening met de huidige datum. Nu maken we een aangepaste sitekolom als een container voor de berekende waarde. In dit geval heb ik gekozen voor een berekende kolom, omdat deze niet kan worden gewijzigd in de formulieren voor nieuwe items en voor het bewerken van items, maar wel kan worden geselecteerd voor weergave. We willen natuurlijk niet dat gebruikers een willekeurige waarde in deze kolom kunnen invoegen. Dat kan leiden tot verwarring als die niet in de weergave worden getoond, 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. We hoeven alleen nog de XSL-sjabloon te maken, te uploaden naar de stijlbibliotheek van de site en te koppelen aan de 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.

Geeft punten waar krediet is voldaan, de XSL-sjablonen voor het uitvoeren van de werkelijke berekeningen die ik gebruik voor deze oplossing zijn vriendelijk verstrekt door 'swirch' op de forums MSDN:
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 het in uw favoriete teksteditor opent, ziet u eerst flink wat SharePoint XSL-opmaak voor de weergaven. Vanaf regel 357 ziet u de aangepaste sjablonen die ik aan de opmaak heb toegevoegd, met als eerste de sjabloon ‘DateDiff’ en daarna ‘calculate-julian-day’ en “FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status”. Dit zijn de drie sjablonen die de berekeningen maken en weergeven in onze weergaven. Als u andere veldnamen gebruikt dan de namen die ik eerder in dit artikel noemde, neemt u de sjablonen door en vervangt u de betreffende namen. Denk eraan dat u de INTERNE naam van het veld moet gebruiken, niet de weergavenaam.

Wanneer u tevreden bent met uw sjabloon, uploadt u het naar de stijlbibliotheek in 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’.

Opdracht Pagina bewerken in menu Siteacties

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

Opdracht Webonderdeel bewerken in het menu Webonderdeel

Hiermee opent u het menu van het webonderdeel aan de rechterkant van het browservenster.

Menu Webonderdeel

Klik op de + voor de sectie 'Overige' en zoek de eigenschap 'XSL-koppeling'.

De eigenschap XSL-koppeling in het menu Webonderdeel

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

XSL-bestandskoppeling geplakt in

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

Knop Bewerken stoppen op tabblad Pagina

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

Kolom Dagen op statuskolom met een getal

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

Naar ouderdom gerangschikt rapport met testgegevens

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. Zo zou u dit type rapport bijvoorbeeld aan een takenlijst kunnen toevoegen, zodat u in een oogopslag kunt zien hoe lang het geleden is dat een taak is gemaakt.

Veel plezier ermee!

--Justin

Justin Joyce, LANtek

Reacties

Ontbrekende stappen
10-8-2012 3:51 uur
OK ik heb de stappen gevolgd, maar er moet iets missen - hoe weet de XSL welke datum moet worden gebruikt, of in welk veld het aantal verstreken dagen moet worden ingevoegd? Ik haat het als stappen ontbreken.

Zonder code inderdaad!
30-8-2012 12:12 uur
Inderdaad, dit bevat zeker geen code.
Wat fascinerend is, is dat door een of andere fout in SharePoint ik een werkende berekende kolom heb met Vandaag… Ik weet niet hoe of wat, en ik krijg het niet meer voor elkaar, maar deze kolom is er en doet het.

Formule voor ‘Dagen op status' berekende kolom?
2-5-2012 7:39 uur
Justin, welke formule heb je gebruikt voor je berekende sitekolom 'Dagen op status' (de tijdelijke kolom)? Is dat '= vandaag'?

SharePoint 2007
2-12-2011 11:29 uur
Ik heb dit nog niet geprobeerd met SharePoint 2007, maar wil dat zeker doen. Helaas kan ik geen eigenschap XslLink vinden in het webonderdeel via de gebruikersinterface.

Geweldige post
30-11-2011 9:53 uur
Hallo,
geweldige post.
Ik gebruik SharePoint 2007.
Ik heb geen sectie Diversen zoals hierboven vermeld.
Heb je ook stappen voor een SP2007-configuratie?
Bedankt.

Re: Oplossing zonder code: Weergeven van de dagen sinds een SharePoint-lijstitem het laatst is gewijzigd
11-10-2011 8:24 uur
Hoi Chris,
goed gevonden!
Ik probeer later vandaag te kijken naar wat je hebt gepost om te zien of ik de oplossing nog kan verbeteren.
Fijn om te lezen dat je wat aan mijn post hebt en dat je een oplossing hebt gevonden voor de Europese datumnotatie. :)
-Justin

Oplossing voor het Europees datum indelingen voor
11-10-2011 6:45 tot
High opnieuw Jeroen,
ter informatie, gevonden ik een oplossing voor het probleem dat ik eerder is vermeld op deze pagina.
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Europese datumnotatie
7-10-2011 3:59 uur
Hoi Justin,
Bedankt, dit is een zeer goede oplossing en precies 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 de code enigszins aangepast om het aantal dagen te berekenen totdat er iets gebeurt, in plaats van sinds er iets is gebeurd, door de variabelen in de laatste regel van de functie 'DateDiff' om te draaien;

< xsl: Value-of select = '$JulianToday - $JulianStartDate' >< / xsl: Value-van >

maar het verschil wordt maar in ongeveer de helft van de gevallen correct berekend. Met deze datum (notatie dd/MM/jjjj);

30/12/2011

is de berekening goed, maar met deze datum (dezelfde notatie)

12/10/2011

wordt de berekening uitgevoerd alsof er 10 december 2011 staat, in plaats van 12 oktober 2011.
Ik heb geprobeerd de dag en maand om te draaien in de variabele 'JulianStartDate', op deze manier;

<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 loste het probleem met de tweede datum op, maar toen ging het met de eerste datum fout!
Ik heb ook geprobeerd om de FormatDateTime-aanroepen Europese LCID's te laten gebruiken en heb verschillende variaties geprobeerd van de laatste parameter van FormatDateTime (bijvoorbeeld ddMMyyyy, MMddyyyy) met de juiste aanpassingen aan de positionele parameters in de substring, maar zonder succes.
Als je advies hebt, hoor ik het heel graag.
Bedankt,
Chris

Zonder code
21-9-2011 4:27 uur
Ik vind niet dat XSL een oplossing ‘zonder code’ is, want lang niet iedereen begrijpt de XSL-taal. Maar je hoeft inderdaad niet te programmeren. Afgezien daarvan: Handige oplossing, bedankt!

Uw Office-vaardigheden uitbreiden
Training verkennen
Als eerste nieuwe functies krijgen
Deelnemen aan Office Insiders

Was deze informatie nuttig?

Bedankt voor uw feedback.

Hartelijk dank voor uw feedback! Het lijkt ons een goed idee om u in contact te brengen met een van onze Office-ondersteuningsagents.

×