Как я упоминал ранее, реализация Umbraco меня покорила. Это наглядный пример того, что означает правильная постановка задач и корректное следование им. Далее я разбираю основы работы и разработки в рамках этой CMS.
Umbraco полностью отвечает определению CMS — система управления контентом. Вся концепция внутренней кухни строится вокруг документов и операций с ними.
Документы
Костяк системы — документ. Это тип страницы, который может состоять из произвольного числа полей различных типов данных. Для удобства поля могут разбиваться по категориям (или закладкам).
Поля могут быть всего лишь нескольких типов с точки зрения БД (Integer, Data, Ntext, Nvarchar). Как можно добавить что-то ещё — перекомпиляцией одной из компонент самого движка или просто добавлением ещё одной сборки — я не ещё проверял. Сверху накладывается возможность задания стандартных допустимых значений, а также способов рендеринга типа. Стандартных типов данных может хватить на большинство задач, их порядка 20 штук. Добавление же новых типов не требует изменения ядра: достаточно определить тип в админской консоли, а для нестандартных отрисовок необходима подготовка и загрузка небольшой сборки. В такой библиотеке реализуется всего лишь 3 класса, хотя это ещё предстоит самому пощупать.
При создании нового типа документа определяется набор его полей, которые могут быть разбиты по категориям. Такие категории при создании документа будут разбиты на несколько закладок в GUI. Стандартная закладка — Generic Properties, содержит общие для всех типов документов свойства. Дабы облегчить интерфейс в дополнительные закладки добавить какие-то специфические части страницы.
Для документов и полей задается читаемое имя и алиас. Первое используется для работы в админке, второе — для выборки данных при построении страницы. Также для каждого документа задается иконка (для админки), описание, допустимые дочерние документы и возможные шаблоны.
Шаблоны — следующая основа системы. С 4-й версии (с ней я и начал своё знакомство) в качестве шаблонов используются стандартные master-pages ASP.NET. При этом админкой поддерживается наглядная иерархия, что позволяет поддерживать порядок в структуре. Более того, админка позволяет добавлять наследуемые и унаследованные блоки содержимого парой щелчков.
В любом шаблоне может быть определен дизайн и подключены несколько типов полезных составляющих страницы: макросы (XSLT, сборки кастомных контролов или наборы пользовательских контролов, а также файлы, написанные на Iron Python), элементы словаря (привет, локализация) и поля страницы.
Как итог, получаем очень важное для легкости работы разделение: данные и отображение отдельно, а функционал вообще в стороне. И это притом, что используется обычный ASP.NET, никаких MVC и MVVM.
Макросы
Заложенные в Umbraco принципы написания макросов просты и удобны. Разработчики максимально задействовали то, что уже есть в платформе .NET, а также добавили не обременяющие возможности взаимодействия.
Все задачи, связанные с отображением документов самой системы, решаются через XSLT. Да, можно извернуться, и написать отдельный модуль на C#, но лучше использовать заложенный каркас. Допустим, надо вывести на странице все дочерние узлы определенного типа, причем делать это только для узлов 2-го уровня вложенности. Для этого создаём новый XSLT-файл вместе с макросом (система сама предложит создать макрос до кучи), а в нём пишем такой код:
1: <?xml version="1.0" encoding="UTF-8"?>
2: <!DOCTYPE xsl:stylesheet [ <!ENTITY nbsp " "> ]>
3: <xsl:stylesheet
4: version="1.0"
5: xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
6: xmlns:msxml="urn:schemas-microsoft-com:xslt"
7: xmlns:umbraco.library="urn:umbraco.library"
8: exclude-result-prefixes="msxml umbraco.library">
9:
10:
11: <xsl:output method="xml" omit-xml-declaration="yes"/>
12:
13: <xsl:param name="currentPage"/>
14:
15: <xsl:template match="/">
16:
17: <xsl:variable name="rootTextpageNode"
select="$currentPage/ancestor-or-self::node
[@level = 2 and @nodeTypeAlias = 'CWS_Galleries']" />
18:
19: <div class="secondaryNav">
20: <h3>
21: <xsl:value-of select="$rootTextpageNode/@nodeName"/>
22: </h3>
23:
24: <ul>
25: <xsl:for-each select="$rootTextpageNode/node
[@nodeTypeAlias = 'CWS_Galleries']">
26: <li>
27: <xsl:if test="$currentPage/ancestor-or-self
::node/@id = current()/@id">
28: <xsl:attribute name="class">
29: <xsl:text>selected</xsl:text>
30: </xsl:attribute>
31: </xsl:if>
32:
33: <a href="{umbraco.library:NiceUrl(
current()/@id)}">
34: <span>
35: <xsl:value-of select="current()
/@nodeName"/>
36: </span>
37: </a>
38: </li>
39: </xsl:for-each>
40: </ul>
41: </div>
42:
43: </xsl:template>
44:
45: </xsl:stylesheet>
Обработка основана на атрибутах документа. При этом есть системные атрибуты, общие для всех документов, например, nodeName (имя документа), level (уровень вложенности) и id (числовой идентификатор любого документа в ветке сайта, по нему устанавливаются связи документов). Кстати, что удобно, ссылки можно строить с использованием имен документов. Т.е. если на сайте есть узел «стулья», а в нем расположен документ «табуретка обычная», то мы можем использовать следующий URL:
http://сайт/стулья/табуретка-обычная.aspx
Более того, такая задача, равно как и ряд других, уже решены в библиотеке Umbraco. В показанном выше примере это делается следующим образом:
href="{umbraco.library:NiceUrl(current()/@id)}"
До кучи стоит сказать, что в шаблонах мы можем подключить все необходимые стили и скрипты JS, учитывая их в том же XSLT. Конечно, обработка AJAX-обращений к серверу потребует дополнительных усилий, но при этом разработчики не обязывают, использовать ли jQuery или прибегнуть к AJAX ASP.NET.
Использование контролов и вообще дополнительных сборок, т. е. работа в Visual Studio нужна только для реализации какого-то дополнительного функционала, который не укладывается в сам движок и работу с документами. Тому примеры: рассылка писем, обращения к внешним системам.
Чтобы работа с такими дополнительными сборками была максимально эффективна, модули не просто могут подцепляться в шаблонах и работать согласно стандартному жизненному циклу ASP.NET, но и их публичные свойства могут определяться Umbraco и использоваться для передачи модулю информации из шаблона.
Для этого нужно сделать несколько простых действий. Сначала, объявить сами свойства (для примера небольшая часть кода):
public string EmailTo
{
get
{
return _EmailTo;
}
set
{
_EmailTo = value;
}
}
public string EmailSubject
{
get
{
return _EmailSubject;
}
set
{
_EmailSubject = value;
}
}
public string EmailBody
{
get
{
return _EmailBody;
}
set
{
_EmailBody = value;
}
}
* This source code was highlighted with Source Code Highlighter.
Далее, после подключения модуля, нажать Browse Properties и выбрать те свойства, которые должны задаваться на страницах.
После этого можно указывать значения этих свойств прямо в шаблоне, в качестве значений передавая конкретные значения или алиасы полей документа, которые будут вычисляться для передачи:
<umbraco:Macro EmailTo="[#emailTo]"
EmailSubject="[#emailSubject]"
EmailBody="[#emailBody]"
EmailReplyFrom="[#emailReplyFrom]"
EmailReplySubject="[#emailReplySubject]"
EmailReplyBody="[#emailReplyBody]"
EnableSSL="[#enableSSL]"
FormHeader="[#headerText]"
FormText="[#formText]"
ThankYouHeaderText="[#thankYouHeaderText]"
ThankYouMessageText="[#thankYouMessageText]"
Alias="CWS_ContactForm" runat="server"></umbraco:Macro>
* This source code was highlighted with Source Code Highlighter.
А далее к моменту загрузки контрола для обработки событий и его рендеринга эти свойства будут определены, и их можно будет использовать как для работы с API Umbraco, так и для собственных нужд.
Итог
В Umbraco живёт и здравствует принцип: создал раз, используешь часто. Основной ориентир на работу с документами здесь дополнен потрясающей лёгкостью разработки. Но есть одно важное условие: нужно хорошо представлять работу самого ASP.NET, т. к. система лишь дополняет и очень качественно использует эту платформу. Если с этим всё в порядке, остаётся только для каждого конкретного проекта поддерживать общие архитектурные принципы для поддержания единообразия используемых решений.
Большая часть действий может быть выполнена в админке. А когда необходимая структура и функционал готовы, все составляющие можно упаковать в отдельный модуль (здесь это package) для распространения и установки на других серверах.
Проблемы
У этой системы есть только две проблемы настроечного плана, которые устранимы, хотя в некоторых случаях могут доставить немало проблем. Во-первых, работает Umbraco только в корневом узле. Единственный способ обойти это ограничение заключается в создании поддомена. Не всегда это подходящий вариант.
Другая проблема в конфиг-файле. Блоки конфигурационных файлов в ASP.NET наследуются от узлов более высокого уровня вложенным узлам. Это легко исправимо для раздела <system.web>: делаем для этого узла обертку location с атрибутом inheritInChildApplications=«false». Но для блока <configSection> лёгкого пути нет. В моём случае проблема возникла со настройка весьма проста.
Back- и Front-Office
Пока не могу точно сказать, как лучше распределять функционал работы с документами между админкой и самим сайтом. Но пока считаю, что вешать всё на административную часть неправильно: всё, что касается пользовательского функционала, должно быть на самом сайте, тем более есть все возможности использовать API для работы с документами. Но для небольшого числа относительно сообразительных юзеров подойдёт и сама админка. Расширяемость этой части я пока не изучал.
Creative Website Starter
Знакомство с Umbraco было для меня особенно ускорено изучением и доработкой под свой сайт набора Creative Website Starter (CWS). В процессе раскопок в файлах этого модуля до меня и дошёл непривычный дзен разработки в этой системе. Я особенно упорно пытался найти скрипты для БД прежде, чем до меня дошло, как там надо работать с данными.
Дополнение от 12 февраля 2010
Проработав с Umbraco уже почти полгода, ни чуть не разочаровался. Все делается очень просто.
Для добавления новых элементов админки, создаются простые ascx-файлы с деталями интерфейса и вместе с кодом закидываются в каталог usercontrols/dashboard. Обработка данных внутри может быть какой угодно, но самое главное: надо предусмотреть и связать эту логику с каким-то дополнительным контролом самого сайта. Приведу пример. Пользователь заполняет форму на странице. Контрол, отвечающий за ее сохранение, отправляет все в какую-то дополнительную таблицу в базе сайта, или в общий xml-файл. Чтобы админ смог прочитать обращение пользователя, надо добавить контрол, который по такой же логике прочитает и выведет сохраненное ранее обращение пользователя. Все очень просто и пример можно подсмотреть в том же CWS.
Другой момент — стандартная обработка каких-то документов. Для этого создается обычный cs-файл, в котором прописываются обработчики событий и привязываются к документной модели. Привязка делается в событии Page_Load, а обработчики должны соответствовать определенной сигнатуре. Файл должен быть размещен в каталоге App_Code корневого узла сайта. Одновременно можно держать несколько файлов. Есть простой пример привязки обработчика на сайте Umbraco. Типы событий можно подсмотреть в объектной модели в Visual Studio. В проекте потребуется поставить ссылки на несколько основных библиотек CMS: businesslogic.dll, cms.dll и umbraco.dll. И ещё одно: в настоящее время есть очень неприятный баг умбрако, в результате которого Before-события выполняются всегда после изменения документа, поэтому использовать пока надо только After.