No-Code Solution: a listaelemek utolsó módosítását követő napok megjelenítése

Áttekintés: egyéni korosítási jelentések kód nélkül

A SharePoint-webhelyek egyike, gyakran igényelt funkcionális elem a feladatok vagy listaelemek elévülési jelentése. Más szóval hány nap/hónap telt el azóta, hogy ez a listaelem utoljára módosult?

A felszínen úgy tűnik, hogy egy egyszerű kérés. Végül is van dátumok a létrehozott és módosított elemekhez, képesek vagyunk arra, hogy egyéni dátumokat tároljon, ha az egyes elemeken végzett módosítások az esemény címzettei között történnek. Számítottunk olyan oszlopokat, amelyekben az adatokkal együtt az Excel-Like képletek is használhatók. Úgy tűnik, ez egy elég egyenes előre Proposition. Kiválasztunk egy dátummező mezőt, létrehozunk egy számított oszlopot, és egy képletet rajzolunk a [DateField] – [ma] sorok mentén. Ah, de nem olyan gyors! Mint bárki, aki megkísérelte az "egyszerű" feladatát, a következőhöz hasonló problémát tapasztal: egy számított oszlopban valami hasonlót próbál használni [ma]. Ha a számított oszlop képlet mezőjébe be szeretné szúrni a [ma] értéket, a következőhöz hasonló hibaüzenet jelenik meg:

Mi a teendő? Nos, a számított oszlopok számításának módját kell tennie.

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

= Ha ( [Oszlop1] <= [Oszlop2], "OK", "nem ok")

Mindez azt jelenti, hogy ha a Oszlop1 kisebb vagy egyenlő Oszlop2, akkor az OK gombra kell mutatnia, ellenkező esetben nem jelenik meg OK. Ez egy elég tipikus egyszerű képlet egy számított oszlophoz, és alapvető feltételezést ad az alábbi oszlopokat tartalmazó listaelemre: a Oszlop1 és a Oszlop2 nem fog tudni változásokat tenni a listaelemek frissítési eseménye nélkül.

Így van, a számított oszlopok csak akkor kerülnek újraszámításra, ha a lista frissül (vagy létrejön), mert a számításban szereplő adatok magukban az elemben szerepelnek. Ez problémát okoz, ha olyan műveletet próbál meg használni, amely az elem mezőitől függetlenül változik, például a mai dátum.

Most nem voltam abban az értekezletben, ahol úgy döntöttek, hogy ez az út a számított oszlopok működéséhez szükséges, azonban ha egy művelt kinézetet kellett volna feltételezni, hogy a teljesítményhez így működnek. Képzelje el, ha több ezer elemből áll, amelyek mindegyike tartalmaz egy "Live" frissítést igénylő számított oszlopot. Ez azt jelentené, hogy egy bizonyos mechanizmust, esetleg egy időzítőt kell megismételni minden olyan elemen, amely az adott számított oszlopot minden olyan esetben meg kell ismételni, amely frissíti az értékét. Ez rendkívül megadóztatást jelent a teljesítmény terén, mert a nagyobb központi telepítésekkel a munkahelye folyamatosan fut és változó dolgokat tartalmaz. Ez csak az a gyanúm, de ez elég némi értelme, ha belegondol.

Vannak javaslatok a hasonló megoldásokra, amelyek körül lebeg a SharePoint befogása a mai érték elfogadásához, először létre kell vennie egy ma nevű oszlopot, majd hozzá kell adni a képlethez, majd törölnie kell azt. Ezek mind jóak és jók, de emlékszem, hogy mit mondtam a számított oszlopok frissítésekor. Ez az érték csak akkor változik, ha az elem frissül, ami azt jelenti, hogy az értékek hamarosan helytelenek lesznek, különösen napi számítás esetén.

Láttam másokat a ravasz JavaScript használatával az oldal értékének megírásához. Ez a funkció azt is megkönnyíti, hogy elkerülhető legyen az ügyfél parancsfájlja ellen.

Megvalósítás

Mi a teendő? A számított oszlopok nem jelennek meg az úgynevezett "változékony" függvények esetében, mint napjainkban. Lehetséges, hogy néhány egyéni kódot kifejlesztünk, hogy kidolgozzunk a számunkra, például egy számított oszlopban, időzítő munkahelyen vagy ütemezett folyamatban, és frissítsen minden olyan elemet, amelyre szüksége van ehhez a számításhoz. Ezzel visszavezet bennünket az utolsó bekezdésben említett teljesítmény problémájára, és emellett törékeny megoldás, amely erősen jellemző a kérdéses webhelyre/listára vagy oszlopra. A fenti két aggályon felül meg kell keresnie egy nerdy fickót is, például saját magam, hogy hogyan tudja megkeresni a kódot, és rábeszélve arra, hogy fejlessze ezt a megoldást. De van egy egyszerűbb mód!

Ha van jogosultsága a webhelyek létrehozásához és a webhelyek szerkesztéséhez, valamint az XSLT-vel és a nézetek létrehozásával kapcsolatban, akkor egy olyan XSL-sablont hozhat létre, amely tartalmazni fogja a lista nézetét, és hűen kiszámítja az értékét minden alkalommal, amikor a lapot kéri. Ez a forgatókönyv a teljesítménnyel kapcsolatos aggályokat távolítja el, és nem igényel egyéni kódot a megoldáson keresztül.

Tökéletes. Hogyan teheti ezt meg?

1. Hozza létre vagy jelölje ki azt a mezőt, amely a forrásként fog működni. A dátum típusnak kell lennie.

2. Hozza létre a mezőt, amely helyőrzőként fog működni a kiszámított értékhez.

3. Vegye fel mindkét mezőt egy tartalomtípusba, és adja hozzá a kívánt tartalomtípust egy listához.

4. Hozza létre a lista nézetét, amelyben a forrás-és a helyőrző oszlopok is szerepelnek.

5. Töltse fel az XSL-sablont a stílusok tárba.

6. A listanézet kijelző "XSL link" tulajdonságának beállítása a felhasználói felületen keresztül

7. Siker!

Fedezzük fel a példa használati esetét, és végezze el a megvalósítást. Ügyfelünk azt akarta, hogy megtekinthesse a fő listát, amely azt közölte, hogy egy adott listaelem mennyi ideig ült az állapota. Ez a lista egy egyéni webhelytartalom-típust tartalmaz, amelyet az elemtípus származtatott, és a listához lett hozzáadva. Már van olyan esemény-vevőkészülék a helyén, amely rögzíti, hogy az állapot mező a listaelemben módosult, és a dátumot a "dátum állapota módosított" nevű oszlopba mentette. Ehhez a kábelezéshez nincs szükség, és bármilyen Date mezővel elvégezhető (csak így történik ez a megvalósítás, de bátran kísérletezhet). A minimális szükség lesz a forrás dátuma mező és a helyőrző mező a kiszámításhoz (a következő bekezdésben továbbiak szerint), de azt javasoljuk, hogy a webhely oszlopait és a webhely tartalomtípusait használja, ha a webhely más helyein szeretné használni a megoldást.

Így a mai dátum szerint kiszámításunk során használható a forrás dátuma. Most létrehozunk egy egyéni webhely oszlopot, melyet tárolóként használhatunk számított értékként. Ebben az esetben úgy döntöttem, hogy számított oszlopot használok, mert az nem módosítható az új vagy a szerkesztési elem űrlapon, de a nézetben való megjelenítéshez kiválasztható, mert a felhasználók nem szeretnék önkényes értékeket bevinni az oszlopba. Zavaró lehet, hogy miért nem jelennek meg a nézetekben stb.

Most, hogy a mi oldalunkon oszlopunk van, felveheti azt a listába felhasználható tartalomtípusokra. Ezután létre kell hoznia a nézetet, amelyet később testre szabhatók az XSLT-vel. Győződjön meg arról, hogy olyan normál nézetet hoz létre, amely tartalmazza a forrás dátuma oszlopot és az új számított oszlopot, amely a számított érték helyőrzőként fog megjelenni.

Most már mindent megteszünk, hogy az egyéni öregedési jelentésünk támogatására lesz szükségünk. Minden marad az XSL-sablon létrehozása, feltöltése a webhely stíluslapján, és összekapcsolása a lista nézettel. A használni kívánt XSL-sablon tartalmazni fog egy olyan normál SharePoint-alapú korrektúrát, amely a nézet generálására szolgál, és a saját egyéni korrektúrákat fogja tartalmazni, melyek felülbírálják a számunkra szükséges értéket.

Ha a jóváírás miatt hitelt ad, akkor az alábbihoz hasonló módon végezheti el az ehhez a megoldáshoz használt XSL-sablonokat: "swirch" az MSDN-fórumokon:
http://Social.msdn.microsoft.com/forums/en-us/sharepointcustomization/Thread/aeda905b-9bc6-40c4-BD22-21306c5cb0d2/

Töltse le az XSL-stíluslapot (aging.zip), amelyet a következő helyen tettem meg:
https://OneDrive.Live.com/?CID=c262e8e2d59a86d9&permissionsChanged = 1&ID = c262e8e2d59a86d9! 104

Ezt a lehetőséget választva a kedvenc szövegszerkesztőben sok olyan normál SharePoint-XSL-korrektúrát fog látni, amely a nézeteket jeleníti meg, ha a legördülő menüben a 357-as vonalon lefelé görget, a korrektúrához hozzáadott egyéni sablonok elejét fogja látni, az első a "DateDiff" sablon, majd a "számítás-Julian-Day" és a "FieldRef_printTableCell_EcbAllowed. Days_x0020_At_x0020_Status" parancsot. Az alábbi három sablonból megtekintheti és megjelenítheti a számításaikat a nézeteiben. Ha a jelen cikkben korábban meghatározottak szerint eltérő mezőneveket fog használni, akkor ezeket a sablonokat kell átírnia, és cserélnie kell az egyéb nevekre mutató hivatkozásokat. Ne felejtse el, mert ez a mező belső nevét fogja használni, nem a megjelenítendő nevet.

Ha meggyőződött róla, hogy a sablon készen áll a keresésre, keresse meg a saját stíluslapját, és töltse fel az "XSL-stíluslapok" mappába, majd másolja le a fájlra mutató hivatkozást. Ez lehetővé teszi számunkra, hogy később egyszerűen végezze el a módosításokat, vagy vegye fel a webhely különböző részeire.

Ezután lépjen a listára, és válassza ki a cikkben korábban létrehozott nézetet. A "Webhelyműveletek" menüben kattintson az "oldal szerkesztése" parancsra.

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

Ekkor megnyílik a kijelző menüje a böngészőablak jobb szélén.

Kattintson a + gombra az "egyéb" szakaszhoz, és keresse meg az "XSL-hivatkozás" tulajdonságot.

Illessze be a korábban másolt stílusok tárban lévő XSL-fájlra mutató hivatkozást (ez lehet relatív vagy abszolút hivatkozás).

Kattintson az "OK" gombra a módosítások mentéséhez, majd kattintson a lap tetején a "lap" menüszalagon lévő "szerkesztés leállítása" gombra.

Ha minden beállítás helyes volt, akkor most már láthatja a számokat a "napok az állapotnál" oszlopban.

Végül pedig az alábbiakat érdemes kinéznie különböző dátumok vizsgálati adataival:

Összefoglalás:

Itt van: egy szépen formázott, robusztus és hatékonyabb megvalósítási mód egy öregedő jelentés létrehozásához a SharePointban. Ez már csak néhány lehetséges alkalmazást tartalmaz, amelyeket az itt ismertetett használati eseteken kívül is feltárunk. Az ilyen típusú jelentések egy másik gyakori forgatókönyve egy feladatlistához csatolja, így láthatja, hogy mennyi ideig volt létrehozva egy feladat egy szempillantás alatt.

Jó szórakozást!

--Justin

Justin Joyce, LANtek

Megjegyzések

Hiányzó
lépések 10/8/2012 3:51 AM
ok követtem a lépéseket, de valami hiányzik – hogyan fogja tudni az XSL-nek, hogy melyik dátumot kell használnia, vagy hogy melyik mezőben szeretné hozzáadni a napokat? Utálom, ha a lépések elmaradnak.

No-Code (megegyezett!
) 8/30/2012 12:12 PM
Egyetértek – nem hiszem, hogy ez tényleg "nincs kód".
Érdekes módon, a SharePoint néhány screwup keresztül van egy munkamennyiség számított oszlop a mai napon... nem biztos abban, hogy miért vagy miért nem tudom azt újra elvégeznie, de az egyik még mindig ott van és működik.

A "napok" állapotú számított oszlop
képlete 5/2/2012 7:39 AM
Justin – mi az a képlet, amelyet a "napok az állapothoz" kifejezéshez használt a "számított hely" oszlop (helyőrző oszlop) esetén? "= Ma" volt?

SharePoint 2007
12/2/2011 11:29 AM
Jelenleg még nem kísérelte meg alkalmazni ezt a megoldást a SharePoint 2007-ra, de rákeresem. Sajnos a kijelzőn nincs XslLink tulajdonság a felhasználói felületen keresztül.

Nagyszerű bejegyzés
11/30/2011 9:53 AM
Helló,
Nagyszerű bejegyzés.
A SharePoint 2007-ot használom.
Nem rendelkezem a fentivel jelzett egyéb szakasszal.
Van egy SP2007-konfigurációval kapcsolatos lépései?
köszönöm.

Re: nem-kód megoldás: a SharePoint-listaelemek utolsó módosítását
követő napok megjelenítése 10/11/2011 8:24 AM
Szia Kristóf.
nagyszerű keresés!
a mai nap és a mai nap, a mai nap és a mai nap megkeresése után is láthatom, hogy ez a megoldás kicsit robusztusabb.
Örülök, hogy tetszett a bejegyzés, és nagyon örülök, hogy megoldást talált az Európai dátumformátumot. :)
-Justin

Megoldás az Európai dátumformátumot
10/11/2011 6:45 AM
Szia ismét Justin,
A cikkben korábban említett probléma megoldását találtam a lapon;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-Work-Around-to-date-Format-Issue-SharePoint-2010/

Európai dátumformátum
10/7/2011 3:59 AM
Szia Justin,
Ez egy igazán jó megoldás, és csak az a valami, amit az elmúlt két napon töltöttem! Van azonban egy kis probléma, és reméltem, hogy segíthet nekem.
Kissé Módosítottam a kódot, hogy calcultate a napok számát, amíg valami nem történik, nem pedig a "DateDiff" függvény utolsó sorában lévő változók közötti váltással;

<xsl: Value-of Select = "$JulianToday-$JulianStartDate" ></xsl: Value-of>

Ha azonban csak az idő felét szeretném megkapni, caclulate a különbséget. Így például ezzel a dátummal (nn/hh/éééé formátumban);

30/12/2011

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

12/10/2011

Úgy számítja ki, mintha 10 – Dec-2011 helyett 12 – TOT – 2011.
A "JulianStartDate" változóban csak a nap és a hónap értékek pozícióját próbáltam átváltani, az alábbihoz

hasonlóan: <xsl: with-params Name = "Month" Select = "alkarakterlánc (ddwrt: FormatDateTime (karakterlánc ($StartDate), 1033," ÉÉÉÉHHNN "), 7, 2)"/>
<xsl: with-params Name = "Day" Select = "alkarakterlánc (ddwrt: FormatDateTime (karakterlánc ($StartDate), 1033, ' ÉÉÉÉHHNN '), 5, 2)"/>

És ez korrigálta a problémát a második dátummal, de az első napon helytelen volt.
Megpróbáltam módosítani az FormatDateTime-hívásokat az Európai LCID-EK és a FormatDateTime utolsó paraméterének (például ddMMyyyy, MMddyyyy) használatára, és nem kell sikerrel elvégeznie a karakterlánc pozíciójának megfelelő módosításokat.
Nagyra értékelem, hogy milyen tanácsot tud ajánlani.
Köszi,
Chris

No-Code (kód
) 9/21/2011 4:27 AM
Nem hiszem, hogy az XSL a "nem kódolt" megoldást veszi fel, mivel az XSL-nyelv nem mindenki számára érhető el, de a programozással nem jár. A fentieken kívül: kellemes megoldás, Köszönjük!