Kód nélküli megoldás: A listaelem utolsó módosítása óta eltelt napok megjelenítése

írta: Justin Joyce, LANtek

Áttekintés: Egyéni elévülési jelentések kód nélkül

A SharePoint-webhelyek egyik gyakran kért funkcionális eleme a feladatok és a listaelemek elévülési jelentése. Más szóval, hány nap/hónap telt el a listaelem utolsó módosítása óta?

A felszínen ez egy nagyon egyszerű kérésnek tűnik. Végül is vannak dátumaink az elemek létrehozására és módosítására, és képesek vagyunk egyéni dátumokat tárolni, amikor az elemek bizonyos módosításai eseményérzékelőkön keresztül történnek. Vannak olyan számított oszlopaink, amelyekbe Excel-szerű képleteket vehetünk fel az információinkkal való munkához. Ez elég egyértelmű javaslatnak tűnik. Kiválasztunk egy dátummezőt, létrehozunk egy számított oszlopot, majd létrehozunk egy ehhez hasonló képletet: [DateField] – [Today]. Ó, de nem olyan gyorsan! Aki már próbálkozott ezzel az "egyszerű" feladattal, tudja, hogy a [Ma] kifejezéshez hasonló kifejezések használata egy számított oszlopban problémákat okozhat. Ha megpróbálja beszúrni a [Ma] szót a számított oszlop képletmezőjébe, az alábbihoz hasonló hibaüzenetet fog kapni:

Miért van ez? Ez a számított oszlopok számításának módjában rejlik.

Vegyünk példaként egy egyszerű képletet:

= HA( [Oszlop1]<=[Oszlop2], "OK", "Nem OK")

Ez mindössze annyit jelent, hogy ha Oszlop1 kisebb vagy egyenlő, mint Oszlop2, akkor az OK legyen látható, ellenkező esetben pedig a Nem OK érték jelenjen meg. Ez egy meglehetősen tipikus egyszerű képlet a számított oszlopokhoz, és alapvető feltételezést végez az oszlopokat tartalmazó listaelemről: Az Oszlop1 és Oszlop2 értékei soha nem módosulhatnak a listaelemen végrehajtott Frissítés esemény nélkül.

Így van, a számított oszlopok újraszámítása csak a lista frissítésekor (vagy létrehozásakor) történik, mivel feltételezik, hogy a kiszámításhoz szükséges információt maga az elem tartalmazza. Ez problémát okoz, ha olyan elemet próbál meg használni, amely a tétel mezőitől függetlenül változik (például a mai dátumot).

Most már nem voltam azon a megbeszélésen, ahol úgy döntöttek, hogy a számított oszlopok így fognak működni, de ha megalapozott tippet kellene végeznem, feltételezném, hogy így működnek a teljesítmény szempontjából. Képzelje el, hogy van egy több ezer elemet tartalmazó listája, amelyek mindegyike tartalmaz egy számított oszlopot, amely "élő" frissítést igényel. Ez azt jelentené, hogy valamilyen mechanizmusnak, például egy időzítőfeladatnak, időnként végig kellene iterálnia minden egyes elemet, amely ezt a számított oszlopot tartalmazza, és frissítenie kellene az értékét. Ez rendkívül megterhelő lehet a teljesítmény szempontjából, mivel nagyobb telepítések esetén ez a feladat folyamatosan futhat és módosíthatja a dolgokat. Ez csak az én tippem, de elég sok értelme van, ha belegondolunk.

Hasonló megoldási javaslatok keringenek, amelyekben megtévesztik a SharePointot, hogy elfogadjon egy Ma értéket úgy, hogy először létrehoz egy Ma nevű oszlopot, majd hozzáadja a képlethez, majd törli. Ezek mind rendben vannak, de ne feledje, mit mondtam a számított oszlopok frissítéséről. Ez az érték csak a tétel frissítésekor változik, ami azt jelenti, hogy az értékek rövidesen helytelenek lesznek, főként ha egy napot számítanak.

Láttam, hogy mások okos JavaScriptet használnak az értékek oldalra írásához. Ez is működne, de nagyjából kategorikusan ellenzem a kliens szkriptet, ha elkerülhető.

Megvalósítás:

Szóval mit tegyünk? A számított oszlopok szóba sem jöhetnek az úgynevezett "villékony" függvényeknél, mint például Ma. Elképzelhető, hogy kifejleszthetünk valamilyen egyéni kódot, hogy ezt elintézzük helyettünk, például egy számított oszlopot, időzítőfeladatot vagy ütemezett folyamatot, amely minden egyes elemet frissít, amelyhez ezt a számítást el kell végezni. Ez azonban visszavezet minket az előző bekezdésben említett teljesítmény problémájához, és emellett ez egy törékeny megoldás, amely nagyon specifikus lenne a kérdéses oldalra/listára/oszlopra. E két aggodalom mellett keresned kell egy kocka fickót is, mint én, aki tudja, hogyan kell kódolni, és meg kell győzni, hogy fejlessze ki ezt a megoldást az Ön számára. De van egyszerűbb módszer is!

Ha rendelkezik a mezők létrehozásához és a lapok szerkesztéséhez szükséges jogosultsággal a webhelyen, és van némi ismerete az XSLT-ről és a nézetek létrehozásáról, akkor összeállíthat egy olyan XSL-sablont, amelyet felvehet egy listanézetbe, és amely pontosan kiszámítja az értéket minden alkalommal, amikor a lapot kérik. Ez a forgatókönyv megszünteti a teljesítménnyel kapcsolatos aggályainkat, és nincs szükség egyéni kód fejlesztésére és üzembe helyezésére egy megoldáson keresztül.

Tökéletes. Szóval hogyan csináljuk?

1. Hozza létre vagy válassza ki a forrásként használandó mezőt. Dátum típusúnak kell lennie.
2. Hozza létre a mezőt, amely a kiszámítandó érték helyőrzőjeként fog működni.
3. Vegye fel mindkét mezőt egy tartalomtípusba, és adja hozzá a tartalomtípust egy listához.
4. Hozzon létre a listáról egy olyan nézetet, amely tartalmazza a forrás- és a helyőrző oszlopot is.
5. Töltse fel az XSL-sablont a stílustárba.
6. Állítsa be a Listanézet kijelző "XSL-hivatkozás" tulajdonságát a felhasználói felületen keresztül.
7. Siker!

Nézzünk meg egy példa használati esetet, és haladjunk végig a megvalósításon. Ügyfelünk olyan nézetet szeretett volna látni a fő listáról, amelyből megtudhatja, hogy egy adott listaelem mennyi ideje van az állapotán. Ez a lista tartalmazott egy, az Elem típusból származtatott, a listához hozzáadott egyéni webhely-tartalomtípust. Már volt egy eseményérzékelő, amely rögzíti a listaelem állapotmezőjének minden módosítását, és menti a dátumot egy "Megváltozás dátuma" nevű oszlopba. Mindez a huzalozás nem szükséges, és BÁRMILYEN dátummezővel elvégezhető (történetesen ez a mi megvalósításunk, de nyugodtan kísérletezzen). A minimum, amire szüksége lesz, a listához hozzáadott forrásdátum mező és helyőrző mező a számítás tárolására (erről bővebben a következő bekezdésben olvashat), bár azt javaslom, hogy használjon webhelyoszlopokat és webhely-tartalomtípusokat arra az esetre, ha ezt a megoldást a webhely más helyein is újra fel szeretné használni.

Tehát megvan a forrásdátumunk, amelyet felhasználhatunk az aktuális dátummal való számításunkhoz. Most létrehozhatunk egy egyéni webhelyoszlopot, amelyet a számított érték tárolójaként használhatunk. Ebben az esetben egy számított oszlop használata mellett döntöttem, mivel az nem módosítható az új vagy az elem szerkesztésére szolgáló űrlapon, de kiválasztható a nézetekben való megjelenítésre, mivel nem szeretnénk, hogy a felhasználók tetszőleges értékeket adjanak meg ebben az oszlopban. Zavaró lehet, hogy miért nem jelenik meg a nézetekben stb.

Most, hogy megvan a webhelyoszlopunk, hozzáadhatjuk a listában használandó tartalomtípusok közé. Ezután létre kell hoznunk a saját nézetünket, amelyet később az XSLT-vel testre szabunk. Ügyeljen arra, hogy olyan szabványos nézetet hozzon létre, amely tartalmazza a forrásdátum oszlopot, valamint az új számított oszlopot, amely helyőrzőként fog működni a számított érték számára.

Mostanra minden a helyén van, amire szükségünk lesz az egyéni elévülési jelentés támogatásához. Már csak létre kell hozni az XSL-sablont, fel kell tölteni a webhely stílustárába, és hozzá kell kapcsolni a listanézethez. Az XSL-sablon, amelyet használni fogunk, tartalmazni fog néhány normál, SharePoint által létrehozott korrektúrát a nézet létrehozásához, valamint a saját egyéni korrektúránkat, amelyek felül tudják bírálni ennek bizonyos részeit, és kiszámítják a kívánt értéket.

Elismerésként ott, ahol az érdemes, a tényleges számítások elvégzéséhez használt XSL-sablonokat a "swirch" kegyesen megadta az MSDN fórumain:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Töltse le az általam összeállított XSL stíluslapot (aging.zip itt:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

Ha ezt megnyitja a kedvenc szövegszerkesztőjében, rengeteg normál SharePoint XSL-jelölést fog látni a nézetek megjelenítéséhez, ha folyamatosan görget lefelé a 357. sorig, látni fogja a korrektúrához hozzáadott egyéni sablonok elejét, az első a "DateDiff" sablon, amelyet a "julian-day" és a "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status" követ. Ez a három sablonunk, amelyek elkészítik és megjelenítik számításainkat a nézeteinkben. Ha a cikkben korábban megadottól eltérő mezőneveket szeretne használni, akkor végig kell néznie ezeket a sablonokat, és le kell cserélnie a többi nevekre mutató hivatkozásokat. Ne feledje, hogy ehhez a mező BELSŐ nevét érdemes használnia a megjelenítendő név helyett.

Ha meggyőződött arról, hogy a sablon készen áll, keresse meg a stílustárat, töltse fel az "XSL-stíluslapok" mappába, majd másolja a fájlra mutató hivatkozást. Ez lehetővé teszi számunkra, hogy később könnyen módosítsuk, vagy tetszés szerint hozzáadjuk a webhely különböző részeihez.

Ezután nyissa meg a listát, és válassza a cikkben korábban létrehozott nézetet. A "Webhelyműveletek" menüben kattintson az "Oldal szerkesztése" elemre.

Keresse meg a lapon a Listanézet kijelzőt, és a jobb felső sarokban található, lefelé mutató kis nyílra kattintva nyissa meg a kijelzőmenüt. A menüből válassza a "Kijelző szerkesztése" lehetőséget.

Ezzel megnyitja a kijelző menüjét a böngészőablak jobb oldalán.

Kattintson a + gombra az "Egyéb" szakaszhoz, és keresse meg az "XSL Link" tulajdonságot.

Illessze be az XSL-fájlra korábban másolt hivatkozást a stílustárba (ez lehet relatív és abszolút hivatkozás is).

Kattintson az "OK" gombra a módosítások mentéséhez, majd kattintson a "Szerkesztés leállítása" gombra az oldal tetején található "Oldal" menüszalagon.

Ha minden megfelelően volt konfigurálva, mostantól számokat kell látnia az "Állapot napja" oszlopban.

És végül, itt nézne ki néhány különböző dátumú tesztadattal:

Összefoglalás:

Itt is van: szépen formázott, hatékony és hatékonyabb módszer az elévülési jelentések létrehozására a SharePointban, egyszerű, kód nélküli implementációval kiegészítve. Ennek jó néhány potenciális alkalmazása van az itt megvizsgált egyetlen felhasználási eseten kívül. Az ilyen típusú jelentések egy gyakori esete, hogy az adatokat feladatlistához csatolják, így egy pillantással áttekintheti, hogy mennyi idő telt el a feladat létrehozása óta.

Jó szórakozást!

--Justin

Justin Joyce, LANtek

Megjegyzések

Hiányzó lépések
2012. 10. 08. 03:51
Követtem a lépéseket, de valami biztosan hiányzik - honnan tudja az XSL, hogy melyik dátumot kell használni, vagy melyik mezőbe kell hozzáadni az eltelt napok számát? Utálom, ha kihagysz lépéseket.

Kód nélkül, egyetértünk!
2012. 08. 30. 12:12
Egyetértek - nem hiszem, hogy ez igazán "nincs kódnak" számít.
Érdekes módon a SharePoint valami elrontása miatt van egy működő számított oszlopom, amely a Ma... nem tudom, hogyan és miért, mert nem tudom rávenni, hogy újra megcsinálja, de az egy még mindig ott van és működik.

Képlet az "Állapot napjai" számított oszlophoz?
2012. 05. 02. 07:39
Justin - Milyen képletet használt az "Állapot napjainak száma" számított webhelyoszlophoz (helyőrző oszlophoz)? Az volt, hogy "=ma"?

SharePoint 2007
2011.12.02. 11:29
Jelenleg még nem próbáltam meg a megoldást alkalmazni a SharePoint 2007-re, de nézem. Sajnos a felhasználói felületen keresztül nem jelenik meg XslLink tulajdonság a kijelzőn.

Nagyszerű bejegyzés
2011. 11. 30. 09:53
Üdv,
Nagyszerű bejegyzés.
SharePoint 2007-et használok.
Nincs Egyéb szakaszom, ahogy fentebb említettem.
Ismeri az SP2007 konfigurálásának lépéseit?
Köszönjük.

Re: Kód nélküli megoldás: SharePoint-listaelem utolsó módosítása óta eltelt napok megjelenítése
2011.10.11. 08:24
Szia Chris.
Nagyszerű lelet!
Remélhetőleg ma később megnézem, amit közzétettél, és megnézem, hogy egy kicsit robusztusabbá tudom-e tenni ezt a megoldást.
Örülök, hogy tetszett a bejegyzés, és nagyon örülök, hogy sikerült megoldást találni az európai dátumformátumra. :)
-Justin

Megoldás európai dátumformátumokhoz
2011.10.11. 06:45
Szia még egyszer Justin!
Tájékoztatásul, találtam megoldást a korábban említett problémára ezen az oldalon;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Európai dátumformátumok
2011.10.07. 03:59
Kedves Justin!
Ez egy nagyon jó megoldás, köszönöm, és pont az a fajta dolog, amit az elmúlt két napban kerestem! Azonban van egy kis problémám vele, és reméltem, hogy tudsz segíteni nekem.
Kissé megváltoztattam a kódodat, hogy kiszámítsam a napok számát, amíg valami történik, nem pedig azután, a "DateDiff" függvény utolsó sorában lévő változók cseréjével;

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

Azonban csak az esetek felében tudom helyesen kiszámolni a különbséget. Tehát például ezzel a dátummal (nn/hh/é. formátum);

30/12/2011

Helyesen számítja ki, de ezzel a dátummal (ugyanaz a formátum)

12/10/2011

A számítás úgy történik, mintha 2011. december 10. lett volna, nem pedig 2011. október 12.
Megpróbáltam egyszerűen megváltoztatni a nap és a hónap értékeinek pozícióját a "JulianStartDate" változóban, így;

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

És ez megoldotta a problémát a második dátummal, azonban akkor helytelen volt az első dátumnál!
Megpróbáltam a FormatDateTime hívásokat is módosítani az európai LCID-k használatára, és a FormatDateTime utolsó paraméterének (pl. nnMMéé, MMnnyyyyyy. KKdddyyyy) különféle módosításait, de nem járt sikerrel.
Nagyra értékelnék minden tanácsot, amit tud adni.
Köszönjük!
Krisztofer

No-Code
2011. 09. 21. 04:27
Nem hiszem, hogy az XSL "kód nélküli" megoldásnak minősülne, mivel az XSL nyelv megértése nem mindenki számára - azonban nem jár programozással. Ezen kívül: Szép megoldás, köszönöm!