Создание нового типа поля для MS SharePoint на примере простого проверяемого поля

[@ZOXEXIVO]

Испытал радость, что когда-то я не выбрал путь Sharepoint.

[@justmara]

эта радость ничто по сравнению с воспоминаниями тех, кто пощупал, но соскочил.

[@gandjustas]

Зачем было создавать новый тип поля, если тоже самое можно сделать, просто поменяв шаблоны для вывода? Для серверной валидации можно event receiver сделать. Кода будет в разы меньше, деплоить проще, результат лучше.

[@BOBS13]

Ну как минимум для шаблонов ввода есть проблема, если его применить, программное создание элемента падает. А ресивер не подошел потому что, хотелось что пользователь сразу видел, что произошло сразу берез передачи на сервер, и на самом деле уже в продакшине у этого поле используется маска ввода.

[@gandjustas]

Вы про какие шаблоны? Я говорю про шаблоны для CSR. Каким образом что-то падает? Ресивер дополняет клиентскую валидацию.
Зачем вам сusom field type? Я очень сомневаюсь что пользователи ходят и создают новые поля. А для частного решения можно и менее тяжелый способ применить.

[@BOBS13]

Во-первых полей около десятка. Тыкают не пользователи, а внедренцы — это совсем другие люди. А внедренцу намного проще создать новое поле, и задать ему шаблон. чем всякой другой ересью заниматься, тем более еще ресивер вешать. Это не маленькое решение для одиночной задачи, а тиражное решение. Тут уже совсем другие приоритеты.

[@gandjustas]

Для тиражируемого решения кастомные типы полей — слишком проблемная штука. Не поддерживаются в REST, плохо работают в CSOM, поиске и workflow (вам повезло, у вас просто текстовое поле — проблем меньше). Обновление типов полей требует рестарта IIS и, самое главное, это не работает в Office 365.

Я бы сделал по-другому:
1) Обычные текстовые поля
2) Дополнительная ссылка в настройках поля для валидации
3) На странице настраивается regexp для поля и сохраняет данные в свойствах (property bag) и в файл, который подключается в JSLink
4) JS с валидатором, подключается через Custom Action, а скрипт сохраненный в 3 дергает класс валидатора для CSR
5) Эвентресивер cо scope=«Site» (срабатывает на всех списках) проверяет метаданные поля и выполняет нужную валидацию.
Кода на выходе будет примерно столько же, но не будет всех проблем кастом-типов-полей.

[@BOBS13]

1) Поддержка SharePoint Online не нужна.
2) Новых типов полей в нашем решении уже больше 10-ка, каких-там только нет. Особо больших проблем в поиске не было. Тем более решение должно работать в режиме реального времени и использование систем поиска не очень удобно.
3) Вы предлагаете при каждом сохранении элементов проверять их метаданные, зачем, если это нужно в основном только в справочных списках. Это лишняя нагрузка и она не к чему.
Мое мнение вариант с типом поля намного проще и логичнее.

[@gandjustas]

1) Поддержка SharePoint Online не нужна.

А вы готовы поставить $10000, что поддержка облака не понадобится в течение 3 лет?

2) Новых типов полей в нашем решении уже больше 10-ка, каких-там только нет. Особо больших проблем в поиске не было.

Вы просто не знаете о них ;) И вам очень везет если заказчик не знает.

Тем более решение должно работать в режиме реального времени и использование систем поиска не очень удобно.

ИНН и реальное время? Вы о чем? Я же прекрасно знаю что за системы вы делаете, реальное время там не нужно от слова вообще.

3) Вы предлагаете при каждом сохранении элементов проверять их метаданные, зачем, если это нужно в основном только в справочных списках. Это лишняя нагрузка и она не к чему.

При желании можно только на выбранных списках включать, если вас это так беспокоит. Эвент-ресивер нужен только для защиты от хакеров, которые воспользуются API для заведения значений. Для пользователей все что нужно — валидатор на клиенте. Можно даже шаблон рендеринга не копипастить, а прицепить валидатор к стандартному шаблону.

Мое мнение вариант с типом поля намного проще и логичнее.

Это только ваше мнение. Тем не менее типы полей несут огромное количество недостатков.

[@BOBS13]

Пока sharepoint online, предлагает, что он предлагает. Использовать его все равно не получится, слишком малый уровень возможности кастомизации.
Режим реального времени это у задача другая, и не вохможность использования в системе стандартных методов поиска отсюда и вытекает. Все недостатки понятны, я пытаюсь только сказать, что для конкретной ситуации этот выход вполне предпочтителен. Тем более в статье, основной упор делается на то как сделать новый тип поля.

[@gandjustas]

Пока sharepoint online, предлагает, что он предлагает. Использовать его все равно не получится, слишком малый уровень возможности кастомизации.

99% того, что можно сделать в наземном шарике можно сделать и в облачном. Только другими средствами. Я вам и предлагаю использовать другие средства.

ЗЫ. Вы НЕ попадаете в оставшийся 1% со своими задачами.