Как стать автором
Обновить

Комментарии 11

Испытал радость, что когда-то я не выбрал путь Sharepoint.
эта радость ничто по сравнению с воспоминаниями тех, кто пощупал, но соскочил.
Зачем было создавать новый тип поля, если тоже самое можно сделать, просто поменяв шаблоны для вывода? Для серверной валидации можно event receiver сделать. Кода будет в разы меньше, деплоить проще, результат лучше.
Ну как минимум для шаблонов ввода есть проблема, если его применить, программное создание элемента падает. А ресивер не подошел потому что, хотелось что пользователь сразу видел, что произошло сразу берез передачи на сервер, и на самом деле уже в продакшине у этого поле используется маска ввода.
Вы про какие шаблоны? Я говорю про шаблоны для CSR. Каким образом что-то падает? Ресивер дополняет клиентскую валидацию.
Зачем вам сusom field type? Я очень сомневаюсь что пользователи ходят и создают новые поля. А для частного решения можно и менее тяжелый способ применить.
Во-первых полей около десятка. Тыкают не пользователи, а внедренцы — это совсем другие люди. А внедренцу намного проще создать новое поле, и задать ему шаблон. чем всякой другой ересью заниматься, тем более еще ресивер вешать. Это не маленькое решение для одиночной задачи, а тиражное решение. Тут уже совсем другие приоритеты.
Для тиражируемого решения кастомные типы полей — слишком проблемная штука. Не поддерживаются в REST, плохо работают в CSOM, поиске и workflow (вам повезло, у вас просто текстовое поле — проблем меньше). Обновление типов полей требует рестарта IIS и, самое главное, это не работает в Office 365.

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

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

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

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

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

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

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

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

ЗЫ. Вы НЕ попадаете в оставшийся 1% со своими задачами.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории