Розробка для SharePoint

Як змінювався підхід до розробки рішень на базі Microsoft SharePoint, починаючи з SharePoint 2003 і закінчуючи SharePoint 2013. Спочатку я хотів написати пост про те, що таке FEATURE в SharePoint розробці, розповівши про розробку під SharePoint 2003, коли цього поняття навіть не було . Але поки що пост перебував у стадії написання, вийшов SharePoint 2013, і я вирішив описати процес розробки під SharePoint з урахуванням цього факту.

2003

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, що описує механізм створення списку: Ви можете створити послідовність definition шляхом редагування двох файлів без усієї definition: SCHEMA. 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).