Итак, приступим. Прежде всего, почему в качестве платформы для сайта была выбрана SPF, а не SharePoint Server (далее – SPS)? В соответствии с лицензионной политикой корпорации Microsoft для сценариев работы через Интернет, когда доступ к корпоративным ресурсам через SPS получает неограниченное количество анонимных пользователей, необходимо приобретать лицензию SharePoint Server for Internet Sites. SPF бесплатна и это основной аргумент.
Но, выбирая SPF, мы лишаемся части функционала системы управления контентом сайта, которая доступна в SPS в полном объеме. Главным образом, это дополнительные шаблоны корпоративных сайтов и возможность публикации контента. Шаблоны корпоративных сайтов говорят сами за себя и позволяют создать сайт на основе стандартного шаблона. Возможность (feature) публикации позволяет использовать специальные типы контента публикации, списки и библиотеки документов, веб-части, мастер-страницы (master pages) и макеты страниц (page layouts). Вкупе с функционалом централизованного управления мастер-страницами и наследования их дочерними сайтами, управления навигацией сайта и функцией блокировки определенных страниц сайта для анонимных пользователей возможность публикации обеспечивает инфраструктуру системы управления контентом сайта. В SPF нам придется обходиться другими средствами.
Существует популярное мнение, что хороший корпоративный сайт на SharePoint – это сайт, который не выглядит как сайт на SharePoint. Для того чтобы добиться такого эффекта лучше отказаться от использования стандартных шаблонов мастер-страниц и макетов страниц SharePoint и заменить их своими. Первым делом нужно создать мастер-страницу сайта с брэндингом в корпоративном стиле. Проще всего начать с шаблона мастер-страницы с минимумом элементов управления ASP.NET/SharePoint и верстки, например, таким как starter.master. Многие для этих целей также используют этот гайд для создания мастер-страницы minimal.master. Для брэндинга сайта потребуется переопределить стандартные CSS-стили, определенные в файлах corev4.css, forms.css и т.д. Новые файлы стилей можно разместить в хайве SharePoint или специально созданной папке в иерархии сайта. Также брэндинг можно сделать с помощью функционала тем SharePoint, создав тему в Microsoft Office Power Point или Microsoft Theme Builder и добавив ее в коллекцию тем сайта. В зависимости от дизайна, часто для главной страницы сайта есть смысл создать отдельную мастер-страницу без панели навигации быстрого запуска или верхней панели ссылок.
Если структура корпоративного сайта такова, что сайт верхнего уровня имеет много дочерних сайтов, то следует правильно подходить к решению вопроса распространения обновлений основной мастер-страницы на дочерние сайты. Как отмечалось ранее, в SPF нет функционала централизованного управления мастер-страницами дочерних сайтов. Конечно, можно делать это вручную, копированием файла обновленной мастер-страницы в коллекцию мастер-страниц каждого из сайтов, но это, мягко говоря, неудобно. Логичнее завернуть основную мастер-страницу в возможность и устанавливать ее с помощью решения (solution). Вот пример конфигурационных файлов такой возможности:
<Feature Id="23E27B3A-120C-3259-02DA-103CC45179BB" Title="Site Master Page" Scope="Site" Version="1.0.0.0" Hidden="FALSE" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/" Description="This feature deploys the site master page"> <ElementManifests> <ElementManifest Location="elements.xml" /> <ElementFile Location="MasterPages\sitemasterpage.master" /> </ElementManifests> </Feature> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Module Name="SiteMasterPage" Url="_catalogs/masterpage" Path="MasterPages" RootWebOnly="FALSE"> <File Url="sitemasterpage.master" Type="GhostableInLibrary" /> </Module> </Elements> Атрибут RootWebOnly=«FALSE» говорит о том, что мастер-страница будет установлена в коллекции мастер-страниц всех сайтов семейства, а атрибут Type=«GhostableInLibrary» означает, что все установленные таким образом мастер-страницы будут ссылаться на один файл мастер-страницы, расположенный в папке возможности в хайве, поэтому любые изменения в этом файле будут отражаться на всех сайтах.
Поговорим о навигации сайта. В отличие от SPS, в SPF нет возможности создавать иерархическое многоуровневое меню в верхней панели ссылок навигации сайта через стандартную страницу администрирования сайта. Но это можно сделать программно, например, с помощью нехитрого скрипта PowerShell:
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"); $url = "http://site" $site = new-object Microsoft.SharePoint.SPSite $url; $web = $site.OpenWeb() $topnav = $web.Navigation.TopNavigationBar while ($topnav.Count -gt 0) { $topnav.Delete($topnav[0])} $node1 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("О компании", "/company", $False) $node1 = $topnav.AddAsLast($node1) $node2 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("История", "/company/pages/history.aspx", $True) $node2 = $node1.Children.AddAsLast($node2) $node3 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("События", "/company/events", $False) $node3 = $node1.Children.AddAsLast($node3) $node4 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("Новости", "/company/events/Lists/news", $False) $node4 = $node3.Children.AddAsLast($node4) Для меню быстрого запуска можно создать два уровня иерархии с помощью страницы администрирования сайта. Если этого недостаточно, можно аналогично создать структуру навигации скриптом.
Как было отмечено ранее, в SPS возможность публикации создает инфраструктуру для управления контентом сайта. Помимо прочего она позволяет хранить контент в специальных библиотеках документов «Страницы» (Pages), для которых включены опции утверждения и хранения определенного числа основных и промежуточных версий контента. В SPF мы можем воспроизвести этот функционал, создав библиотеки документов «Страницы» вручную и в свойствах настроив для них утверждение и версионность контента. Если для хранения контента на сайте используются другие списки и библиотеки документов — их можно настроить аналогично.
Возможность публикации в SPS несет в себе и специальные типы контента, например, «Страница статьи». С их помощью в библиотеках документов «Страницы» SPS можно относительно просто создавать новый контент сайта, контент размещается на странице в специальных элементах управления публикации. В SPF для этих целей можно использовать страницу веб-частей, добавлять на нее веб-часть «Редактор контента», размещать контент в этой веб-части, а страницу размещать в предварительно созданной библиотеке документов «Страницы». Если необходимо хранить HTML-контент в элементах списка, то для этого неплохо подходит поле типа «Многострочный текст» с опцией «Расширенный форматированный текст».
При создании сайта на SharePoint сложно обойтись без кастомизации стандартных веб-частей представлений списков типа XsltListViewWebPart. Их архитектура довольно своеобразна, и если требуется серьезная кастомизация большого количества таких веб-частей, например, с изменением XSLT-шаблонов рендеринга, можно съесть на этом немало стекла. Столкнувшись с такой задачей, для себя я сделал выбор в пользу написания своей универсальной (для моих целей) веб-части, которая по заданной в XML VIEW-схеме запроса получает данные из указанного списка/библиотеки документов и накладывает на них простой шаблон XSLT, который, как правило, пишется за 5 минут. Как говорится, почувствуйте разницу:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ext="webparts.xsltlistviewwebpart"> <xsl:param name="ListUrl"/> <xsl:output method="html"/> <xsl:template match="rows"> <div id="news"> <div class="page_title" style="margin-top:7px !important; margin-bottom: 10px;"> <span>Архив новостей</span> </div> <table width="100%" border="0" cellspacing="0" cellpadding="3" class="ms-listviewtable"> <tbody> <xsl:for-each select="row"> <tr> <td style="vertical-align:top;"> <span class="date_text" style="display:inline-block;"> <xsl:value-of select="ext:Frmt_Date_Time(PublishDate, 'dd MMMM yyyy')"/> </span> </td> <td style="vertical-align:top;"> <a class="title_item" style="font-size: 10pt;"> <xsl:attribute name="href">javascript:</xsl:attribute> <xsl:attribute name="onclick">javascript: window.location.href='<xsl:value-of select="concat($ListUrl,concat('/DispForm.aspx?ID=',ID))" disable-output-escaping="yes"/>&Source=' + escape(window.location.href);</xsl:attribute> <xsl:value-of select="Title" disable-output-escaping="yes"/> </a> </td> </tr> </xsl:for-each> </tbody> </table> </div> </xsl:template> </xsl:stylesheet> Еще один важный вопрос, с которым сталкивается разработчик сайта на SPF – нужно каким-то образом запретить доступ к определенным страницам сайта для анонимных пользователей, например, к системным страницам (application pages), доступным через /_layouts/, или служебным представлениям списков и библиотек документов. В SPS, на сайтах, созданных из шаблона «Портал публикации» (publishing portal), используется возможность «Режим блокировки для семейства сайтов» (ViewFormPagesLockDown), которая задействует функцию блокировки системных страниц сайта для анонимных пользователей. В SPF такая возможность отсутствует, и наиболее логичным решением, на мой взгляд, является создание своего http-модуля, для анализа и блокировки http-запросов к определенным страницам с последующим редиректом на страницу с информацией о запрете доступа. URL запрещенных страниц удобно задавать в конфиге веб-приложения сайта, например, в таком виде:
<SecuritySettings> <Extensions> <res ext=".aspx" /> <res ext=".html" /> <res ext=".htm" /> </Extensions> <Allowed> <res url="*/_layouts/searchresults.aspx*" /> </Allowed> <Denied> <res url="*/_forms/*" /> <res url="*/_layouts/*" /> <res url="*/_catalogs/*" /> <res url="*/_controltemplates/*" /> <res url="*/_cts/*" /> <res url="*/_private/*" /> <res url="*/_login/default.aspx*" /> <res url="*/m/default.aspx*" /> <res url="*/approval.aspx*" /> <res url="*/latestreports.aspx*" /> <res url="*/personalviews.aspx*" /> <res url="*/last2weeks.aspx*" /> <res url="*/allitems.aspx*" /> </Denied> </SecuritySettings> Адепты поисковой оптимизации контента сайта для поисковых систем с помощью meta-тегов, вероятно, будут озадачены способом, которым можно создавать такие теги для динамических страниц сайта, таких как формы просмотра элементов списков и библиотек документов (DispForm.aspx). В моем случае я решил этот вопрос следующим образом:
- на сайте был создан список ключевых слов с полем «Ключевое слово» (keyword),
- в списках и библиотеках документов, для которых в формах просмотра элементов требуются meta-теги, было добавлено поле подстановки по полю «Ключевое слово» из списка ключевых слов, а также поле «Описание» (description) для поискового описания контента, определяемого ключевым словом,
- был разработан элемент управления (web control), который в процессе рендеринга определял и при наличии записывал значение поля подстановки в meta-тег «keywords», а значение поля «Описание» в meta-тег «description»,
- этот элемент управления регистрировался на мастер-странице сайта в качестве DelegateControl AdditionalPageHead с помощью возможности:
<Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Control Id="AdditionalPageHead" Sequence="50" ControlClass="MetaTagGenerator" ControlAssembly="MetaTagGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=18bdc3dfdc022d0b" /> </Elements> В итоге, в процессе рендеринга страницы формы просмотра элемента списка или библиотеки документов, для которого заполнено поле подстановки ключевых слов, на странице размещаются соответствующие meta-теги.
И напоследок несколько слов о функционале поиска по сайту в SPF. Стандартный поиск предлагает выбрать области поиска. На корпоративном сайте, нам мой взгляд, такие настройки только мешают пользователю, так как обычно требуется поиск по всему контенту. Поэтому я рекомендую избавить пользователя от этого выбора путем небольшой кастомизации. Для этого нужно сделать следующее:
- создать свой элемент управления поиска, полностью аналогичный стандартному Microsoft.SharePoint.WebControls.SearchArea, но не создавать в его разметке список областей поиска SearchScope,
- с помощью возможности зарегистрировать созданный элемент управления на мастер-странице в качестве DelegateControl SmallSearchInputBox,
- в разметке стандартной страницы результатов поиска /_layouts/searchresulsts.aspx закомментировать элемент управления списка областей поиска SearchScope.
В этом случае, при отправке запроса на поиск системный скрипт СORE.js в функции_SubmitSearchRedirect, не обнаружив в разметке список областей поиска SearchScope, не установит параметр области поиска, что будет воспринято службой поиска как поиск по всем сайтам семейства сайтов.
ссылка на оригинал статьи http://habrahabr.ru/post/163665/
Добавить комментарий