de Justin Joyce, LANtek
Notă
Acest articol face parte dintr-o colecție de postări din patru ani de blog Get the Point pentru utilizatorii finali SharePoint.
Prezentare generală: Rapoarte de vechime particularizate, fără cod
Unul dintre părțile funcționale solicitate adesea ale unui site SharePoint este un raport de vechime pentru activități sau elemente de listă. Cu alte cuvinte, câte zile/luni au trecut de când acest element din listă a fost modificat ultima dată?
La suprafață, aceasta pare a fi o cerere foarte simplă. La urma urmei, avem date pentru elementele create și modificate, avem capacitatea de a stoca date personalizate când anumite modificări ale elementelor au loc prin intermediul receptorilor de evenimente. Am calculat coloane în care putem include formule de tip Excel pentru a lucra cu informațiile noastre. Aceasta pare o propunere destul de simplă. Selectăm un câmp de date, creăm o coloană calculată, apoi facem o formulă de genul [CâmpDată] – [Azi]. Ah, nu atât de repede totuși! După cum știe toți cei care au încercat această activitate "simplă", încercarea de a utiliza ceva de genul [Azi] într-o coloană calculată cauzează probleme. Încercați să inserați [Azi] în caseta de formule a coloanei calculate va returna un mesaj de eroare asemănător cu următorul:
De ce se întâmplă acest lucru? Ei bine, are de-a face cu modul în care se calculează coloanele calculate.
Să luăm ca exemplu o formulă simplă:
= IF( [Coloana1]<=[Coloana2], "OK", "Nu este OK")
Toate acestea spun că dacă Coloana1 este mai mică sau egală cu Coloana2, afișează OK, altfel afișează Nu OK. Aceasta este o formulă de bază destul de tipică pentru o coloană calculată și face o presupunere de bază despre elementul de listă care conține aceste coloane: Valorile pentru Coloana1 și Coloana2 nu se vor putea modifica niciodată fără un eveniment de actualizare pentru elementul de listă.
Corect, coloanele calculate vor fi recalculate doar atunci când lista este actualizată (sau creată), deoarece presupun că informațiile pe care le calculați sunt conținute în elementul propriu-zis. Acest lucru creează o problemă atunci când încercați să utilizați ceva care se modifică independent de câmpurile elementului, cum ar fi data de astăzi.
Nu am fost la întâlnirea în care au decis că acesta este modul în care vor funcționa coloanele calculate, totuși, dacă ar trebui să fac o presupunere educată, aș presupune că funcționează în acest fel pentru performanță. Imaginați-vă dacă ați avea o listă de câteva mii de elemente și fiecare ar conține o coloană calculată care necesită o actualizare "live". Aceasta ar însemna că un mecanism, poate un cronometru, ar trebui să itereze prin fiecare element care conține acea coloană calculată din când în când și să-i actualizeze valoarea. Acest lucru ar putea fi extrem de solicitant în ceea ce privește performanța, deoarece, în cazul implementărilor mai mari, această activitate ar putea rula și schimba constant lucrurile. Asta este doar presupunerea mea, dar are destul de mult sens dacă te gândești la asta.
Există câteva sugestii pentru soluții similare care implică păcălirea SharePoint să accepte o valoare Azi, creând mai întâi o coloană numită Azi, apoi adăugând-o la formulă, apoi ștergând-o. Toate acestea sunt bune și bune, dar rețineți ce am spus despre momentul în care se actualizează coloanele calculate. Această valoare se va modifica doar atunci când elementul este actualizat, ceea ce înseamnă că valorile vor fi în curând incorecte, mai ales în cazul unui calcul cu zi.
Am văzut și alții care folosesc JavaScript inteligent pentru a scrie valorile în pagină. Și asta ar funcționa, dar sunt destul de categoric împotriva scriptului client atunci când poate fi evitat.
Implementare:
Deci, ce trebuie să faceți? Coloanele calculate nu sunt în discuție pentru așa-numitele funcții "volatile", cum ar fi Today. Este posibil să dezvoltăm un cod particularizat care să se ocupe de acest lucru pentru noi, cum ar fi o coloană calculată, o activitate de cronometrare sau un proces planificat care să apară și să actualizeze fiecare element care are nevoie de acest calcul. Asta ne aduce înapoi la problema performanței pe care am menționat-o în ultimul paragraf și, în plus, este o soluție fragilă care ar fi foarte specifică site-ului/listei/coloanei în cauză. Pe lângă aceste două preocupări, ar trebui să mergi și să găsești un tip tocilar, ca mine, care știe să codifice și să-l convingă să dezvolte această soluție pentru tine. Dar există o modalitate mai simplă!
Dacă aveți drepturi pentru crearea de câmpuri și editarea paginilor pe site și aveți cunoștințe despre XSLT și crearea de vizualizări, puteți crea un șablon XSL care poate fi inclus într-o vizualizare listă și care va calcula fidel valoarea de fiecare dată când se solicită pagina. Acest scenariu elimină grija noastră legată de performanță și nu necesită dezvoltarea și implementarea de cod particularizat prin intermediul unei soluții.
Perfect. Deci, cum o facem?
- Creați sau selectați câmpul care va acționa ca sursă. Trebuie să fie de tip dată.
- Creați câmpul nostru care va acționa ca un substituent pentru valoarea calculată.
- Adăugați ambele câmpuri la un tip de conținut și adăugați acel tip de conținut la o listă.
- Creați o vizualizare a listei care să conțină atât coloana sursă, cât și coloana substituent.
- Încărcați șablonul XSL în Biblioteca de stiluri.
- Setați proprietatea "Link XSL" pentru partea web Vizualizare listă prin interfața de utilizator.
- Succes!
Să explorăm un exemplu de caz de utilizare și să parcurgem implementarea. Clientul nostru dorea o vizualizare a listei sale principale care să îi spună cât timp stă un anumit element de listă la starea sa. Această listă conținea un tip de conținut de site particularizat derivat din tipul de element și adăugat la listă. Exista deja un receptor de evenimente care capturează de fiecare dată când câmpul de stare din elementul de listă era modificat și salva data respectivă într-o coloană numită "Data modificării stării". Toate aceste cablări nu sunt necesare și se pot face cu ORICE câmp de dată (se întâmplă ca aceasta să fie implementarea noastră, dar nu ezitați să experimentați). Minimul necesar este câmpul dată sursă și câmpul substituent pentru a menține calculul (mai multe despre acest lucru în paragraful următor) adăugat la lista dvs., deși vă sugerez să utilizați coloanele de site și tipurile de conținut de site în cazul în care doriți să reutilizați această soluție în alte locuri de pe site-ul dvs.
Așadar, avem data sursă pe care o putem utiliza în calculele noastre în raport cu data de astăzi. Acum putem crea o coloană de site particularizată pe care să o utilizăm ca un container pentru valoarea noastră calculată. În acest caz, am ales să utilizez o coloană calculată, deoarece ea nu va putea fi modificată în formularele noi sau de editare a formularelor cu element, dar poate fi selectată pentru afișare în vizualizări, deoarece nu dorim ca utilizatorii să introducă valori arbitrare în această coloană. Motivul pentru care acesta nu se afișează în vizualizări etc. ar putea fi derutant.
Acum, că avem coloana de site, o putem adăuga la tipurile de conținut care vor fi utilizate în lista noastră. Apoi trebuie să creăm vizualizarea care va fi particularizată mai târziu cu XSLT. Asigurați-vă că creați o vizualizare standard care conține coloana sursă de date și noua coloană calculată, care va acționa ca substituent pentru valoarea calculată.
Acum avem tot ce ne trebuie pentru a accepta raportul nostru personalizat de îmbătrânire. Nu mai rămâne decât să creăm șablonul XSL, să-l încărcăm în Biblioteca de stiluri a site-ului și să-l legăm la vizualizarea listă. Șablonul XSL pe care îl vom utiliza va conține un marcaj normal generat de SharePoint pentru a genera vizualizarea, precum și propriul nostru marcaj particularizat utilizat pentru a înlocui anumite părți ale acestuia și a calcula valoarea dorită pentru noi.
Acordând credit acolo unde se cuvine, șabloanele XSL pentru a face calculele reale pe care le utilizez pentru această soluție au fost furnizate cu grație de "swirch" pe forumurile MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/
Descărcați foaia de stil XSL (aging.zip) pe care am alcătuit-o aici:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104
Deschizând acest lucru în editorul de text preferat, veți vedea o mulțime de marcaje normale SharePoint XSL pentru redarea vizualizărilor, dacă continuați să derulați în jos până la linia 357 veți vedea începutul șabloanelor personalizate pe care le-am adăugat la marcaj, primul fiind șablonul "DateDiff" urmat de "calculate-julian-day" și "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Acestea sunt cele trei șabloane ale noastre care vor efectua și afișa calculele noastre în vizualizările noastre. Dacă veți utiliza nume de câmp diferite de cele specificate anterior în acest articol, va trebui să parcurgeți aceste șabloane și să înlocuiți orice referințe la alte nume. Rețineți că pentru aceasta se recomandă să utilizați numele INTERN al câmpului, nu numele afișat.
După ce sunteți mulțumit că șablonul este gata de utilizare, navigați la Biblioteca de stiluri și încărcați-l sub folderul "XSL Style Sheets", apoi copiați linkul către fișier. Acest lucru ne va permite să-l modificăm cu ușurință mai târziu sau să-l adăugăm la diferite părți ale site-ului, după cum dorim.
Mai departe, accesați lista și selectați vizualizarea pe care ați creat-o anterior în acest articol. Din meniul "Acțiuni site", faceți clic pe "Editare pagină".
Găsiți partea web Vizualizare listă pe pagină și deschideți meniul Parte web făcând clic pe săgeata mică orientată în jos din colțul din dreapta sus. Din acest meniu, selectați "Editare parte web".
Se va deschide meniul părții web în partea dreaptă a ferestrei browserului.
Faceți clic pe + pentru secțiunea "Diverse" și găsiți proprietatea "Link XSL".
Lipiți linkul către fișierul XSL din Biblioteca de stiluri, pe care l-ați copiat mai devreme (acesta poate fi un link relativ sau absolut).
Faceți clic pe "OK" pentru a salva modificările, apoi faceți clic pe butonul "Oprire editare" de pe panglica "Pagină" din partea de sus a paginii.
Dacă totul a fost configurat corect, acum ar trebui să vedeți numerele în coloana "Zile în stare".
Și, în sfârșit, iată cum ar arăta cu unele date de test de diferite date:
Rezumat:
Iată-l: un mod bine formatat, robust și mai performant de a crea un raport vechi în SharePoint, cu o implementare simplă fără cod. Acest lucru are destul de multe aplicații potențiale în afară de cazul de utilizare pe care l-am explorat aici. Un alt scenariu obișnuit pentru acest tip de raport este atașarea sa unei liste de activități, astfel încât să vedeți dintr-o privire cât timp a trecut de când s-a creat o activitate.
Sperăm să vă placă!
--Iustin
Justin Joyce, LANtek
Comentarii
Pași lipsă
08.10.2012 03:51
ok am urmat pașii, dar trebuie să lipsească ceva - cum va ști XSL ce dată să utilizeze sau în ce câmp să adauge zilele de atunci? Urăsc când sunt ratați pași.
Fără cod, am fost de acord!
30.08.2012 12:12
Sunt de acord - nu cred că acest lucru contează cu adevărat ca "fără cod".
Interesant este că, printr-o greșeală de SharePoint, am o coloană calculată care funcționează folosind Astăzi... nu sunt sigur cum sau de ce, pentru că nu pot să-l fac să o facă din nou, dar cel este încă acolo și funcționează.
Formulă pentru coloana calculată "Zile în stare"?
02.05.2012 07:39
Iust - Care este formula pe care ați utilizat-o pentru coloana de site calculată "Zile în stare" (coloana substituent)? A fost "=today"?
SharePoint 2007
2.12.2011 11:29
Momentan nu am încercat să aplic această soluție la SharePoint 2007, însă mă interesează să o utilizez. Din păcate, nu există nicio proprietate XslLink care să apară pe partea web prin interfața de utilizator.
Postare grozavă
30.11.2011 09:53
Bună ziua,
Postare grozavă.
Utilizez SharePoint 2007.
Nu am o secțiune Diverse așa cum s-a menționat mai sus.
Aveți pași pentru o configurare SP2007?
Vă mulțumim.
Re: Soluție fără cod: Afișarea zilelor de la ultima modificare a unui element din lista SharePoint
11.10.2011 08:24
Bună ziua, Chris.
O găsire grozavă!
Voi arunca o privire la ceea ce ați postat sper mai târziu astăzi și voi vedea dacă pot face această soluție puțin mai robustă.
Mă bucur că v-a plăcut postarea și mă bucur foarte mult că ați reușit să găsiți o soluție la formatul european al datei. :)
-Iustin
Soluție pentru formatele de dată europene
11.10.2011 06:45
Bună din nou Justin,
FYI, am găsit o soluție pentru problema pe care am menționat-o anterior pe această pagină;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/
Formate de dată europene
07.10.2011 03:59
Bună ziua, Justin,
Aceasta este o soluție foarte bună, mulțumesc și exact genul de lucru pe care l-am căutat în ultimele două zile! Cu toate acestea, am o mică problemă cu asta și speram că mă puteți ajuta.
V-am modificat ușor codul pentru a calcula numărul de zile până când se întâmplă ceva, mai degrabă decât de atunci, prin schimbarea variabilelor din ultima linie a funcției "DateDiff";
<xsl:valoare-a select="$JulianToday - $JulianStartDate"></xsl:valoare-din>
Cu toate acestea, reușesc să-l fac să calculeze corect diferența doar jumătate din timp. Deci, de exemplu, cu această dată (format zz/LL/aaaa);
30/12/2011
Calculează corect, dar cu această dată (același format)
12/10/2011
Calculează ca și cum 10-Dec-2011 mai degrabă decât 12-Oct-2011.
Am încercat pur și simplu să schimb pozițiile valorilor de zi și lună în variabila "JulianStartDate", astfel;
<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)"/>
Și acest lucru a corectat problema cu a doua dată, dar a fost incorect pentru prima dată!
De asemenea, am încercat să modific apelurile FormatDateTime pentru a utiliza LCID-uri europene și diverse modificări la ultimul parametru al FormatDateTime (de exemplu, ddMMyyyy, MMddyyyy) cu ajustările corespunzătoare ale parametrilor poziționali subșirului fără succes.
Aș aprecia foarte mult orice sfat pe care îl puteți oferi.
Mulțumim,
Cornel
No-Code
21.09.2011 04:27
Nu cred că XSL se califică ca o soluție "fără cod", deoarece înțelegerea limbajului XSL nu este pentru toată lumea - totuși nu implică programare. Pe lângă asta: Soluție frumoasă, mulțumesc!