среда, 27 июня 2012 г.

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, и в будущем планирую писать их чем реже, тем лучше. Чего и вам советую!

12 комментариев:

  1. Layouts страницы для настроек, Site Pages для контента. Как может быть одно лучше другого - не понятно. Они используются для разных целей. Layouts страницы общие для всей фермы и не должны кастомизироваться пользователем. Если Lauouts страница относится к листу, то ты и выставляешь при ее разработке доступ который должен иметь пользователь к листу, а не то что вздумается кастомеру.

    ОтветитьУдалить
    Ответы
    1. статья была слишком много букав чтоли, не осилил? :)

      Удалить
    2. В том то и дело что читал :)

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

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

      3) Вот и думайте, неужели крайне сомнительный пункт про производительность может затемнить такое количество потенциальных возможностей Site Pages?

      Вы кричите что Site Pages лучше, а тут нет того кто лучше, а каждое предназначено для своего.

      Удалить
    3. Если вы действительно читали статью, и читали полностью и внимательно, значит я её плохо написал. Попробую акцентировать основные моменты, хотя это и повторение того что написано выше, но другими словами..

      Я считаю, что нет, или почти нет таких кейсов, где Application Pages оправданы. Любая страница - это прежде всего страница. Страница - это интерфейс для пользователя. Админы это тоже пользователи, по большому счету. А Site Pages, как ни крути, лучше ориентированы на пользователей.

      Если вы не хотите давать кастомизировать страницу, можно запретить кастомизацию в Site Pages легко. Если вы хотите чтобы Site Page был доступен по всей ферме - да он в общем-то и так доступен, если есть Site Page, у него всегда есть URL. Да, ему придется передавать что-нибудь типа SPWeb.Url, если нужен контекст, но это решается элементарно.

      Фишка же Site Pages в том, что у них гораздо больший потенциал. Нет требований, которые не меняются. И никогда не будет. Сегодня клиенты хотят одно, а завтра другое. Поэтому потенциал решения важен. Application Pages - это просто страница. Любое новое требование придется писать. На Site Page, есть вероятность что придется просто включить какую-то опцию и вуаля, готово. Такие случаи бывают, честно. И нередко.

      И админ - это тоже важный человек. Если его не удовлетворить в плане интерфейса, он тоже может обидеться и начать ныть по всяким пустякам, филонить и т.д. Админам ведь тоже нравятся хорошие красивые интерфейсы, и все админы - это тоже люди, которые лазают в интернет и легко отличают хорошую страницу от "гогна".

      Кроме того, благодаря тому, что для SitePage есть стандартные веб-части, получается что чаще всего Site Page создается быстрее (конечно, для этого нужно хорошо знать SharePoint и возможности стандартных веб-частей). Чаще всего Site Page лепится из почти готовых блоков, и этих блоков доступно намного больше чем в Application Pages, т.к. можно использовать веб-части, и эти веб-части не будут глючить.

      Итого: Site Pages имеют намного больший потенциал, чем Application Pages. Потенциал можно не использовать, но он есть. Он никому не мешает, просто сидит и ждет своего часа. К тому же, Site Pages часто бывает создавать быстрее.

      Удалить
  2. Полностью согласен с Dev4U. У данных типов страниц абсолютно разное предназначение.

    "Про Site Pages люди знают гораздо меньше. В основном то, что Site Pages хостятся в БД, могут кастомизироваться пользователями, могут лежать в библиотеках документов, не имеют Code Behind. "
    Ну здрасьте, приехали. А как же ghosting/unghosting?

    "просто обертываешь myControl в SPSecurityTrimmedControl и указываешь нужные привилегии."
    что мешает делать также в application pages?

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

    "Я считаю, что нет, или почти нет таких кейсов, где Application Pages оправданы. "
    Хм, а если конфигурационная страница должна быть в central administration? Будем деплоить её и веб части туда?

    "Клиент захотел, чтобы разработанный вами модуль могли настраивать только определенные пользователи. Да нет проблем, смените разрешения у страницы настроек…"
    Супер! Проблемы начнутся когда нерадивый админ или какой-нибудь "шутник" добавит веб часть, созданную для конфигурационной site page, на другую страницу, как вариант доступную всем. Вот будет потеха :) Проверять пермишены в самой веб части? Простите, но это можно делать и в application page.

    "Если вы хотите чтобы Site Page был доступен по всей ферме - да он в общем-то и так доступен, если есть Site Page, у него всегда есть URL. Да, ему придется передавать что-нибудь типа SPWeb.Url, если нужен контекст, но это решается элементарно."
    Угу, а с пермишенами проблем не будет? Вы можете гарантировать, что у юзера А с веб приложения A будут права на веб приложение Б? Да что там права - что делать, если веб приложения использует разные схемы аутентификации, например на одном из приложений forms based auth?

    ОтветитьУдалить
    Ответы
    1. Alex Gr, Central Administration - это такой же сайт, как и все остальные. Там точно также полно Site Pages. Например, страница управления веб-приложениями - это Site Page. Как и многие другие.

      "просто обертываешь myControl в SPSecurityTrimmedControl и указываешь нужные привилегии."
      что мешает делать также в application pages?

      Насчет SPSecurityTrimmedControl - никто не мешает, но на практике все пишут иначе. С точки зрения ASP.Net-чика проще проверить права в коде, что он и делает. Да, ASP.Net-чиков работает с SharePoint очень много, и многие из них не желают понимать, что SharePoint это не ASP.Net, и более эффективные решения под SharePoint получаются как раз тогда, когда от методов ASP.Net отказываешься и начинаешь делать по-шарепойнтовски.

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

      Проблемы начнутся когда нерадивый админ или какой-нибудь "шутник"...
      Если такой админ или какой-нибудь шутник заведется на портале, то никакие доморощенные ограничения не помогут. А вот умным людям могут и помешать. Ну и наверное даже не стоит писать, что деплоить системные веб-части в галерею веб-частей мягко говоря не стоит - мне кажется, это вполне достаточная "защита от дурака".

      Резюмируя, хочется отметить, что эта статья написана на основе реального живого опыта. Я больше 2х лет писал Application Pages, но в результате пришел к выводу, что Site Pages лучше и теперь пишу только Site Pages. Есть опыт и с теми, и с другими. Эта статья - просто попытка поделиться опытом. Конечно, если вы по-прежнему не хотите писать Site Pages, дело ваше, вперед и с песнями на покорение SharePoint Apps 2013 без Site Pages :)

      Удалить
    2. "Central Administration - это такой же сайт, как и все остальные. Там точно также полно Site Pages."
      Можно парочку примеров?

      "Например, страница управления веб-приложениями - это Site Page."
      С каких это пор "_admin/WebApplicationList.aspx" стала site page?

      "Насчет SPSecurityTrimmedControl - никто не мешает, но на практике все пишут иначе."
      Поэтому лучше использовать site pages? :) Как это относится к сравнению application и site pages?

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

      Удалить
    3. С каких это пор "_admin/WebApplicationList.aspx" стала site page?
      Не, я имел в виду /applications.aspx.
      Можно открыть через SPD и посмотреть весь список. Все странички с меню, я так полагаю, являются Site pages. Непосредственно настроечные страницы - application pages.

      Поэтому лучше использовать site pages
      Alex, я очень старался обосновать, почему site pages мне кажутся лучше. Всё наверху написано. Если не прониклись, значит плохой из меня писатель :( Смысла еще раз писать не вижу.

      Не подскажите где ещё можно хранить веб части, если не в галерее?
      Вот когда вы создаете в Visual Studio веб-часть, там появляется автоматически Elements.xml и .webpart-файл. Elements.xml содержит CAML для развертывания этого самого webpart-файла в галерею веб-частей. Если удалить содержимое Elements.xml или просто удалить оба этих файла, ваша веб-часть не будет доступна через галерею веб-частей. Однако, SafeControls и сама сборка всё равно будут развернуты, и веб-часть по прежнему можно будет развертывать вручную, через AllUsersWebPart или программно, или же путем использования её как контрола через маркап.

      Т.е. по большому счету она будет доступна, но не через browser GUI.

      Например, через browser GUI мы же не можем развернуть DataFormWebPart, и другие веб-части, а вот через SPD или вручную - без проблем. И т.д.

      Удалить
  3. Меня откровенно пугают Site Pages. От страха упереться в какое-нибудь ограничение и получить ущербный функционал. Своя страница ближе к телу. Хотя конечно всегда есть чувство, что каждый раз создавать свои Application Pages не правильно. Например я не понимаю как можно сделать каскадные дропдаун листы. А если у клиента Foundation, то у него вообще функциональность веб-партов резко сокращается и каждый чих приходится программить руками. Использование стандартного функционала всегда похоже на ходьбу по минному полю. Никогда не знаешь где закончится твой путь. Скорее всего это от отсутствия должного опыта, но факт остается фактом.

    ОтветитьУдалить
    Ответы
    1. Привет Андрей,

      Извиняюсь за поздний ответ, почему-то пропустил твой пост :(

      Cascaded Dropdowns вообще нельзя делать на серверной стороне как класс (правильно я понимаю что ты так делаешь?), они делаются на клиенте и данные подтягиваются Ajax-запросами. Если совсем надо, можно туда прикрутить ASP.Net-овские асинхронные callback'и, но в SharePoint данные должны храниться в списках, а из списков всегда можно вытащить через OData или Client Object Model или на крайний случай через клиентский веб-сервис-call (SPServices). Ну нет проблемы совсем никакой...

      И нет, еще раз: нет никаких ограничений на SitePage. Даже если не получается стандартными средствами что-то сделать по той или иной причине (но поверь чаще всего причина в недостатке квалификации и не знании стандартного функционала SharePoint), создаешь обычный UserControl и дальше в нем - ASP.Net.

      А про Foundation, я 2.5 года писал на SharePoint Foundation :) Наш продукт DeskWork, на котором в основном в общем-то и был получен опыт который я описываю в статье, базируется на SharePoint Foundation. Поэтому со всей ответственностью заявляю: стандартных контролов и веб-частей там более чем достаточно. В серверной версии конечно есть кое-какие дополнительные, но на самом деле не так уж много, и большинство либо и не нужно, либо за пару дней можно зареимплементить.

      Удалить
  4. Андрей, а куда ты кладешь созданные Site Page? Создаешь специальную библиотеку или, например, используешь стандартную библиотеку SitePages?

    ОтветитьУдалить
    Ответы
    1. Чаще всего отдельную библиотеку или совсем без библиотеки. Там ведь можно в любой путь задеплоить, в том числе в корень сайта.

      Удалить

Внимание! Реклама и прочий спам будут беспощадно удаляться.