Рішення без використання коду: відображення днів із моменту останнього змінення елемента списку

Джастін Джойс, LANtek

Огляд: спеціальні звіти про старіння без коду

Один із функціональних компонентів сайту SharePoint, про який часто запитують, – це звіт про старіння для завдань або елементів списку. Іншими словами, скільки днів або місяців минуло з моменту останнього змінення цього елемента списку?

На перший погляд це здається дуже простим запитом. Адже у нас є дати для елементів, що створюються і змінюються, у нас є можливість зберігати кастомні дати, коли певні зміни в елементах відбуваються через одержувачів подій. У нас є обчислювані стовпці, куди можна включити формули, подібні до Excel, щоб працювати з нашою інформацією. Це здається досить простою пропозицією. Ми вибираємо поле дати, створюємо обчислюваний стовпець, а потім робимо формулу на кшталт [Поле_дати] – [Сьогодні]. Ах, не так швидко! Кожен, хто намагався виконати це "просте" завдання, знає, що спроба використати щось на зразок [Сьогодні] в обчислюваному стовпці спричиняє проблеми. Якщо спробувати вставити [Сьогодні] в поле формули обчислюваного стовпця, відобразиться повідомлення про помилку приблизно такого змісту:

Чому це так? Це пов'язано зі способом обчислення обчислюваних стовпців.

Візьмемо для прикладу просту формулу:

= IF( [Стовпець1]<=[Стовпець2];"OK";"Не OK")

Це говорить лише про те, що якщо Стовпець1 менше Стовпця2 або дорівнює йому, то відображатиметься OK, в іншому разі відображатиметься Не OK. Це досить типова базова формула для обчислюваного стовпця, яка дає змогу зробити загальне припущення щодо елемента списку, що містить стовпці: Значення для Стовпця1 і Стовпця2 ніколи не зможуть змінитися без події оновлення елемента списку.

Саме так, обчислювані стовпці переобчислюватимуть лише тоді, коли список оновлюватиметься (або створюватиметься), оскільки для цього припускається, що обчислювані відомості містяться в самому елементі. Це створює проблеми, коли ви намагаєтеся використати щось, що змінюється незалежно від полів елемента, наприклад сьогоднішня дата.

Я не був на нараді, де вони вирішили, що саме так функціонуватимуть обчислювані стовпці, однак, якби мені довелося зробити обґрунтоване припущення, я б припустив, що вони функціонують таким чином для продуктивності. Уявіть, що у вас є список із кількох тисяч елементів, кожен із яких містить обчислюваний стовпець, який потребує «живого» оновлення. Це означало б, що якийсь механізм, можливо, завдання таймера, повинен був би час від часу перебирати кожен елемент, який містив цей обчислюваний стовпець, і оновлювати його значення. Це може бути надзвичайно обтяжливо з точки зору продуктивності, оскільки з більшими розгортаннями ця робота може постійно виконуватися та змінювати ситуацію. Це лише моє припущення, але це має досить багато сенсу, якщо подумати.

Існує кілька пропозицій щодо подібних рішень, зокрема обманом змусити SharePoint прийняти значення "Сьогодні", спочатку створивши стовпець "Сьогодні", потім додавши його до формули, а потім видаливши. Все це добре і добре, але пам'ятайте, що я говорив про те, що я говорив при оновленні обчислюваних стовпців. Це значення зміниться лише після оновлення елемента, а це означає, що незабаром значення будуть неправильними, особливо якщо використовуються дні обчислення.

Я бачив, як інші використовували розумний JavaScript для запису значень на сторінку. Це також спрацювало б, але я категорично проти клієнтського скрипту, коли його можна уникнути.

Реалізація:

Так що ж робити? Про обчислювані стовпці не може бути й мови для так званих "мінливих" функцій, таких як "Сьогодні". Цілком можливо, що ми могли б розробити якийсь спеціальний код, який би подбав про це для нас, як-от обчислюваний стовпець, завдання таймера або запланований процес, щоб з'явитися та оновити кожен окремий елемент, який потребує цього обчислення. Це повертає нас до проблеми продуктивності, про яку я згадував у попередньому абзаці, і, крім того, це крихке рішення, яке було б дуже специфічним для сайту/списку/стовпця, про який йде мова. На додачу до цих двох проблем, вам також доведеться знайти хлопця-ботаніка, такого як я, який знає, як кодувати, і переконати його розробити це рішення для вас. Але є і простіший спосіб!

Якщо у вас є права на створення полів і редагування сторінок на сайті, а також певні знання про XSLT і створення подань, можна створити XSL-шаблон, який можна включити до подання списку й який точно обчислюватиме значення щоразу, коли запитується сторінка. Цей сценарій усуває наше занепокоєння щодо продуктивності та не вимагає розробки спеціального коду за допомогою рішення.

Чудово! Як же це зробити?

1. Створіть або виберіть поле, яке буде виступати в якості нашого джерела. Це має бути тип дати.
2. Створюємо наше поле, яке буде виконувати роль покажчика місця заповнення для значення, що обчислюється.
3. Додайте обидва ці поля до типу вмісту, а потім цей тип вмісту додайте до списку.
4. Створіть подання цього списку, що міститиме вихідні стовпці та стовпці покажчика місця заповнення.
5. Передайте XSL-шаблон до бібліотеки стилів.
6. Установіть властивість "XSL-посилання" для веб-частини подання списку через інтерфейс користувача.
7. Успішно завершено!

Розгляньмо приклад сценарію використання та покрокові вказівки щодо реалізації. Наш клієнт хотів отримати вигляд основного списку, у якому можна було б дізнатися, як довго певний елемент перебуває у своєму стані. Цей список містив настроюваний тип вмісту сайту, отриманий на основі типу "Елемент" і доданий до списку. Вже існував одержувач подій, який записував усі випадки змінення поля стану в елементі списку та зберігав цю дату в стовпці "Дата змінення стану зміни". Вся ця проводка не потрібна, і може бути виконана з БУДЬ-ЯКИМ полем дати (так вже вийшло, що це наша реалізація, але не соромтеся експериментувати). Мінімум, що вам знадобиться, це поле вихідної дати та поле покажчика місця заповнення, щоб виконати обчислення (докладніше про це в наступному параграфі), доданому до вашого списку, хоча я пропоную вам використовувати стовпці сайту та типи вмісту сайту на випадок, якщо ви захочете повторно використовувати це рішення в інших місцях вашого сайту.

Отже, у нас є вихідна дата, яку ми можемо використовувати в наших обчисленнях із сьогоднішньою датою. Тепер можна створити настроюваний стовпець сайту, який використовуватиметься як контейнер для обчислюваного значення. У цьому випадку я вибрав обчислюваний стовпець, оскільки його не можна змінювати у формах створення або редагування елементів, але його можна вибрати для відображення в поданнях, оскільки ми не хочемо, щоб користувачі вводили довільні значення в цей стовпець. Це може збити з пантелику, чому він не відображається в поданнях тощо.

Тепер, коли у нас є стовпець сайту, ми можемо додати його до наших типів вмісту, які будуть використовуватися в нашому списку. Далі нам потрібно створити наше представлення, яке в подальшому буде налаштовано за допомогою нашого XSLT. Переконайтеся, що ви створили стандартне подання з вихідним стовпцем дати та новим обчислюваним стовпцем, який виконуватиме роль покажчика місця заповнення для обчислюваного значення.

Тепер у нас є все необхідне для підтримки нашого спеціального звіту про старіння. Залишилося лише створити наш XSL-шаблон, завантажити його в бібліотеку стилів сайту та зв'язати його з нашим поданням списку. Шаблон XSL, який ми будемо використовувати, міститиме звичайну розмітку, створену SharePoint, для створення подання, а також нашу власну настроювану розмітку, яка використовується, щоб перевизначити певні частини цього коду та обчислити бажане значення.

Віддаючи належне там, де потрібно віддати належне, шаблони XSL для виконання фактичних обчислень, які я використовую для цього рішення, були люб'язно надані "swirch" на форумах 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

Відкривши це у вашому улюбленому текстовому редакторі, ви побачите багато звичайної розмітки SharePoint XSL для рендерингу подань, якщо ви продовжите прокручувати вниз до рядка 357, ви побачите початок користувацьких шаблонів, які я додав до розмітки, першим з яких є шаблон "DateDiff", за яким слідують "calculate-julian-day" та "FieldRef_printTableCell_EcbAllowed.Days_x0020_At_x0020_Status". Нижче наведено три шаблони, які створюватимуть і відображатимуть наші обчислення в поданнях. Якщо ви збираєтеся використовувати імена полів, відмінні від тих, що були вказані вище в цій статті, вам потрібно буде проаналізувати ці шаблони та замінити всі посилання на інші імена. Пам'ятайте, що для цього потрібно використовувати внутрішнє ім'я поля, а не коротке ім'я.

Коли ви будете впевнені, що шаблон готовий до використання, перейдіть до бібліотеки стилів, завантажте його в папку "Списки стилів XSL", а потім скопіюйте посилання на файл вниз. Це дозволить нам легко вносити в нього зміни пізніше або додавати його в різні частини сайту на свій розсуд.

Після цього перейдіть до списку та виберіть подання, створене раніше в цій статті. У меню «Дії сайту» натисніть «Редагувати сторінку».

Знайдіть свою веб-частину подання списку на сторінці та відкрийте меню, клацнувши маленьку стрілку вниз у верхньому правому куті. У цьому меню виберіть "Змінити веб-частину".

Відкриється меню веб-частини праворуч у вікні браузера.

Клацніть знак "+" для розділу "Різне" та знайдіть властивість "Посилання XSL".

Вставте посилання на XSL-файл у бібліотеці стилів, скопійований раніше (це може бути відносне або абсолютне посилання).

Натисніть «OK», щоб зберегти зміни, а потім натисніть кнопку «Зупинити редагування» на стрічці «Сторінка» у верхній частині сторінки.

Якщо все налаштовано правильно, у стовпці "Дні в статусі" відображатимуться числа.

І, нарешті, ось як це виглядатиме з деякими тестовими даними різних дат:

Зведення.

Ось він: гарно відформатований, надійний і ефективніший спосіб створення звіту про старіння в SharePoint із простою реалізацією без написання коду. Це має досить багато потенційних застосувань, окрім одного випадку використання, який ми тут розглянули. Інший поширений сценарій такого типу – вкладення звіту в список завдань, щоб швидко переглянути, скільки часу минуло з моменту створення завдання.

Приємного користування!

--Джастін

Джастін Джойс, LANtek

Примітки

Пропущені кроки
08.10.2012 в 03:51
Гаразд, я виконав кроки, але, мабуть, чогось не вистачає - як XSL знатиме, яку дату використовувати, або в яке поле додавати дні з того часу? Ненавиджу, коли пропущені кроки.

No-Code, згоден!
30.08.2012 12:12
Я згоден - я не думаю, що це дійсно вважається "без коду".
Цікаво, що через якусь помилку SharePoint у мене є робочий обчислюваний стовпець, який використовує Today... не знаю, як і чому, тому що я не можу змусити його зробити це знову, але він все ще існує і працює.

Формула для обчислюваного стовпця "Дні за станом"?
02.05.2012 р. 07:39
Джастін. Яку формулу використано для обчислюваного стовпця сайту "Дні в стані" (стовпець покажчика місця заповнення)? Це було "=сьогодні"?

SharePoint 2007
02.12.2011 р. 11:29
Зараз я не намагався застосувати це рішення до SharePoint 2007, проте я його розглядаю. На жаль, у веб-частині інтерфейсу немає властивості XslLink.

Чудовий пост
30.11.2011 р. 09:53
Вітаємо,
Чудовий пост.
Я використовую SharePoint 2007.
У мене немає розділу "Різне", як зазначено вище.
Чи є у вас вказівки щодо конфігурації пакета SP2007?
Дякуємо.

Re: No-code рішення: відображення днів із моменту останнього змінення елемента списку SharePoint
10/11/2011 8:24 AM
Привіт, Кріс.
Чудова знахідка!
Я збираюся поглянути на те, що ви, сподіваюся, опублікували пізніше сьогодні, і подивлюся, чи зможу я зробити це рішення трохи надійнішим.
Я радий, що вам сподобалася публікація, і я дуже радий, що ви змогли знайти рішення європейського формату дати. :)
-Джастін

Рішення для європейських форматів дат
10/11/2011 6:45 AM
Ще раз привіт, Джастіне!
До відома, я знайшов рішення проблеми, про яку я згадував раніше на цій сторінці;
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>

Однак я можу змусити його правильно пояснити різницю лише в половині випадків. Так, наприклад, з цією датою (формат дд/мм/рррр);

30/12/2011

Обчислення виконується правильно, але з цією датою (у тому ж форматі)

12/10/2011

Він обчислюється як 10 грудня 2011 р., а не 12 жовтня 2011 р.
Я спробував просто поміняти місцями позиції значень дня та місяця у змінній "JulianStartDate", ось так;

<xsl:with-param name="Місяць" 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 для використання європейських LCID та різні зміни останнього параметра FormatDateTime (наприклад, ddMMyyyy, MMddyyyy) з відповідними коригуваннями позиційних параметрів підрядка, але безуспішно.
Буду дуже вдячний за будь-яку пораду, яку ви можете дати.
З повагою,
Кріс

No-Code
21.09.2011 в 04:27
Я не думаю, що XSL можна вважати "no-code" рішенням, оскільки розуміння мови XSL підходить не всім, однак це не передбачає програмування. Крім того: гарне рішення, дякую!