Разработка для SharePoint. Как это было и как это будет
Как изменялся подход к разработке решений на базе Microsoft SharePoint, начиная с SharePoint 2003, и, заканчивая SharePoint 2013. Изначально я хотел написать пост о том, что такое FEATURE в SharePoint разработке, рассказав о разработке под SharePoint 2003, когда этого понятия даже не было. Но пока пост находился в стадии написания, вышел SharePoint 2013, и я решил описать процесс разработки под SharePoint с учетом этого факта.
Подобно тому факту, что все прелести технологии ASP.NET может почувствовать лишь тот, кто разрабатывал на классическом ASP, используя VBScript или JavaScript, я начну с SharePoint 2003 и закончу SharePoint 2013.
SharePoint 2003. XML, .NET и копи-паст
Разработка решений для SharePoint 2003 (WSS 2.0) сводилась к созданию расширения пользовательского интерфейса, т.е. написанию кастомных веб-частей. Сами веб-части упаковывались в cab-файл с расширением .dwp. Вся остальная кастомизация SharePoint 2003 проходила путем декларативного описания шаблонов списков, сайтов и прочего с помощью языка CAML (Collaborative Application Markup Language). Причиной тому было отсутствие единого механизма описания решений.
Зачем придумали Feature
Возвращаясь к FEATURE, я хотел бы привести список самых ужасных ограничений при отсутствии этого механизма разработки решений:
- Отсутствие каких-либо ресиверов (так как нет и самих фич). Чтобы удалить шаблон списка надо явно удалить XML-файл, в котором он описан. То есть такое решение развертывалось на портале путем простого копи-паста. И банальным удалением файла(ов) решение отзывалось;
- Невозможность разграничить область действия решений. Либо созданное вами доступно везде, либо недоступно нигде;
- Обновление использованных решений было невозможно. Если список был создан по вашему шаблону, то его (шаблона) модификация никак не влияла на уже созданные списки. Причина - отсутствие типов содержимого;
Таким образом разработка для SharePoint 2003 всегда сводилась к тому, что приходилось резать по живому раз и навсегда. Но этот ужас был не долговечен, к тому же мало организаций в то время были готовы к переносу бизнес-функционала на новую платформу. Тем не менее есть корпоративные порталы, которые нехитрым путем миграции прошли путь от SharePoint 2003 до SharePoint 2010. Этот факт надо учитывать при разработке для таких порталов.
Вот отрывок из SDK для SharePoint 2003, описывающий механизм создания списка:
You can create a list definition by modifying two files within a site definition: the SCHEMA.XML file that applies to the list, and the ONET.XML file that applies to the site as a whole.
SharePoint 2007. Начало эры Solutions
В SharePoint 2007 (MOSS 2007 или бесплатный WSS 3.0) впервые появились решения (solution), которые могли содержать различные компоненты (feature), что явилось первым шагом по упрощению создания расширений для SharePoint 2007. В дополнение к этому был выпущен SharePoint Designer, который позволял проводить модификации портала, не требуя разработческих навыков у пользователя.
С появлением фич (feature) стали доступны и различные ресиверы для выполнения необходимых действий при их установки/активации/деактивации/удаления. Также доступным стало ограничение области действия фич (feature scope):
- Сайт (Web) - минимальная из областей, предназначенная для развертывания решений на отдельном сайте (узле). Эта область может быть использована для развертывания шаблонов списков/библиотек (list template), их экземпляров (list instance), контролов (control), действий (custom action group, custom action). Причем ресиверы (receiver) можно разворачивать только на уровне сайта;
- Коллекция сайтов (Site) - следующая область действия, включающая в себя коллекцию сайтов предназначена для развертывания типов содержимого (content type), их привязки (content type binding), полей (field). Все расширения, описанные для области сайта, кроме ресиверов можно также развертывать на уровне коллекции сайтов.;
- Приложение (WebApplication) - область, включающая в себя веб-приложения и все коллекции сайтов на нём расположенные. Предназначение этой области - регистрация приложений-конвертеров документов. Помимо этого некоторые расширения можно "поднять" с уровня сайта и/или коллекции сайтов;
- Ферма (Farm) - область, включающая в себя веб-приложения (WebApplication).
И еще раз, но в виде таблицы:
| Web | Site | WebApplication | Farm | |
|---|---|---|---|---|
| Content Type | ✓ | |||
| Content Type Binding | ✓ | |||
| Control | ✓ | ✓ | ✓ | ✓ |
| Custom Action | ✓ | ✓ | ✓ | ✓ |
| Custom Action Group | ✓ | ✓ | ✓ | ✓ |
| Hide Custom Action | ✓ | ✓ | ✓ | ✓ |
| Document Converter | ✓ | |||
| Feature/Site Template Association | ✓ | ✓ | ✓ | |
| Field | ✓ | |||
| List Instance | ✓ | ✓ | ||
| List Template | ✓ | ✓ | ||
| Module | ✓ | ✓ | ||
| Receiver | ✓ | |||
| Workflow | ✓ |
SharePoint 2007 позволил создавать коробочные решения, распространять их и поддерживать без танцев с бубном, как это было в SharePoint 2003.
SharePoint 2010. Sandbox всему голова
Выход SharePoint 2010 не внес в разработку решений никаких радикальных изменений. Только теперь решения разделялись на две категории: решения уровня фермы (Farm Solution) и решения для песочницы (Sandbox Solution). Что касается решений уровня фермы - это те решения, которые разрабатывались для SharePoint 2007. В противовес им были поставлены решения для песочницы, которые исполнялись в изолированной среде (песочнице), к тому же использования пользовательских контролов и страниц было невозможно.
Предназначались sandbox-решения для использования в облачных решениях (Office 365). С этим связаны такие жесткие ограничения. К тому же их установка и развертывание выполнялись полностью с использованием интерфейса SharePoint. Решения уровня фермы же требовали установки на все сервера фермы и только затем можно их активировать и использовать.
Microsoft во время выхода на рынок SharePoint 2010 убеждала всех, что sandbox-решения - это будущее. Создавать их просто (спасибо инструментам Visual Studio 2010), распространять ещё проще. Но все эти обещания как-то поутихли с выходом SharePoint 15 SDK Preview, из которого стало понятно, что грядет очередной вид решений для SharePoint - приложения (SharePoint App). Не имея самого SharePoint 15 (позднее выяснилось, что называться он будет SharePoint 2013), а только кусок SDK, теплилась надежда, что наконец-то можно будет создавать решения и выкладывать их в AppStore, покоряя пользователей и зарабатывая на этом. Но все оказалось несколько иначе.
SharePoint 2013. Sandbox мертв, да здравствует Apps!
С выходом SharePoint 2013 появляется новый тип приложений - SharePoint App, который имеет ещё большие ограничения по сравнения с sandbox-решениями, появившимися в SharePoint 2010. Основа основ в SharePoint 2013 - клиентская модель и тот факт, что создавать SharePoint App можно хоть на PHP, хоть на Java (использование iframe'ов привнесло в SharePoint 2013 много нового). Строго говоря, писать можно только на JavaScript. Но если у вас есть веб-приложение, написанное на PHP, то портировать его на .NET-платформу не обязательно.
Даже стандартные списки и библиотеки теперь представлены в виде приложений, что не является правдой.
Если разработка решений на SharePoint 2007 требовала знаний CAML, объектной модели SharePoint и прочего, то разработка решений для SharePoint 2013 добавляет к этому еще и JavaScript.
Дизайн Apps
При разработке новых приложений для SharePoint подстроить внешний вид под корпоративный стандарт невозможно (т.к. мы не знаем где будет установлено приложение) и остается только надеяться, что он максимально приближен к стандартному, что бывает не так часто. Но в SharePoint 2013 проблема соответствия дизайна разработанных приложений и порталов, на которых эти приложения будут установлены, решена крайне просто. Нет дизайна - нет проблемы. Не так-то просто произвести брендинг квадратика (плитки).
Cross-domain
При установки новых приложений SharePoint создает для них отдельные узлы, доступ к которым организован через поддомен, адрес которого заранее неизвестен (да и сделали его таким, что запомнить его человеку не представляется возможным). Взаимодействие с таким приложением порождает кросс доменные запросы. В браузере это реализовано через iframe, который может быть как развернут на весь экран, так и свернут до размеров веб-части.
Серверный код
В SharePoint 2013 Apps серверный код может исполнятся где угодно (это может быть даже не .NET) за одним небольшим исключением: серверный код не может быть исполнен на том же сервере где установлено приложение.
Вот такой эволюционный путь за последние 10 лет прошла разработка SharePoint-решений. От CAML декларации до отказа от серверного кода. Мне с трудом представляется как можно портировать имеющиеся решения для использования их в качестве SharePoint App. Со всякими виджетами погоды и курсов валют все понятно, но вот что-то посложнее вряд ли выйдет.
