Поделиться через

Причины использовать SharePoint Framework

  • Статья

SharePoint был первоначально запущен как локальный продукт в 2001 году. Большое сообщество разработчиков значительно расширило его и повлияло на его развитие. Сообщество разработчиков использовало те же модели и методы, что и группа разработчиков SharePoint, в том числе веб-части и XML-элемент Feature. Многие функции были написаны как настройки на стороне сервера с помощью C#, скомпилированы в библиотеки DLL и развернуты в локальных фермах серверов.

Эта архитектура хорошо работала в средах с одним предприятием, но не подходила для облака, где несколько клиентов работают параллельно на одних серверах. В результате мы представили две альтернативные модели: клиентское внедрение JavaScript и надстройки SharePoint. У обоих этих решений есть как сильные, так и слабые стороны.

Внедрение JavaScript

Одна из наиболее популярных веб-частей в SharePoint Online — это редактор скриптов. Вы можете вставлять код JavaScript в веб-часть редактора скриптов, и он будет выполняться при отрисовке страницы. Это просто & эффективно. Он запускается в том же контексте браузера, что и страница, и использует ту же модель DOM, поэтому может взаимодействовать с другими элементами управления на странице. Он также относительно эффективный и простой в использовании.

У этого подхода есть несколько недостатков.

  • Вы можете упаковать решение так, чтобы пользователи смогли перетянуть элемент управления на страницу, но добавить настраиваемые параметры не так просто.
  • Конечный пользователь может нарушить работу веб-части, изменив страницу или скрипт.
  • Веб-часть "Редактор скриптов" не помечена как безопасная для скриптов. В большинстве семейств веб-сайтов самообслуживания (на личных сайтах и сайтах групп) включена функция NoScript. Она удаляет разрешение на добавление и настройку страниц (ACP) в SharePoint. Это означает, что выполнение веб-части "Редактор скриптов" будет блокироваться на этих сайтах.

Модель надстроек SharePoint

Для решений, которые работают на сайтах с NoScript, можно использовать модель надстройки/веб-части приложения, появившуюся в SharePoint Server 2013. Она создает окно iFrame, в которой выполняется функция. Так как она находится вне системы и не имеет доступа к текущей модели DOM и подключению, информационным работникам легче настроить доверие и развернуть ее. Конечные пользователи могут устанавливать надстройки на сайтах NoScript.

Но и у этого подхода есть несколько недостатков.

  • Надстройки запускаются в окнах iFrame. Окна iFrame медленнее веб-части "Редактор скриптов", так как отправляется запрос на другую страницу. Страница должна проходить полную проверку подлинности и авторизацию, самостоятельно вызывать службу для получения данных SharePoint, загружать различные библиотеки JavaScript и т. п. Веб-часть "Редактор скриптов" обычно загружается и отрисовывается за 100 миллисекунд, а веб-части приложения может потребоваться 2 секунды или больше.
  • Границы окна iFrame затрудняют создание адаптивных макетов и наследование информации о CSS и настройке темы. Окна iFrame имеют более высокий уровень безопасности, что может быть полезно как вам (ваша страница недоступна для других элементов управления на странице), так и пользователю (подключение к Microsoft 365 недоступно для элемента управления).

SharePoint Framework

Раньше разработчики создавали веб-части как сборки C# с полным доверием, устанавливаемые на облачных серверах.

Однако текущие модели разработки обычно включают JavaScript, работающий в браузере, который вызывает REST API к серверным рабочим нагрузкам SharePoint и Microsoft 365. Сборки C# устарели. Разработчикам нужна новая модель разработки.

Платформа SharePoint Framework — это следующий этап в разработке SharePoint.

См. также