Site Pages vs Application Pages

Еще буквально полгода назад я почти не задумываясь создавал Application Pages под каждый чих и был этим вполне счастлив. А что, пользоваться ими просто и привычно: это суть обычные ASP.Net страницы с обычным CodeBehind, и любой ASP.Net-чик чувствует себя с ними как дома.

Однако сейчас, я почти все формы, и даже странички настроек, создаю на основе Site Pages. И этому есть очень серьезные причины.

Чтобы понять, как я к такому пришел, нужно понять, чем Site Pages отличаются от Application Pages.

Ну и чем же они отличаются?

Про Application Pages все всё прекрасно знают, – это чуть ли не первая фича, которой учат начинающих SharePoint-разработчиков. Про Site Pages люди знают гораздо меньше. В основном то, что Site Pages хостятся в БД, могут кастомизироваться пользователями, могут лежать в библиотеках документов, не имеют Code Behind. Часто смутно присутствует подозрение о вероятных проблемах с производительностью с Site Pages, т.к. мол они же в БД лежат, и не компилятся при первом обращении, как это делают обычные ASP.Net-страницы…

Во-первых, хочется развеять миф о проблемах с производительностью. Хорошо, возможно Site Pages в целом немного медленнее. Но вы сами подумайте, любой SharePoint портал на 90% состоит именно из Site Pages. На 90%!! Какой смысл избегать Site Pages в своих решениях, если всё равно “куда ни ткни, везде они”? :)

В остальном, различия между Site Pages и Application Pages неплохо описаны на MSDN, в статье SharePoint Page Types. И из этой статьи, а также из своего опыта, я хочу сказать, что потенциальные возможности Site Pages просто-таки зашкаливают… А у Application Pages, оказывается, есть некоторые довольно весомые ограничения!

Про веб-части и зоны веб-частей

Из упомянутой в предыдущем параграфе статьи SharePoint Page Types, я хочу обратить ваше особое внимание на следующую цитату про Application Pages:

They cannot, however, use dynamic Web Parts or Web Part zones or be modified using SharePoint Designer.

Это означает, что для Application Pages, использование динамических веб-частей и зон веб-частей не поддерживается! Т.е. даже несмотря на то, что формально можно добавлять и веб-части, и зоны веб-частей на Application Pages, их работоспособность не гарантируется.

Особенно это относится к стандартным веб-частям. Даже если их добавить на Application Page статически: они просто никогда не тестировались на работоспособность в окружении Application Pages. В частности, доподлинно известно, что в некоторых случаях XsltListViewWebPart начинает глючить, если её запихать на Application Page. Это на своей “шкуре” испытал Антон Вишняков :)

Я предпочитаю такие вот риски потенциальных багов жестко исключать. Опыт показывает: с багами внутри SharePoint бороться не нужно. Если вы видите явный баг – скорее всего вы просто используете тот или иной компонент SharePoint не так, как это было задумано. Разбирательство с такого рода внутренними багами SharePoint съедает кучу времени, и чаще всего в итоге решение получается неудачным.

А ведь использовать стандартные веб-части хочется, ой как хочется. Тот же Content Editor WebPart, прекрасно интегрированный в Ribbon, для меня намного предпочтительнее любого самопального контрола на базе TinyMCE или его аналогов. А DataFormWebPart (далее DFWP) и XsltListViewWebPart (далее XLV) – это ж вообще “рабочие лошадки” для вывода любых данных...

Резюмируя, мне кажется отсутствие поддержки зон веб-частей, динамических веб-частей и стандартных веб-частей на Application Pages является очень существенным ограничением этого типа страниц в SharePoint.

Про открытость пользователю

У Site Pages довольно много преимуществ. Значительную часть этих преимуществ можно описать как “открытость пользователю”, т.е. этот тип страниц прекрасно поддерживает взаимодействие с пользователями, и все эти механизмы стандартны – не нужно ничего писать.

Эти преимущества проще всего показать на примерах:

• Клиент захотел, чтобы разработанный вами модуль могли настраивать только определенные пользователи. Да нет проблем, смените разрешения у страницы настроек…
• Клиент захотел поменять инструкцию-подсказку на разработанной вами странице или форме. Добавить какое-нибудь важное замечание, специфичное именно для его компании. Нет проблем, переводим страницу в режим редактирования, а там лежит Content Editor WebPart с текстом…
• Клиент внедрил ваше решение на свой портал, а потом решил внедрить на портале корпоративный дизайн. Ваше решение его не удовлетворяет дизайном, но он не хочет платить вам за брендинг, потому что он уже нанял команду верстальщиков и дизайнеров, которая делает полный редизайн портала. Опять же, нет проблем, дизайнеры открывают SPD, и правят ваши страницы как их душе угодно. А если требуется, правят XSLT-шаблоны в тех же DFWP или XLV…
• Клиент захотел добавить на вашу форму еще одну вкладку с собственными данными и некоторыми действиями над ними. Причем, он хочет, чтобы его данные зависели от того, что отображает ваша часть решения… Опять же, нет проблем! Добавляем на страницу EasyTabs, его веб-часть, и линкуем его веб-часть к нашей через механизм WebPart Connections…

Самое интересное, что все эти возможности, относящиеся к открытости пользователю, можно регулировать, настраивать. Например, у любой зоны веб-частей можно указать, что она не кастомизируемая – в этом случае, её нельзя будет изменять через GUI. И т.д. Т.е. если вам нужны эти возможности – вы можете легко их задействовать. Если возможности не нужны, вы их можете безболезненно отключить.

Ах да, чуть не забыл, даже если пользователь что-то не то натворил с вашей страницей, он сам может это исправить. Достаточно в SPD перейти к файлу страницы и в контекстном меню тыкнуть “Reset to site definition”…

Про SharePoint Designer

Кстати про SPD! Возможность работы с site pages через SPD – это тоже очень важный пунктик.

Во-первых, поскольку SPD может подключаться к удаленным порталам, вы получаете возможность кастомизировать решение клиента, и при этом клиент может не опасаться, что вы вдруг утащите важные файлы, которые у него лежат на том же сервере, на котором и портал…

Во-вторых, SPD позволяет очень быстро отлаживать ваши файлы, меняя их на лету, без перекомпиляции/переразвертывания решения. Он сохраняет файлы даже быстрее, чем это делает CKS:Dev для Application Pages, при установке галочки “Copy to SharePoint Root on save”.

Про Sandbox и Office365

Также к плюсам Site Pages хочется добавить тот факт, что Site pages работают в Sandbox и Office365 – в отличие от Application Pages. И даже если вы создаете on-premise решение, если вы его изначально создаете на основе site pages, то конвертнуть в Sandbox будет потом значительно легче, если это вдруг понадобится.

Про SPFile

У SPFile, которым собственно представляется страница веб-частей в SharePoint, много разных методов и свойств.

Есть средства для организации совместного доступа/редактирования страниц веб-частей, версионность, Content Approval…

Есть некоторые экзотические возможности, как например можно автоматически получить, какие файлы ссылаются на нашу страницу (SPFile.BackwardLinks), и на какие файлы ссылается наша страница (SPFile.ForwardLinks). Конечно, эта возможность едва ли часто используемая, но например, её можно задействовать, чтобы вывести предупреждение о том, что на странице обнаружены битые ссылки.

Также, у SPFile есть свойство Properties, где можно хранить любые метаданные, относящиеся к странице. Удобно!

Про мышление

Завершающим пунктом, хочется отметить, что когда есть стремление делать всё на Site Pages, меняется даже мышление. Вместо того, чтобы писать кучу Code Behind, автоматически стараешься по максимуму использовать существующие контролы и веб-части.

Например, вместо того, чтобы писать в Page_Load что-нибудь типа

if (SPContext.Current.Web.CurrentUser.IsSiteAdmin) 
    myControl.Visible = true;

, просто обертываешь myControl в SPSecurityTrimmedControl и указываешь нужные привилегии.

Например, вместо сложной логики по скрытию/показу контролов в зависимости от значений других контролов, просто соединяешь несколько веб-частей с помощью WebPart Connections.

Например, при необходимости отобразить данные, вместо DataBound-репитеров или какого-нибудь SPGridView, используешь XLV или DFWP, часто опять же слинкованные через WebPart Connections.

Примеров много, но факт остается фактом:

1. Как правило, накидать на страницу несколько веб-частей, соединить их через WebPart Connections, накидать пару контролов и прописать ParameterBindings – это получается гораздо быстрее, чем писать всё то же самое стандартными методами ASP.Net.


2. Решения становятся более простыми, более кастомизируемыми, более открытыми пользователю. Даже если эти преимущества всплывают не сразу, рано или поздно они всё равно всплывают.

Итого

На самом деле, выше представлен даже не полный список . Например, можно упомянуть про Ribbon, и про то, как сложно было бы создать риббон на Application Page, если бы не было Fluent Ribbon'а :) Ну и т.д.

Вот и думайте, неужели крайне сомнительный пункт про производительность может затемнить такое количество потенциальных возможностей Site Pages? Я думаю, нет. Поэтому, за последние полгода я не написал ни одной Application Page, и в будущем планирую писать их чем реже, тем лучше. Чего и вам советую!