Решение без код: Показване на дните от последната промяна на елемент от списък

Общ преглед: Отчети за стареене по избор без код

Един от често исканите функционални части на сайт на SharePoint е отчет за остаряване за задачи или елементи от списък. С други думи, колко дни/месеца е изминал от последната промяна на този елемент от списък?

На повърхността това изглежда е много проста заявка. В края на краищата имаме дати за елементите, които се създават и модифицират, имаме възможност да съхраняваме дати по избор, когато определени промени в елементите се извършват чрез получатели на събития. Имаме изчисляеми колони, където можем да включим формули, подобни на excel, за да работим с нашата информация. Това изглежда като доста прямо предложение. Избираме поле за дата, създаваме изчисляема колона и след това правим формула нещо подобно на [DateField] – [Today]. Не толкова бързо! Както знае всеки, който е опитал тази "проста" задача, опитът да се използва нещо като [Today] в изчисляема колона създава проблеми. Опитайте да вмъкнете [Today] в полето за формула на изчисляемата колона и ще получите съобщение за грешка по следния начин:

Защо е това? Това е свързано с начина, по който се изчисляват изчисляемите колони.

Да вземем за пример проста формула:

= IF( [Колона1]<=[Колона2]; "OK"; "Не OK")

Всичко, което казва, е, че ако "колона1" е по-малко или равно на "колона2", тогава се показва OK, в противен случай се показва "Не OK". Това е доста типична основна формула за изчисляема колона и прави основно предположение за елемента от списъка, който съдържа тези колони: Стойностите за "Колона1" и "Колона2" никога няма да могат да се променят без събитие Update в елемента от списъка.

Точно така изчисляемите колони ще се преизчисляват само когато списъкът се актуализира (или създава), тъй като предполагат, че информацията, която изчислявате, се съдържа в самия елемент. Това създава проблем, когато се опитвате да използвате нещо, което се променя независимо от полетата на елемента, като например днешната дата.

Сега не бях на събранието, където решиха, че това е начинът, по който изчисляемите колони биха функционирали, но ако трябваше да направя образовано предположение, щях да предположа, че функционират по този начин за производителност. Представете си, ако имате списък с няколко хиляди елемента, всеки от които съдържа изчисляема колона, която се нуждае от "динамична" актуализация. Това би означавало, че някой механизъм, може би задание на таймера, ще трябва да извършва итерация през всеки елемент, който съдържа тази изчисляема колона толкова често, и да актуализира стойността й. Това може да бъде изключително данъчно облагане по отношение на производителността, тъй като при по-големи разполагания тази задача може непрекъснато да работи и да променя нещата. Това е моето предположение, но има логика, ако мислиш за това.

Има някои предложения за подобни решения, плаващи навън, които включват трикове на SharePoint за приемане на стойност "Днес", като първо създадете колона с име "Днес", след което я добавите към формулата, след което я изтриете. Всичко това е добре, но не забравяйте за какво казах, когато се актуализират изчисляеми колони. Тази стойност ще се промени само когато елементът бъде актуализиран, което означава, че вашите стойности скоро ще бъдат неправилни, особено в случай на изчисляване на деня.

Виждал съм други, които използват интелигентен JavaScript, за да напишат стойностите на страницата. Това ще работи и, но аз съм почти категорично против клиентския скрипт, когато може да бъде избегнат.

Изпълнение:

И така, какво да правим? Изчисляемите колони са извън въпроса за така наречените "непостоянни" функции като Today. Възможно е да можем да разработим някакъв потребителски код, за да се погрижим за това вместо нас, като например компютърна колона, задание за таймер или планиран процес, за да се създаде и актуализира всеки отделен елемент, който се нуждае от това изчисление. Това обаче ни връща към проблема с производителността, който споменах в последния абзац, и освен това е крехко решение, което ще бъде специфично за въпросния сайт/списък/колона. В началото на тези две притеснения, вие също ще трябва да отидете намери зубър човек, като мен, че знае как да кодирате и го убеди да разработи това решение за вас. Но има и по-лесен начин!

Ако имате права за създаване на полета и редактиране на страници във вашия сайт и имате малко познания за XSLT и създаването на изгледи, можете да съставите XSL шаблон, който може да бъде включен в списъчен изглед, и ще изчислявате вярно стойността си всеки път, когато страницата бъде поискана. Този сценарий премахва нашето опасение относно производителността и не изисква разработването и разполагането на потребителски код чрез решение.

Съвършен. Как ще го направим?

1. Създайте или изберете полето, което ще действа като наш източник. Това трябва да бъде тип дата.

2. Създайте нашето поле, което ще действа като контейнер за стойността, която се изчислява.

3. Добавете и двете полета към тип съдържание и добавете този тип съдържание към списък.

4. Създайте изглед на този списък, съдържащ колоните източник и контейнер.

5. Качете XSL шаблона в библиотеката със стилове.

6. Задайте свойството "XSL връзка" за уеб частта за списъчен изглед чрез потребителския интерфейс.

7. Успех!

Нека разгледаме примерен случай на използване и преминете през внедряването. Нашият клиент искаше преглед на основния му списък, който би му казал колко дълго определен елемент от списъка се е седял в състоянието си. Този списък съдържа тип съдържание на сайт по избор, извлечен от типа елемент и добавен към списъка. Вече е имало получател на събитие, който улавя всеки път, когато това поле за състояние в елемента от списъка е променено и записано тази дата в колона, наречена "Дата на промяна на състоянието". Цялата тази окабеляване не е задължителна и може да се направи с всяко поле за дата (това просто се случва това е нашата реализация, но не се колебайте да експериментирате). Необходимият минимум е вашето поле за дата източник и поле контейнер, за да задържите изчислението (повече за това в следващия абзац), добавено към вашия списък, въпреки че предлагам да използвате колони на сайт и типове съдържание на сайт, в случай че искате да използвате повторно това решение на други места във вашия сайт.

Така че имаме нашата дата на източника, която можем да използваме в изчислението си спрямо днешната дата. Сега можем да създадем колона на сайт по избор, която да се използва като контейнер за нашата изчисляема стойност. В този случай избрах да използвам изчисляема колона, тъй като тя няма да може да бъде променена във формулярите за нови или редактирани елементи, но може да бъде избрана за показване в изгледите, тъй като не искаме потребителите да въвеждат произволни стойности в тази колона. Може да бъде объркващо защо не се показва в изгледите и т.н.

Сега, след като вече имаме нашата колона на сайт, можем да я добавим към нашите типове съдържание, които ще се използват в нашия списък. След това трябва да създадем нашия изглед, който по-късно ще бъде персонализиран с нашия XSLT. Уверете се, че сте създали стандартен изглед, съдържащ колоната за дата източник и новата изчисляема колона, която ще действа като контейнер за изчисляемата стойност.

Сега разполагаме с всичко, което ще изискваме, за да поддържаме нашия персонализиран отчет за стареене. Всичко, което остава, е да създадем нашия XSL шаблон, да го качим в библиотеката със стилове на сайта и да го свържим с нашия списъчен изглед. XSL шаблонът, който ще използваме, ще съдържа нормални, генерирани от SharePoint коректури за генериране на изгледа, както и собствена коректура по избор, използвана за заместване на определени части от това и изчисляване на желаната от нас стойност вместо нас.

Даването на кредит на мястото, където е дължим кредит, шаблоните за XSL за извършване на действителните изчисления, които използвам за това решение, бяха предоставени любезно от "въртележката" във форумите на MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sharepointcustomization/thread/aeda905b-9bc6-40c4-bd22-21306c5cb0d2/

Изтегляне на XSL листа със стилове (aging.zip), който събрах тук:
https://OneDrive.live.com/?cid=c262e8e2d59a86d9&permissionsChanged=1&id=C262E8E2D59A86D9!104

Отваряйки това в любимия си текстов редактор, ще видите много нормална XSL коректура на SharePoint за рендиране на изгледите, ако продължите да превъртате надолу до ред 357, ще видите началото на шаблоните по избор, които добавих към коректурата, като първият е шаблонът "DateDiff", последван от "calculate-julian-day" и "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Това са нашите три шаблона, които ще направят и покажат нашите изчисления в нашите изгледи. Ако ще използвате различни имена на полета от зададените по-горе в тази статия, ще трябва да прегледате тези шаблони и да заместите всички препратки към другите имена. Не забравяйте, че за това ще искате да използвате вътрешното име на полето, а не показваното име.

След като сте доволни, че шаблонът е готов за работа, отидете до библиотеката със стилове и го качете под папката "XSL листове със стилове", след което копирайте връзката към файла. Това ще ни позволи лесно да извършваме промени в него по-късно или да го добавяме към различни части на сайта, както искаме.

След това отидете във вашия списък и изберете изгледа, който създадохте по-рано в тази статия. От менюто "Действия за сайта" щракнете върху "Редактиране на страница".

Намерете уеб частта за списъчен изглед на страницата и отворете менюто на уеб частта, като щракнете върху малката стрелка надолу в горния десен ъгъл. От това меню изберете "Редактиране на уеб част".

Това ще отвори менюто на уеб частта от дясната страна на прозореца на браузъра ви.

Щракнете върху + за секцията "Разни" и намерете свойството "XSL връзка".

Поставете връзката към вашия XSL файл във вашата библиотека със стилове, която сте копирали по-рано (това може да бъде относителна или абсолютна връзка).

Щракнете върху "OK", за да запишете промените, след което щракнете върху бутона "Спиране на редактирането" в лентата "Страница" в горния край на страницата.

Ако всичко е конфигурирано правилно, сега би трябвало да виждате числа в колоната "Дни в състоянието".

И накрая, ето как би изглеждало това с някои тестови данни от различни дати:

Обобщение:

Ето го: добре форматиран, стабилен и по-добре работещ начин за създаване на отчет за стареене в SharePoint. Пълен с опростена реализация без код. Това има доста няколко потенциални приложения освен един случай употреба ние разгледахме тук. Друг често използван сценарий за този тип отчет е прикачването му към списък със задачи, така че да можете да видите колко време е изминало, откакто е създадена задача с един поглед.

Наслаждавайте се!

--Джъстин

Джъстин Джойс, LANtek

Коментари

Липсват
стъпки 08.10.2012 г., 03:51 ч
. OK Аз последвах стъпките, но трябва да има нещо липсва - как XSL знае в коя дата, или кое поле да добавите дните след? мразят, когато стъпките са пропуснати.

Не е код, съгласен съм!
30.8.2012 г., 22:12 ч.
Съгласен съм - не мисля, че това наистина се брои като "няма код".
Интересното е, че чрез някои отрепка на SharePoint имам работеща изчисляема колона с помощта на "Днес"... не сте сигурни как или защо, защото не мога да го накарам да го направи отново, но този, който все още е там и работи.

Формула за изчисляема колона "Дни при състояние"?
02.5.2012 г., 07:39 ч
. Justin – Каква е формулата, която сте използвали за вашата изчисляема колона на сайт "Дни в състоянието" (колона контейнер)? "=today"?

SharePoint 2007
02.12.2011 г., 00:29 ч
. В момента не съм опитал да приложат това решение към SharePoint 2007, но все пак го търся. За съжаление, няма свойство XslLink, което да се показва в уеб частта чрез потребителския интерфейс.

Страхотна публикация
30.11.2011 г., 09:53 ч
. Здравейте
Страхотна публикация.
Използвам SharePoint 2007.
Нямам раздел "Други", както е отбелязано по-горе.
Имате ли стъпки за конфигуриране на SP2007?
Благодарим ви.

Re: Решение без код: Показване на дните от последната промяна
на елемент от списък на SharePoint 11.10.2011 г., 08:24 ч
. Здравейте, Крис.
страхотно намиране!
Ще погледна какво публикувахте по-късно днес по-късно и ще видя дали мога да направя това решение малко по-стабилно.
Радвам се, че харесахте публикацията и се радвам, че успяхте да намерите решение на европейския формат за дата.
:) -Джъстин

Решение за европейски формати за дата
11.10.2011 г., 06:45 ч.
Здравейте отново Джъстин,
За съжаление, намерих решение на проблема, за който споменах по-горе на тази страница;
https://sharepointbydummies.wordpress.com/2011/07/13/possible-work-around-to-date-format-issue-sharepoint-2010/

Европейски формати за дата
07.10.2011 г., 03:59 ч
. Здравейте, Джъстин,
Това е наистина добро решение, благодаря, и просто нещо, което прекарах последните два дни, търсейки! Въпреки това имам малко проблем с него и се надявах, че можете да ми помогнете.
Промених леко кода ви, за да изчислим броя дни, докато нещо се случи, а не след това чрез превключване на променливите в последния ред на функцията "DateDiff";

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

Въпреки това мога само да го накарам да различи правилно разликата през средата на времето. Така например с тази дата (формат дд/ММ/гггг);

12.30.2011

г. Изчислява се правилно, но с тази дата (същия формат)

10.12.2011

г. Изчислява се сякаш 10-дек-2011, а не 12-окт-2011.
Опитах просто да превключвам позициите на стойностите за деня и месеца в променливата "JulianStartDate", ето така;

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

И това коригира проблема с втората дата, но след това беше неправилен за първата дата!
Също така опитах да променя повикванията във FormatDateTime, за да използвам европейски LCIDs и различни промени на последния параметър на FormatDateTime (напр. ddMMyyyy, MMddyyy) с подходящи корекции на позиционните параметри на подниз без успех.
Ще съм ви благодарен за всеки съвет, който можете да предложите.
Благодаря
Крис

Без код
21.09.2011 г., 04:27 ч
. Не мисля, че XSL се определя като решение "без код", тъй като разбирането на XSL езика не е за всички – но не включва програмиране. Освен това: Хубаво решение, благодаря ви!