На этой страничке я расскажу как начать работать в среде Digimaker - одной из самых известнейших в мире CMS (Content Management System). Достаточно упомянуть список самых известных компаний мира, использующих Digimaker.

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

Одним из преимуществ является то, что ее контролы можно использовать не только на ASP2-формах, но точно также и на формах Word или Excel. Насколько мне известно со слов моих работодателей - это крайне важный для них момент.

Итак, все начинается со скачки и запуска инсталляционного пакета Digimaker Server 6.0.32.msi. Насколько я могу понять на этом этапе сложностей быть не должно. Просто нужные сборки установятся в ProgramFiles и в GAC.

А вот дальше будет чуть интереснее. На первом этапе надо убедиться, что именно ASP2 является дефолной версией ASP для IIS. Как правило, после инсталляции это не так. Дело в том, что Digimaker работает с помощью WSE (причем именно старой версии), а она не работает без выполнения этого требования.

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

Теперь пару слов об архитектуре Digimaker. Контролы Digimaker'а обращаются к WEB-сервисам Digimaker'а, которые исполняются в рамках сборки Digimaker.Web.Services.dll, исполняющейся в рамках отдельной службы Windows.

Насколько я понимаю, IIS при этом не нужен вообще. Те WEB-слубжы дигимейкера напрямую экспортируются WIN-службой. При этом она и осуществляет WSE-криптографию.

На самом нижнем уровне всей этой пирамиды - находится уровень данных. Он состоит из 291 таблицы и 758 шифрованных процедур.

Естественно, инсталлировать и управлять этой пирамидой нет необходимости вручную. Собственно для этого и предназначен сервер Digimaker'а, который умеет управлять всем этим: создавать новые базы, бекапить их, трассировать трафик между контролами и ВЭБ-службой. И главное - инсталлировать готовые шаблоны сайтов (и баз данных, конечно). Таких шаблонов он имеет четыре. Но, собственно говоря, те 291 таблиц и 758 процедур - это пятый (так называемый пустой шаблон).

Вообще функциональность этого сервера перечисленным не ограничивается, он умеет и интегрироваться с ActiveDirectory, управлять аутентификацией, создавать сертификаты, управлять MemberShip-профайдером, шифровать строки подключения к базе и еще много чего. Управляется он весьма продвинутым Config-файлом в 628 строк. Кроме того, для работы требуется файл лицензии с включенным в него X509-сертификатом. Файл лицензии высылается менеджером Дигимейкера после оплаты.

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

Теперь пара практических проблем, возникающих при работе с Дигимейкером. Во-первых, переименовать сайт или камп уже будет низзя. На какой домен выдана лицензия - с таким доменом пожизненно и работать. Во-вторых, прекрасный параметр RequerySSL я так и не смог прикрутить к сайту на Digimaker'e.

Дигимейкер работает со своим провайдером аутентификации, который работает хорошо, но по своей собственной базе, а не по той, что работает AspNetMembershipProvider. Конфигурационный файл приложения с Дигимейкером становится тоже грандиозным, примерно таким.

У этого конфигурационного файла приложения есть множество заморочек. Вот например одна из них. Достаточно изменить в нем имя странички аутентификации, как Дигимейкер умирает. А ведь служба дигимейкера имеет собственный конфигурационный файл, из которого казалось бы и должно браться имя этой странички. Таким образом имя аутентификацинной странички в приложении получается фиксированым Login.aspx и к тому же определенным внутри самой сборки дигимейкера.

Еще одна заморочка этого конфигурационного файла. Он постоянно занят и изменения в нем невозможно сохранить из студии. Более того, если их и сохранить как-то, то актуальность они приобретают только после перезапуска Дигимейкера. Кстати для определения кем именно занят файл - я пользуюсь утилитой WhoLockMe. Поскольку WSE-служба дигимейкера работает без IIS, даже перезапуск IIS не поможет освобождению конфигурационного файла приложения - только перезапуск самой службы Дигимейкера.

Естественно, сайты под Дигимейкером не должны управляться шарпоинтом. Но c SharePoint и даже Team Foundation Server они вполне уживаются на одной машине.

Да, чуть не забыл. Еще пару глючков. Часть контролов у меня по непонятной причине не работает. И кроме того, несмотря на множество обращений в техподдержку мне так и не ответили, почему в инсталяшке отсутствует сборка Digimaker.Logging.ConfigRollingFileAppender.

Это, так сказать - весьма поверхностное описание устройства CMS DigitalMaker. Теперь еще пару слов собственно о пользовательских сервисах, предоставляемых этим пакетом. Это, конечно, в первую очередь, сервис для ASP2-программиста в виде большого пакета достаточно продвинутых контролов. Из этих контролов Дигимейкера, собственно, и строится программистом приложение из множества страниц. Плюс этот же пакет контролов мы получаем для офиса. Но главное... Главное - это ведь CMS-система. Причем сделанная на весьма высоком уровне - с Атласом, например. Те заботится о том, как загрузить на сайт статьи, юзеров, рисунки и прочие данные уже не придется. Изменить меню, прочитать RSS или перестроить SiteMap - обо всем этом уже позаботился Digimaker. Правда все это очень не даром...

Документацию на контролы вы можете качнуть прямо у меня без инсталляции всей системы и получения временной лицензии (часть 1, часть 2, часть 3).

Comments ( )