Сказать, что разрабатывать под Umbraco просто — ничего не сказать. Я с огромным удовольствием сделаю подробный обзор. Но самое главное, здесь максимально большое число действий осуществимо через админку разработчика и лишь определенные детали бизнес-логики (т.е. то, где без кода уже не обойтись) требует реальной разработки.

Вывод информации из того, что есть — максимально укладывается в XSLT и редактирование master-pages. Подключить любой JS-фреймворк: как нечего делать. Добавить какое-то контекстно-зависимое меню: ерунда. Мне даже обидно, что не я эту штуку разработал.

Хотя пара серьезных огрехов, они, в общем-то, меркнут, особенно если соблюдать элементарные правила аккуратности.

Провёл пробную установку AxCMS и Umbraco. Когда проведу обзор и оценку разработки под эти CMS, будет готова полная статья и будут соответствующие развёрнутые посты.

А пока вкратце.

AxCMS ориентирована на корпоративные порталы, из чего следует её «тяжелый вес»: несколько приложений, рекомендуемые две базы, многоэтапная установка (хотя для дефолтного развёртывания есть «батники», ускоряющие всё неимоверно) и очень навороченная админка.

Umbraco — очень лёгкая, но и очень умелая платформа. Ставится очень быстро, быстрее даже DotNetNuke. Админка самая удобная из всех, что я когда либо видел (за 5 лет успел много всего пощелкать).

Продолжая тему DotNetNuke, пара замечаний на счет установки.

Если система ставится на 80-й порт, то всё просто прекрасно и просто: распаковал в виртуальный каталог с запущенным приложением (просто в узел оно лезть почему-то не хочет), подключился браузером, прокликал настройки, вуа-ля! Особенно порадовало то, что в настроечном интерфейсе не забыли возможность хранения базы в локальном файле с подключением к серверу БД для его обработки. Это может быть очень удобно для разработки.

Но вот если порт какой-то ещё, и после установки сделать пару неправильных телодвижений, то скорее всего придется сбрасывать кучу внутренних настроек, а проще говоря — переустанавливать. Чтобы такого не было, надо:

1. Подключиться к консоли localhost'а
2. Зайти в раздел настроек системы под учетной записью host
3. В разделе Portal Aliases добавить все те имена и адреса, по которым будут обращаться к системе с включением имени виртуального каталога (по дефолту прописано только localhost/имя_директории). Это могут быть имя_машины/dnn, имя_машины:порт/dnn, localhost:порт/dnn, ip:порт/dnn и т.п. Причем на случай переноса системы (например, с разработчетского сервера на продуктивный или тестовый) лучше заранее прописать соответствующие имена. Как вариант, можно отредактировать таблицу Port_Alias в базе.
4. В web.config включить настройку UsePortNumber. Она там заготовлена, надо только раскомментировать.

И до кучи почти классическая ситуация, связанная с установкой модулей. Наткнулся на этот баг ещё при установке. Возможна некорректная обработка установки модуля, в результате вылетает ошибка Thread was being aborted.

Как выяснил некий Эндрю Райер (в этой теме, внизу), проблема в том, что при копировании новых dll в каталог bin, приложение перезагружается (нормальное поведение ASP.NET). Каждому потоку даётся команда на завершение. Существует таймаут, за который потоки должны завершиться, иначе они отрубаются насильно. Получается, что установщик просто не успевал отработать и его гасили. Чтобы ситуацию исправить надо немного скорректировать узел httpRuntime:

Проблема актуальна для виртуальных систем и хостингов в момент высокой нагрузки серверов и при установке сразу большого числа модулей.

На работе повезло избежать разработки под Sharepoint (хотя будут использоваться веб-службы внешнего стандартного портала). А чтобы не создавать разрабатываемый сайт с нуля, решил задействовать CMS. Т.к. Umbraco и AxCMS решил изучать в свободное время, выбрал DotNetNuke.

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

Чтобы не возиться с регистрацией на сайте, можно сразу скачать дистрибутив с CodePlex. Там же можно и нужно взять Visual Studio Starter Kit (чуть ниже дистрибутива, в списке Other Downloads) — это шаблон проекта для Visual Studio, создающий заготовку всего сайта, который можно будет сразу залить на внешний веб-сервер. Насколько я понял, для большинства случаев использовать исходники движка нет смысла, это может потребоваться только для очень сильной переделки.

Относительно обзора разработки есть хорошие руководства по установке и созданию простейшего модуля (дизайн сайта напоминает Word Art и Basic), плюс обзор работы движка. Возможно, есть материалы получше качеством, но лично мне этого хватило.

Суть в следующем. Используется классическая архитектура: портал — страница — модуль. Движок предоставляет определенную модель взаимодействия компонент и их настройки, а также возможность внутренней логике делать всё, что угодно в рамках ASP.NET. Особенно радует, что не переиначена модель событий, т. е. всё также можно использовать Page_Load и другие события жизненного цикла контрола. Единственное различие в том, что контролы наследуют базовому классу модуля DotNetNuke.Entities.Modules.PortalModuleBase, который расширяет возможности контрола.

Для работы есть два простых варианта: создать проект на основе стартового работа (линк был выше) или открыть веб-сайт из внешнего или локального каталога. Работать можно из VS Web Developer Express, что может оказаться даже удобнее (работает шустрее).

Ну и до кучи остаётся отметить, что есть набор дополнительных модулей на официальном сайте, из разряда полезных мелочей, например: авторизация пользователей через Active Directory или OpenID, работа со списками, вики и пр.

Дублирую пост, опубликованный ранее в ЖЖ по причине его необходимости.

Опробовал бета-версию UMI.CMS .NET. Резюмируя: даже обновлённая бета не ушла дальше сырой альфы. Далее по порядку.

Сразу скажу, что сначала использовалась версия от 22 июня этого года, в процессе шаманств с установкой получил версию от 17 августа.

Установка

Одно сделано хорошо: установка. Но и то лишь в плане простоты настройки, а время не лучшее. Суммарно ушло 20 минут, из них 10 — установка Web Platform Installer и проверка необходимых компонент. При этом не создавалась отдельная учётная запись в СУБД. Количество шагов очень небольшое. Хотя при более активных телодвижениях тот же Blogengine.NET ставится быстрее.

После установки начались края бубнов. По какой-то причине почти все модули администрирования оказались отключены. Лечение потребовало трёх переустановок. Сначала было простое удаление (оказалось, что при дежурном uninstall файлы остаются на месте, база вроде тоже не трогается), затем оно было дополнено ручной чисткой с удалением файлов и базы. Полная переустановка помогла, но только со второго раза, когда использовал уже обновлённую версию. Появилась полноценная панель управления, заполненная всеми положенными модулями.

Впечатления

Памятуя презентацию на TechDays.ru хочу сказать, что все показанное там верно. Также Наружная страница веб-сайта работает гладко (а это редактирование страниц, как минимум), панель администрирования наверху также в порядке. Но! Совсем другая история с основной админкой.

Простой пример. Захожу в главный раздел, выбираю редактирование страницы «Оплата заказа», попадаю в раздел редактирования, все поля пустые. Ввожу текст в большое поле ввода (контент), нажимаю «Сохранить и посмотреть». Попадаю на страницу, где мало того, что нет введенного контента, так ещё и много заготовленной информации размещено (использовалась демонстрация магазина «Хомяки»). Дальше веселее. Меняю заголовок страницы, и о чудо, страница не найдена. Откат названия не помогает, хотя путь никто не трогал.

Точное число багов я не считал, тратить время на составление полного списка дефектов я не считаю нужным, потому как эту работу мне никто не оплачивает. Но когда наткнулся на означенные глюки, после возни с установкой желание собирать все плюшки и проводить полное тестирование, заготовленное для нескольких систем, отпало.

Система сырая, это должна быть закрытая альфа. Не спорю, в UMI весьма самобытная архитектура, основанная на нескольких хороших идеях индустрии с рядом собственных доработок. Но вот если процесс разработки этой конторы допускает такие бета-версии, то я не хочу работать ни с первым релизом, ни с последующими. Первый шаг к хорошему качеству продукта: процесс, ориентированный на качество с самого начала. Простейший тому барьер заключается в проведении хотя бы базового юнит-тестирования еще на этапе разработки. Написали код ядра — пишем проект теста ядра. Написали веб-модуль, пишем тесты веб-модуля. А эти ребята явно поспешили показать всем шуструю установку, а недра ещё не стабилизировали.

И ещё. Хорошие разработчики пишут хороший код сразу, хотя бы на 60—70%, а не когда каждая вторая функция хромает. Примеры тому есть: Microsoft, Google, Sun, Fog Creek. Оправданий низкому качеству быть не может: любой вклад в качество хотя и делает саму разработку дороже, но очень облегчает поддержку в будущем, чем даёт очень большую выгоду. В ином случае начинается дешёвая политика с целью распиливания бюджетов.