Koodita lahendus: loendiüksuse viimasest muutmisest möödunud päevade kuvamine
Rakenduskoht
Justin Joyce, LANtek
Märkus.: See artikkel on osa postituste kogumist, mis pärinevad SharePointi lõppkasutajate ajaveebist "Hangi punkt ".
Ülevaade: koodita kohandatud aegumisaruanded
Üks SharePointi saidi sageli taotletud funktsionaalsetest osadest on tööülesannete või loendiüksuste aegumisaruanne. Teisisõnu, mitu päeva/kuud on sellest loendiüksuse viimasest muutmisest möödunud?
Pinnal tundub see olevat väga lihtne taotlus. Lõppude lõpuks on meil üksuste loomise ja muutmise kuupäevad, meil on võimalik salvestada kohandatud kuupäevi, kui teatud muudatused toimuvad sündmuste vastuvõtjate kaudu. Meil on arvutuslikud veerud, kuhu saame teabega töötamiseks kaasata Exceli-laadseid valemeid. See tundub olevat üsna sirgjooneline ettepanek. Valime kuupäevavälja, loome arvutusliku veeru ja seejärel teeme valemi, mis on seotud ridade [DateField] – [Täna] ridadega. Ah, mitte nii kiiresti! Kuna kõik, kes on proovinud seda lihtsat ülesannet, teavad, et katse kasutada arvutuslikus veerus midagi sarnast [Täna] põhjustab probleeme. Proovige lisada arvutatud veeru valemiväljale [Täna] järgmine tõrketeade:
Miks see nii on? See peab olema seotud sellega, kuidas arvutatud veerge arvutatakse.
Võtame näiteks lihtsa valemi:
= IF( [Veerg1]<=[Veerg2], "OK", "Pole OK")
Kõik see ütleb, et kui veerg1 on väiksem kui teine veerg või sellega võrdne, siis kuvaDA OK, muul juhul kuvada Pole OK. See on arvutusliku veeru üsna tüüpiline põhivalem ja see eeldab neid veerge sisaldava loendiüksuse kohta: veerud Veerg1 ja Veerg2 ei saa ilma loendiüksusel sündmuse Värskendata muuta.
See on õige, arvutatud veerud arvutatakse ümber ainult siis, kui loendit värskendatakse (või luuakse), kuna need eeldavad, et arvutuslik teave sisaldub üksuses endas. See tekitab probleemi, kui proovite kasutada midagi, mis muutub üksuse väljadest sõltumatult (nt tänane kuupäev).
Ma ei olnud koosolekul, kus nad otsustasid, et nii töötavad arvutuslikud veerud, aga kui peaksin tegema haritud oletuse, siis ma eeldan, et need toimivad jõudluse jaoks nii. Oletagem, et teil oleks loend mitmest tuhandest üksusest, millest igaüks sisaldas arvutatud veergu, mis vajas reaalajas värskendamist. See tähendaks, et mõni mehhanism ( ehk ajastitöö) peaks itereerima läbi iga üksuse, mis sisaldas seda arvutatud veergu igal nii tihti ja värskendama selle väärtust. See võib jõudluse osas olla äärmiselt maksustav, kuna suuremate juurutustega võib see töö pidevalt töötada ja asju muuta. See on lihtsalt minu arvamus, aga see on üsna mõttekas, kui sa sellele mõtled.
Siin on mõned soovitused sarnaste lahenduste leidmiseks, mis hõlmavad SharePointi petmist väärtuse Täna aktsepteerimiseks, luues esmalt veeru nimega Täna, seejärel lisades selle oma valemisse ja seejärel kustutades selle. Need kõik on head ja head, kuid pidage meeles, mida ma ütlesin, kui arvutuslikke veerge värskendatakse. See väärtus muutub ainult siis, kui üksust värskendatakse, mis tähendab, et teie väärtused on varsti valed, eriti päevaarvutuse korral.
Olen näinud teisi, kes kasutavad lehele väärtuste kirjutamiseks nutikat JavaScripti. See toimiks ka, kuid ma olen üsnagi kategooriliselt kliendi skripti vastu, kui seda on võimalik vältida.
Rakendamine:
Mida teha? Arvutuslikud veerud ei vasta nn lenduvate funktsioonide (nt Täna) küsimusele. On võimalik, et saame välja töötada kohandatud koodi, et saaksime selle eest hoolitseda nagu arvutatud veerg, ajastitöö või ajastatud protsess, mis tuleb kaasa ja värskendab iga üksust, mis seda arvutust vajab. See toob meid tagasi jõudlusprobleemi juurde, mida mainisin viimases lõigus, ja lisaks sellele on see rabe lahendus, mis oleks kõnealuse saidi/loendi/veeru jaoks väga spetsiifiline. Lisaks neile kahele murele peaksite leidma ka nerdy mehe, nagu mina, kes teab, kuidas koodi panna ja veenda teda seda lahendust teie jaoks välja töötama. Aga on ka lihtsam viis!
Kui teil on saidil väljade loomise ja lehtede redigeerimise õigus ning teil on veidi teadmisi XSLT ja vaadete loomise kohta, saate koostada XSL-malli, mida saab loendivaatesse kaasata, ja arvutab teie väärtuse usaldusväärselt iga kord, kui lehte taotletakse. See stsenaarium eemaldab meie mure jõudluse pärast ja ei nõua kohandatud koodi arendamist ja juurutamist lahenduse abil.
Täiuslik. Kuidas me seda teeme?
-
Looge või valige väli, mis toimib meie allikana. See peab olema kuupäevatüüp.
-
Looge meie väli, mis toimib arvutatava väärtuse kohatäitena.
-
Lisage mõlemad väljad sisutüübile ja lisage see sisutüüp loendisse.
-
Saate luua selle loendi vaate, mis sisaldab nii lähte- kui ka kohatäiteveerge.
-
Laaditeeki üles XSL-malli.
-
Seadke kasutajaliidese kaudu loendivaate veebiosa atribuut XSL-link.
-
Õnnestus!
Vaatame näite kasutusjuhtumit ja tutvustame selle rakendamist. Meie klient soovis vaadata oma põhiloendit, mis ütleks talle, kui kaua konkreetne loendiüksus on oma olekus olnud. See loend sisaldas kohandatud saidisisutüüpi, mis on tuletatud üksusetüübist ja lisatud loendisse. Sündmusevastuvõtja oli juba paigas, mis jäädvustab iga kord, kui loendiüksuse olekuvälja muudeti ja salvestati see kuupäev veergu nimega "Muudetud kuupäeva olek". Kogu see juhtmestik ei ole nõutav ja seda saab teha IGA kuupäevaväljaga (see lihtsalt juhtub, et see on meie rakendamine, kuid võite julgelt katsetada). Vähim, mida vajate, on lähtekuupäeva väli ja kohatäiteväli, et hoida loendis arvutusi (rohkem selle kohta järgmises lõigus), kuigi ma soovitan kasutada saidiveerge ja saidi sisutüüpe juhuks, kui soovite seda lahendust oma saidi muudes kohtades uuesti kasutada.
Seega on meil lähtekuupäev, mida saame kasutada arvutuses tänase kuupäeva suhtes. Nüüd saame luua kohandatud saidiveeru, mida kasutada oma arvutatud väärtuse ümbrisena. Sel juhul valisin arvutusliku veeru kasutamise, kuna seda ei saa uutel üksusevormidel muuta ega redigeerida, kuid selle saab valida vaadetes kuvamiseks, kuna me ei soovi, et kasutajad sisestaksid sellesse veergu suvalisi väärtusi. See võib segadusse ajada, miks seda vaadetes ei kuvata jne.
Nüüd, kui meil on saidiveerg, saame selle lisada oma sisutüüpidesse, mida loendis kasutatakse. Järgmiseks peame looma oma vaate, mida hiljem XSLT-ga kohandatakse. Looge kindlasti standardvaade, mis sisaldab lähtekuupäeva veergu ja uut arvutatud veergu, mis toimib arvutatud väärtuse kohatäitena.
Meil on nüüd olemas kõik, mida vajame oma kohandatud aegumisaruande toetamiseks. Alles jääb ainult meie XSL-malli loomine, saidi laaditeeki üleslaadimine ja selle linkimine loendivaatega. Kasutatav XSL-mall sisaldab vaate loomiseks tavapärast SharePointi loodud märgistust, samuti meie kohandatud märgistust, mida kasutatakse teatud osade alistamiseks ja meile soovitud väärtuse arvutamiseks.
Krediidi andmine juhul, kui krediiti tuleb, XSL-mallid tegelike arvutuste tegemiseks, mida ma selle lahenduse jaoks kasutan, pakkus msDN-i foorumites meeldivalt "nipsamine":http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/
Laadige alla XSL-laadileht (aging.zip), mille olen kokku pannud, asub siin:https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104
Kui avate selle oma lemmiktekstiredaktoris, kuvatakse vaadete renderdamiseks palju SharePoint XSL-i tavalisi märgistusi. Kui liigute edasi reani 357, kuvatakse märgistusele lisatud kohandatud mallide algus, millest esimene on "DateDiff" mall, millele järgnevad "calculate-julian-day" ja "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Need on meie kolm malli, mis teevad ja kuvavad meie vaates arvutusi. Kui kavatsete kasutada teistsuguseid väljanimesid kui selles artiklis varem määratud, peate need mallid läbima ja asendama viited muudele nimedele. Pidage meeles, et selleks soovite kasutada välja SISEMIST nime, mitte kuvatavat nime.
Kui olete veendunud, et mall on kasutamiseks valmis, liikuge laaditeeki ja laadige see üles kausta "XSL-laadilehed" alla ja kopeerige seejärel faili link alla. See võimaldab meil hiljem hõlpsalt muudatusi teha või lisada need vastavalt soovile saidi eri osadesse.
Järgmiseks avage loend ja valige selles artiklis varem loodud vaade. Klõpsake menüüs "Saiditoimingud" nuppu Redigeeri lehte.
Leidke lehelt loendivaate veebiosa ja avage menüü Veebiosa, klõpsates paremas ülanurgas olevat väikest allanoolt. Valige selle menüü kaudu "Redigeeri veebiosa".
Veebiosa menüü avatakse brauseriakna paremas servas.
Klõpsake jaotises "Muud" nuppu +ja otsige üles atribuut "XSL Link".
Kleepige varem kopeeritud laaditeegis XSL-faili link (see võib olla suhteline või absoluutne link).
Muudatuste salvestamiseks klõpsake nuppu OK ja seejärel lehe ülaservas asuval lindil "Leht" nuppu "Lõpeta redigeerimine".
Kui kõik on õigesti konfigureeritud, peaksite nüüd nägema numbreid veerus "Päevad olekus".
Ja lõpuks, siin näete, kuidas see erinevate kuupäevade testandmetega välja näeks.
Kokkuvõte.
See on olemas: hästi vormindatud, töökindel ja paremini toimiv viis SharePointis aeguva aruande loomiseks. Sellel on üsna vähe potentsiaalseid rakendusi peale selle, mida siin uurisime. Teine seda tüüpi aruande tavaline stsenaarium on selle manustamine ülesandeloendile, et saaksite kiiresti vaadata, kui kaua on möödunud tööülesande loomisest.
Head kasutamist.
--Justin
Justin Joyce, LANtek
Kommentaarid
Etapid puuduvad 08.10.2012 3:51 ok Ma järgisin juhiseid, kuid midagi peab olema puudu - kuidas XSL teab, millist kuupäeva kasutada või millisele väljale lisada päevi alates? vihkan seda, kui sammud on möödas.
Koodita, kokku lepitud! 30.08.2012 12:12 Ma olen nõus - ma ei usu, et see tõesti loeb "koodita".Huvitaval kombel on mul SharePointi kruvimise läbi töötav arvutatud veerg, mis kasutab funktsiooni Täna... ei tea, kuidas või miks, sest ma ei saa seda uuesti teha, kuid see on ikka seal ja töötab.
Arvutatud veeru "Days At Status" valem? 2.05.2012 07:39 Justin – mis valemit kasutate arvutatud saidiveeru "Days At Status" (kohatäiteveerg) jaoks? Kas see oli "=täna"?
SharePoint 2007 12.02.2011 11:29 Praegu pole ma proovinud seda lahendust rakendusele SharePoint 2007 rakendada, kuid otsin seda. Kahjuks pole veebiosas kasutajaliidese kaudu surface'i atribuuti XslLink.
Suurepärane postitus 30.11.2011 9:53 Tere Suurepärane postitus.Kasutan versiooni SharePoint 2007.Mul pole eespool märgitud jaotist Misc.Kas teil on sp2007 konfiguratsiooni juhised? Täname.
Re: Koodita lahendus: SharePointi loendiüksuse viimasest muutmisest möödunud päevade kuvamine 11.10.2011 8:24 Tere, Chris.suurepärane leid! Ma vaatan, mida te täna hiljem postitasite, ja vaatan, kas saan selle lahenduse veidi töökindlamaks muuta.Mul on hea meel, et teile see postitus meeldis, ja mul on väga hea meel, et saite leida lahenduse Euroopa kuupäevavormingule. :) -Justin
Lahendus Euroopa kuupäevavormingutele 11.10.2011 6:45 Tere veel kord, Justin, Teadmiseks: leidsin lahenduse sellele probleemile, mida ma sellel lehel varem mainisin;https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/
Euroopa kuupäevavormingud 07.10.2011 3:59 Tere, Justin! See on väga hea lahendus tänu, ja just selline asi, mida ma olen veetnud viimased kaks päeva otsides! Aga mul on sellega väike probleem ja ma lootsin, et sa saad mind aidata.Olen koodi pisut muutnud, et arvutada päevade arv, kuni midagi juhtub, mitte sellest ajast alates, vahetades muutujaid funktsiooni "DateDiff" viimases reas; <xsl:value-of select="$JulianToday - $JulianStartDate"></xsl:value-of> Kuid ma saan selle ainult nii, et see kakleks vahet õigesti poole ajaga. Nii et näiteks selle kuupäevaga (vorming kk/KK/aa); 30/12/2011 See arvutab õigesti, kuid selle kuupäevaga (samas vormingus) 10.12.2011 See arvutab nii, nagu oleks 10. dets 2011, mitte 12. okt 2011.Püüdsin lihtsalt vahetada päeva- ja kuuväärtuste positsioone muutujas "JulianStartDate", nagu see; <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)"/> Ja see parandas teise kuupäeva probleemi, kuid see oli siis esimese kuupäeva puhul vale! Samuti olen proovinud muuta FormatDateTime'i kutseid, et kasutada Euroopa LCID-sid ja erinevaid muudatusi FormatDateTime'i viimases parameetris (nt ddMMyyyy, MMddyyyy) koos sobivate muudatustega alamstringi positsiooniparameetritele ilma õnnestumiseta.Ma hindaksin väga kõiki nõuandeid, mida sa pakkuda oskad.Tänud Chris
Koodita 21.09.2011 4:27 Ma ei usu, et XSL kvalifitseerub "koodita" lahendusena, sest XSL-keele mõistmine ei ole kõigi jaoks , kuid see ei hõlma programmeerimist. Lisaks sellele: tore lahendus, aitäh!