Министерство образования и науки Российской Федерации

Саратовский социально-экономический институт (филиал) РЭУ им. Г.В. Плеханова

Кафедра прикладной математики и информатики

Ю.Ю. Игнатов

ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ВЕБ-ПРЕДСТАВИТЕЛЬСТВА ФИРМЫ

Учебное пособие для студентов, обучающихся по направлениям подготовки

38.03.05 Бизнес-информатика, 01.03.02 Прикладная математика и информатика

Саратов

2017

УДК 004.41/.42 ББК 32.973-018

И26

Рекомендует к печати редакционно-издательский совет

ССЭИ РЭУ им. Г.В. Плеханова 15.12.2016 г.

Рецензенты: доктор физико-математических наук, профессор В.Н. Гусятников,

доктор физико-математических наук, доцент Т.Э. Шульга

Игнатов Ю.Ю. Проектирование и разработка веб-представительства фирмы :

учебное пособие для студентов, обучающихся по направлениям подго-товки 38.03.05 Бизнес-информатика, 01.03.02 Прикладная математика и информатика. – Саратов : Саратовский социально-экономический ин-ститут (филиал) РЭУ им Г.В. Плеханова, 2017. – 160 с.

ISBN 978-5-4345-0385-3 В учебном пособии рассматриваются технологии и инструменты разработки

веб-сайтов портального типа для организаций различного масштаба. Анализиру-ются понятия и структура веб-представительств, современные инструменталь-ные средства их разработки. Подробно разбираются основные особенности тех-нологии веб-разработки ASP.NET, понятие, структура и классификация систем управления веб-контентом. На практических примерах на основе передовой системы управления веб-контентом DNN показывается архитектура и устройство данной системы, техника разработки и дизайна интернет-магазина как одного из элементов веб-представительства. Пособие располагает большим количеством иллюстрированного материала.

Для студентов, обучающихся по направлениям подготовки 38.03.05 Бизнес-информатика, 01.03.02 Прикладная математика и информатика.

УДК 004.41/.42 ББК 32.973-018

ISBN 978-5-4345-0385-3 © Игнатов Ю.Ю., 2017

© Саратовский социально- экономический институт (филиал) РЭУ им. Г.В. Плеханова, 2017

И26

3

Оглавление

Введение ................................................................................................................................. 4

Глава 1. ВЕБ-ПРЕДСТАВИТЕЛЬСТВО: МЕТОДЫ И ИНСТРУМЕНТЫ РАЗРАБОТКИ ............................................................ 6

1.1. Понятие веб-представительства компании, основные этапы разработки ......................................................................... 6

1.2. Технология Microsoft ASP.Net и системы управления контентом (CMS) в веб-представительствах ...................................... 14 Контрольные вопросы к главе 1 ................................................................ 30

Глава 2. СИСТЕМА УПРАВЛЕНИЯ ВЕБ-КОНТЕНТОМ DNN (DotNetNuke) ДЛЯ РЕАЛИЗАЦИИ ВЕБ-ПРЕДСТАВИТЕЛЬСТВА .............................................. 32

2.1. Архитектура и структура CMS DNN ......................................................... 32 2.1.1. Ретроспективный анализ развития архитектуры DNN ........ 32 2.1.2. Внешние и внутренние компоненты архитектуры DNN ..... 37 2.1.3. Уровень данных, безопасность, классы DNN .............................. 47 2.1.4. Функциональная структура

административных средств управления DNN .......................... 54 2.2. Модули DNN, применимые к веб-представительству .................. 77 2.3. Технология дизайна и создания страниц веб-

представительства в CMS DNN ................................................................... 93 2.4. Microsoft Visual Studio и программирование

дополнительной функциональности модулей CMS DNN в веб-представительстве ........................................................................... 110

Контрольные вопросы к главе 2 ............................................................. 152

Заключение ...................................................................................................................... 154

Библиографический список .................................................................................... 157

4

Введение

На современном этапе развития экономики интернет – без пре-увеличения самый быстрорастущий сектор экономики. Постоянное увеличение пользователей сети во многих странах мира сформиро-вала в интернете отдельный электронный рынок, имеющий кон-кретные сегменты. В России количество пользователей российского сегмента глобальной паутины (Рунета) достигла почти 65 млн че-ловек. По количеству пользователей интернета Россия в 2012 г. вышла на первое место в Европе, которое ранее занимала Герма-ния, и на шестое место в мире. Первое место в мире занимает Китай, где веб-пользователей 564 млн человек, далее идут США, Япония, Индия и Бразилия.

В 2012 г. рынок контента, сервисов и электронных платежей был равен 563 млрд руб. и 268,7 млрд руб. соответственно, или 1,3% ВВП. Рост к 2010 г. составил почти 40%. В 2013 г. за 9 месяцев отмечен 25% рост [9], в абсолютном выражении рост составил 1,05 млрд руб, об этом свидетельствует исследовательский отчет Российской ассоциации электронных коммуникаций (РАЭК) «Эко-номика Рунета» [3]. А если брать еще и интернет-зависимые рынки, включающие электронную B2B-коммерцию, инвестиции, то эта цифра в совокупности равняется 5 трлн руб. 93% российских под-ростков регулярно пользуются всемирной сетью, ежедневно про-водя в интернете в среднем от трех до пяти часов. Интернет в РФ остался единственным каналом, где подросток может найти что-то нужное, полезное, дружелюбное по отношению к себе [4]. Напри-мер, согласно опросам американской компании @plan, 24% пользо-вателей глобальной сети в США используют ее для приобретения товаров в веб-магазинах, и эта цифра только увеличивается [5]. В 2012 г. рынок интернет-продаж в США вырос на 14,8% по отно-

шению к 2011 г., тогда как розничные продажи выросли на 5,3%. В 2012 г. оборот рынка электронной коммерции в США составил 231 млрд долл. В России этот показатель был равен 11,2 млрд долл. К 2017 г., по данным Forrester Research, интернет-ритейл будет со-ставлять 10% всех розничных продаж в США и достигнет 370 млрд долл. Рост будет происходить за счет тех клиентов, которые уже пользуются услугами интернет-магазинов, но при этом готовы тратить больше денег [12].

В Азиатско-Тихоокеанском регионе наблюдается бум электрон-ной коммерции. Китай, Индия и Индонезия, по данным eMarketer, задают темп всему региону. В 2012 г. объем онлайн-продаж в Китае составил 179 млрд долл., что на 42,2% выше, чем в 2011 г. – 126 млрд долл. (по данным Китайского министерства торговли). По оценке Forrester Research, китайский рынок электронной тор-говли еще больше: в 2012 г. общий объем продаж составлял 219 млрд долл.

Согласно официальным высказываниям высокопоставленных лиц Минкомсвязи России, индустрия, связанная с интернетом, – это один из локомотивов, который показывает, куда и как может дви-гаться экономика [10].

В приведенной статистике видно и то, что за указанными циф-рами стоят конкретные компьютерные системы. В самом общем виде, это аппаратно-программная инфраструктура сети Интернет, веб-серверы, приложения, программные системы управления кон-тентом, которые в комплексе и реализуют тот удобный электрон-ный инструмент для бизнеса и взаимодействия людей в интернете. И конечно, лицевой стороной обеспечения интернет-бизнеса в этой сложной системе является веб-сайт, портал, веб-приложение, где пользователям предоставляется удобная функциональность для удовлетворения своих многообразных потребностей. Разработка качественного веб-сайта, портала, веб-приложения, которые, по су-ти, выступают главной частью веб-представительства компании в сети, является сложной задачей, требующей знаний веб-дизайна, программирования на конкретной платформе, например JSP или ASP.Net. Также на современном уровне сайтостроения нужно вла-деть знаниями и навыками работы в той или иной системе управ-ления веб-контентом, одну из которых мы и рассмотрим в данном пособии – DNN на платформе ASP.Net.

6

Глава 1

ВЕБ-ПРЕДСТАВИТЕЛЬСТВО: МЕТОДЫ И ИНСТРУМЕНТЫ РАЗРАБОТКИ

1.1. Понятие веб-представительства компании,

основные этапы разработки

Инфраструктура сети Интернет, состоящая из системы аппарат-но-программных средств, реализует информационное простран-ство WWW – всемирной паутины. В то же время в интернете есть и другие пространства, например Fidonet, Buelletin Board System. Протокол FTP также имеет весомое значение, так как объем ин-формации, передаваемый по данному протоколу, в интернете со-ставляет 80%. Но именно в пространстве WWW, работающем по HTTP-протоколу, ведется коммерческая деятельность фирм, физи-ческих лиц или другие виды деятельности, например обучение. В этой связи для организации различных ресурсов компании в ин-тернете лучше подходит термин «веб-представительство», так как он направляет деятельность по созданию таких ресурсов не на ап-паратную систему сети, а только в информационное пространство.

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

Цели создания веб-представительства можно сгруппировать по следующим направлениям:

– ознакомление целевой аудитории с деятельностью компании; – формирование имиджа компании; – маркетинг, продвижение товаров и услуг; – обратная связь с целевой аудиторией; – исследование рынков;

7

– интернет-торговля; – сервисное обслуживание клиентов; – организация обучения; – проектная деятельность; – формирование социальных сетей компании; – формирование баз знаний или технической документации

об использовании продуктов компаний. Как правило, на практике трудно найти какой-либо веб-сайт

компании, который создан только под одну из вышеуказанных це-лей. Всегда преследуется несколько целей, поскольку при создании и поддержании веб-представительства играют роль и экономиче-ские факторы, и стремление максимально охватить и удержать це-левую аудиторию. Если мы откроем в браузере веб-сайт отече-ственной мега-корпорации ОАО «РЖД», то сразу же бросится в глаза целевая разнонаправленность ресурса. Во-первых, это крупная торговая площадка, которая реализует для клиента продажу би-летов на поезда дальнего и пригородного следования, продажу различных услуг, связанных с грузоперевозками. Во-вторых, это крупный информационный ресурс о структуре компании, ее дея-тельности, мероприятиях и событиях, организуемых услугах, предоставляющий много справочной информации. В-третьих, сайт формирует определенный стилевой имидж компании для аудито-рии, связанный с брендом, который аналогичен и другим неин-формационным объектам ОАО «РЖД», например окраске пассажир-ских поездов. В-четвертых, сайт предоставляет посетителям воз-можности для обратной связи с руководством компании посред-ством виртуальной приемной, возможности задать вопрос вице-президентам. Также сайт широко использует баннерную рекламу своих услуг, скидок и других возможностей железнодорожного транспорта, содержит ссылки на другие сайты компании.

Веб-ресурс для идентификации его как веб-представительства компании должен удовлетворять определенным критериям:

• администрируется самой компанией или лицом, которому делегированы на это администрирование полномочия;

• используется для коммерческого взаимодействия с клиентами; • однозначно определяется посетителями сайта принадлежа-

щим данной организации; • имеет постоянное доменное имя, URL-адрес [6]. Качество выполнения данных критериев, как правило, разное и

зависит от того, использует ли организация собственные или арен-

8

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

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

Корпоративный сайт определяется как структура, объединяю-щая веб-ресурсы, сайты организаций, входящие в ту или иную кор-порацию. Это объединение реализовано на одной странице при помощи расположения гиперссылок дочерних или подчиненных предприятий. Корпоративный сайт, как правило, содержит не-большое количество страниц, оформленных специфически, исходя из бренда и деятельности организации. На таких страницах отсут-ствует какая-либо сторонняя реклама, могут описываться текущие возможности корпорации, ее деятельность и нововведения. Через области расположения гиперссылок посетители сайта переходят по своим предпочтениям и потребностям к сайту подразделения, который оказывает конкретные услуги или типовые услуги в кон-кретном регионе. Хороший пример корпоративного сайта – сайт Сбербанка России, где посетитель может выбрать отделения банка в зависимости от своего местоположения.

9

Веб-портал, или электронный портал, – это сайт с большим ко-личеством разнообразных услуг по определенной тематике. Есть две трактовки данного понятия. Первая – представляет собой еди-ную точку входа из веб-браузера для удовлетворения потребностей в структурированной и неструктурированной информации, в пре-образовании данной информации в HTML-формат, поиска с обеспе-чением защиты передаваемых данных по сети. Вторая трактовка понятия – веб-сайты, на которых пользователи проводят больше времени. По этой трактовке к порталам можно отнести социальные сети, так как на них пользователи тратят большое количество вре-мени и передаваемого трафика. По мнению автора, исходя из опыта разработок сайтов в корпоративной среде, к порталу сле-дует относить именно сайт с большим или максимальным охватом предоставляемых сервисов по целевой предметной области. Это своего рода единая точка входа или перехода в ту или иную ин-формационную среду, сферу. Порталы можно классифицировать в зависимости от широты охвата предметной области [7]:

• общие порталы – учитывают различные тонкости потребно-стей посетителей и предоставляют разнообразные инструменты для их удовлетворения, например mail.ru., google.ru;

• специализированные порталы – предназначены для полного удо-влетворения потребности пользователей по узконаправленной тема-тике, например юридические порталы, система «Консультант Плюс»;

• корпоративные порталы – формируют единое информацион-ное пространство и сервисные услуги в границах деятельности той или иной корпорации.

Мегапорталы объединяют под одной оболочкой несколько тематических специализированных порталов.

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

Структура такого полноценного веб-представительства форми-руется из следующих элементов:

• профильные, тематические веб-сайты, порталы (например, основной сайт организации и интернет-магазин продукции данной организации);

10

• официальные страницы компании или группы в социальных сетях;

• ресурс информационно-почтовых рассылок подписчикам или RSS канал на основном сайте компании;

• целевые сайты для привлечения внимания посетителей к спе-циальным предложениям, акциям, конференциям и другим важ-ным событиям;

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

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

Компания с веб-представительством имеет следующие преиму-щества:

• увеличение спроса на продукцию компании; • рост престижности компании; • формирование и продвижение имиджа компании, товаров, ра-

бот и услуг; • улучшение системы связей с общественностью; • обеспечение потребителей, партнеров, акционеров, рекламо-

дателей и СМИ полной и актуальной информацией о самой компа-нии и ее продуктах;

• обеспечение информационной поддержки посетителей и кли-ентов посредством обратной связи;

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

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

11

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

В процессе разработки концепции веб-представительства необ-ходимо выдерживать общие принципы создания веб-сайтов:

• веб-представительство должно превращать посетителей в по-стоянных клиентов компании, бизнеса;

• отсутствие отказов в предоставлении информации на сайте; • качественная работа сайта на всех популярных браузерах

с учетом того, что нет единого стандарта обработки браузерами HTML-разметки;

• быстрая загрузка страниц сайта; • система актуализации информации (кто и как будет вводить и

править контент); • легкий и наглядный способ поиска информации, а также пол-

нота охвата поисковым движком сайта опубликованного контента; • легкое, наглядное восприятие информации. Недопустим нечи-

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

• подача информации на сайте должна соответствовать прин-ципу интерактивности в текстовом виде, дополняемая аудио- и видеороликами;

• качественная обратная связь с посетителями сайта (функцио-нальность высказывания мнения, вопросов-ответов, учет мнения посетителя при модернизации веб-сайта);

• ясная, концентрированная подача материала, его достовер-ность, уникальность и авторитетность.

После концепции описывается логическая структура представи-тельства, которая содержит:

• тематические разделы. Для удобного доступа к информации сайта его нужно разумно организовать. Все предполагаемое содер-жание нужно разбить на основные темы (разделы сайта);

12

• типы страниц. В соответствии с тематической разбивкой ин-формации можно вывести разные типы страниц, которые отлича-ются устройством и оформлением. Например, это относится к страницам, где располагается фотоматериал, презентационный материал к докладам, видеоматериал. При этом каждый тип стра-ницы должен максимально качественно выполнять свое предна-значение для посетителей;

• схема взаимодействия страниц – ссылки на страницы с других страниц в логической последовательности. Здесь разрабатывается блок-схема, наглядно отображающая связи страниц по гиперссылкам;

• навигация по сайту – чаще всего простой способ для перехода в другие разделы сайта на основе блок-схемы взаимодействия страниц. Навигация состоит из меню сайта и навигационных стра-ниц. Меню должно располагаться на каждой странице сайта и орга-низуется с учетом максимального удобства доступа к нему и выбо-ра пунктов, должно быть понятным и коротким. Навигационные страницы содержат карту сайта, указатель, путеводитель, оглавле-ние, схему сайта;

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

После описания логической структуры веб-сайта представи-тельства необходимо детально разработать оформление страниц. Эффективней начать с макетирования страниц, либо просто ис-пользуя бумажные носители, либо в электронном виде, например в программе для подготовки презентаций. При использовании профессиональных систем управления контентом макеты сразу можно строить их средствами, не затрачивая времени на перенос макета страниц с другого носителя на веб-сайт. Имея перед собой графический макет, гораздо легче определить, достаточно ли сде-лано в оформлении страниц для достижения цели. Далее нужно проработать стили оформления типов страниц, чтобы они имели некоторое отличие друг от друга, но в то же время придерживались общего стиля сайта. Затем прорабатываются компоненты оформ-ления, которые включают композицию, цветовую гамму, графику, шрифты. Композиция относится к общему виду страницы: что, где и как будет располагаться. Это отношение между различными объ-ектами – элементами навигации/субнавигации, рекламные банне-ры, формы для взаимодействия с пользователями, надписи, обла-

13

сти текста, фотографии и другие графические объекты. Цветовая гамма оформления сайта полностью зависит от бренда компании. В пределах сайта или типа страниц должны быть одинаковые стили оформления текста (заголовки разных уровней, эпиграфы, цитаты, ссылки и т.п.).

Должен быть выработан четкий стиль сайта, зависящий от бренда компании, который накладывает определенный отпечаток на мане-ру подачи материала, элементы оформления, принципы использова-ния цвета, звука, видео, анимационных баннеров. Манера подачи материала может быть также структурирована (например, сначала о главных темах, затем подробнее о каждой в отдельности).

Стилистические элементы оформления страниц сайта веб-представительства включают в себя:

• вид экрана; • цветовую гамму; • вид навигационного меню, его структуру и расположение; • вид и количество гиперссылок; • размеры шрифта и соотношение заголовков и основного текста; • количество и расположение мультимедийных элементов

на веб-страницах. Выработанного стиля веб-сайта нужно строго придерживаться и

осторожно вносить какие-либо изменения, так как посетители сай-та быстро привыкают к стилю, не осознавая его тонкостей, и порой болезненно реагируют на его изменения. Если вносить изменения, то делать это глобально, например как корпорация Microsoft при изменении стиля от Windows 7 до Windows 8 поменяла и стиль веб-сайтов, имеющий плиточный интерфейс последней операционной системы.

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

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

14

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

1.2. Технология Microsoft ASP.Net и системы управления контентом (CMS)

в веб-представительствах

В мире WWW существует несколько ведущих платформ (техно-логий) разработки и реализации веб-сайтов, порталов и сервисов различного уровня, применяемые в веб-представительствах – LAMP (Linux, Apach, MySQL, PHP), JSP (Java Server Page), CGI (Common Gateway Interface), Cold Fusion и ASP.Net. Применительно к ASP.Net в сообществе говорится о том, что она является технологией, по-тому что в общей форме представляет собой набор классов в ин-фраструктуре .Net Framework платформы Microsoft.Net. Данная технология возникла не на пустом месте. Фундаментом развития для нее выступили предшествующие технологии, такие как Active Server Page (ASP) и JSP. Недостатки и жалобы разработчиков на ASP, такие как невозможность отделения в проекте кода и раз-метки HTML, направили Microsoft на поиски новых решений в созда-нии продвинутой технологии. Также толчком послужило желание дать достойный ответ агрессивной экспансии PHP и JSP. Первый прототип ASP.Net появился в начале 1997 г. и носил название XSP. Прототип был написан на Java, так как на тот момент у Microsoft не было подобной технологии. Но с лицензированием Java для Microsoft возникли проблемы, которые исключали продление использования платформы. В 1999 г. Microsoft приняла решение

15

о создании новой технологии, базирующейся на так называемой общеязыковой среде выполнения, или Common Language Runtime (CLR), так как в ней, как и в Java, наличествовало программирова-ние по принципам ООП, сборка мусора и другие возможности. Тогда разработчики относились к такому решению с большой осторож-ностью, так как CLR, как и XSP, находилась на ранней стадии разра-ботки. Но, как показало время, риск себя оправдал.

По мнению экспертов [13], технология ASP.Net вобрала в себя все лучшее, что создано в области разработки всего спектра веб-решений. Это объектно-ориентированное и событийно-управ-ляемое программирование в HTTP-среде, применение .Net-совмести-мых компилируемых языков, классический подход в разработке веб-проекта, когда HTML-разметка и Java-скрипты являются ре-зультатом выполнения программного кода, создание приложений с компонентной структурой, сохранение состояния вида (view state), серверные элементы управления с богатым интерфейсом, адаптивный рендеринг, использование огромного количества го-товых классов при разработке, высочайший уровень безопасности, использование для разработки всей мощности MS Visual Studio и дополнительный ряд преимуществ. Существует несколько паттер-нов, которые дают возможность разработчикам подойти к техно-логии ASP.Net с разных сторон – это ASP.NET WebForms и ASP.NET MVC. Технологию обогащают дополнительные компоненты – ASP.NET AJAX и WebMatrix. Следует отметить, что в WebMatrix уже присутствует ряд ASP.Net систем управления контентом, которые мы будем анализировать ниже. Обобщенно рассмотрим логику ра-боты указанных выше паттернов или моделей.

Модель ASP.Net WebForms создавалась для реализации концеп-ции быстрой разработки в веб-среде, так называемая RAD – модель ускоренной разработки приложений. Поэтому вся технология ра-боты модели WebForms преследовала только одну цель – произво-дительность программирования.

Данная модель базируется на трех основных концепциях: об-ратная передача веб-страницы, состояние просмотра, серверные элементы управления. Когда запрос с браузера клиента приходит на веб-сервер и направляется на обработку исполняющей среде ASP.Net, его ждет несколько стадий, где центральное место занима-ет процесс обработки обратной передачи (postback). В этот процесс входит извлечение специальной информации состояния элементов управления из скрытых полей, совместно формирующих итоговую

16

разметку HTML-страницы. Для браузера после обратной передачи генерируется ответ HTML с новой информацией о состоянии эле-ментов управления страницы, которая будет использоваться при следующем запросе. В этом процессе необходимо указать на ключевой элемент: веб-страница ASP.Net базируется на форме, HTML-элементе <form>, содержащем все элементы ввода, с кото-рыми может взаимодействовать пользователь, и элементы отправ-ки данных. В ASP.Net страница отправляет содержимое своей уни-кальной формы самой себе, что, собственно, и является обратной передачей. Такая форма называется реентерабельной. Именно при-рода протокола HTTP, в котором два последовательных запроса на сервер никак не связаны друг с другом, не сохраняют никакой информации о сеансе, обрабатываются сервером независимо друг от друга, и обусловила необходимость реализации обратной пере-дачи и сохранения состояния в ASP.Net. Конечно, как мы сказали выше, механизм postback нужен для передачи информации опреде-ленного назначения, а точнее, той, которая хранится в так называе-мых скрытых полях веб-страницы. И здесь мы плавно переходим к следующей концепции построения ASP.Net – состояние просмот-ра, или view state [14].

Каждый элемент на странице ASP.Net может сохранять инфор-мацию о своем полном состоянии – в состоянии просмотра. Это свойство может быть отменено, но по умолчанию при создании на форме элемента управления в Visual Studio в свойствах элемента всегда установлено «view state = true». Данное состояние представ-ляет собой коллекцию, в которой страница между обратными пе-редачами хранит данные о состоянии своих дочерних элементов управления. Сама информация о состоянии передается на сервер через так называемые скрытые поля формы в зашифрованном ви-де. При поступлении запроса исполняющая среда ASP.Net произво-дит разбор информации в скрытых полях формы и учитывает ее при формировании новых экземпляров серверных элементов управления. Причем между обратными передачами подключается механизм десериализации состояния страницы, инициализирован-ный при получении запроса и сериализации состояния страницы, выполняемый при подготовке ответа. Состояние просмотра играет ключевую роль в реализации модели передачи данных, так как без этого отслеживание состояния страницы и всех его элементов в ASP.Net было бы невозможным, а следовательно, и сам паттерн WebForms остался бы только теорией.

17

Следующая концепция паттерна – серверные элементы управле-ния, играющие также ключевую роль. Поскольку ASP.Net базирует-ся на классах .Net Framework, серверный элемент – это класс System.Web.UI.WebControls (например, обычная таблица или выпа-дающий список, кнопка, переключатель, поле, которые пользова-тель видит на странице сайта). Такие элементы являются компо-нентами с открытым интерфейсом, всегда имеют уникальный идентификатор, настраиваются при помощи тегов разметки и ат-рибутов. Они непосредственно связаны с состоянием просмотра и реализуют обратную передачу. Но главная особенность серверного элемента управления состоит в том, что при разработке проекта программист избавлен от написания кода HTML и JavaScript. Про-граммирование серверного элемента заключается в правильном расположении его на форме, прописывании в разметке необходи-мых атрибутов его отображения и программировании реакции на те или иные события. При обработке на стороне сервера такой элемент превращается в живой экземпляр класса, генерируя необ-ходимый HTML-код для отображения в браузере.

Конечно же, кратко описанные концепции не появляются сами по себе, а реализуются и связываются воедино в так называемом контроллере страниц. Данный контроллер реализуется в виде клас-са, инициирующего несколько событий в программном коде, прово-дит обработку после передачи среде выполнения входящего на сер-вер HTTP-запроса. Обработка проходит через ряд фаз: создание эк-земпляра страницы, инициализация страницы, восстановление со-стояния страницы, обновление страницы, визуализация страницы и выгрузка страницы для передачи клиенту. Контроллер определяет стратегию обработки запроса в ASP.Net WebForms или жизненный цикл страницы. Реализация жизненного цикла приводит к форми-рованию событий и интерфейсов виртуальных методов для пере-определения и обработки производными классами, которые, в свою очередь, называются классами программной логики. В принципе, разработка сайта или веб-приложения ASP.Net WebForms означает написание классов программной логики с добавлением на страницу необходимых элементов управления. В классе программной логики содержится код, необходимый для обслуживания входящих запро-сов страничных элементов управления.

Тем не менее устойчивая модель WebForms может не удовле-творить своими возможностями реализацию определенных задач – контролировать код и структуру выводимого HTML до каждого

18

тега, идентификаторы внутренних элементов управления, встав-ляемые в итоговую модель DOM (Document Object Model), управ-лять объемом данных в состоянии просмотра, проводить удобное тестирование логики приложения, разделять ответственность. По этим причинам был реализован другой паттерн – ASP.Net MVC. Стек ASP.Net MVC имеет более простую структуру, различие обу-словлено отсутствием жизненного цикла страницы. Сохранение со-стояния необходимо реализовывать самостоятельно.

По аналогии с описанием концепции WebForms опишем концеп-ции технологии MVC: модель, представление, контроллер.

Модель – компонент приложения, отвечающий за взаимодей-ствие с источником данных (база данных, XML-файлы, файловая система), а также содержащий объекты, описывающие данные, с которыми работает приложение.

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

Контроллер – компонент, содержащий логику приложения. В контроллере описана логика обработки HTTP-запросов к веб-приложению. Контроллер взаимодействует с объектами модели, которые, в свою очередь, влияют на представление.

ASP.Net MVC имеет следующие преимущества: четкое разделе-ние логических слоев, полный контроль над разметкой страницы, логическое разделение функциональности, «красивые» URL-адреса, прозрачный процесс обработки запроса, поддержка различных движков генерации разметки, полноценная поддержка всех воз-можностей технологии ASP.Net. К недостаткам можно отнести бо-лее высокий «порог входа» в технологию, отсутствие механизма хранения состояния, сложность создания библиотек компонентов [8]. Таким образом, каждый паттерн ASP.Net по-своему хорош, и выбор между ними зависит от целого ряда факторов. Тем не менее, хоть паттерн ASP.Net MVC еще достаточно молод (финальная вер-сия 1.0 была выпущена в марте 2009 г.), уже существуют системы управления контентом на его основе, например Orchard, Umbraco.

Для ясности понимания принципов работы технологии ASP.Net следует провести сравнительный анализ с другим популярным средством создания веб-решений – РНР (в первоначальной версии обозначался как Personal Home Page Tools – инструменты для со-здания персональных веб-страниц). В настоящее время является

19

одним из лидеров среди языков программирования для создания динамических веб-сайтов и поддерживается подавляющим боль-шинством хостинг-провайдеров. Ядро PHP следует самому просто-му рабочему процессу: получить введенные данные, обработать их, отобразить вывод и полностью завершить свой процесс. Язык PHP позволяет динамически выводить HTML-разметку и другую ин-формацию, например заголовки для cookee. Возможна вставка кода в обычную статическую HTML-разметку, таким образом разработ-чик сам заботится о всей выводимой разметке.

В ASP.Net WebForms совсем другой подход. Каждая страница по умолчанию состоит из двух файлов – файл дизайна (внешнего вида страницы), где размещается HTML- и ASP.Net-код разметки, и файл отдельного кода, где программируется логика на языке VB.Net и C#. Идея проста – отделить внешнее представление веб-формы от логики ее работы, хотя здесь также возможен и подход PHP, но делать этого не рекомендуют. ASP.Net-разметка относится к серверным элементам управления на форме и их свойствам, например кнопки или текстовые поля, которые на стороне сервера превращаются в HTML- и JSP-код и отправляются клиенту.

При сравнении двух подходов становится очевидно, что понять принцип работы PHP гораздо проще, нежели ASP.Net. Порог вхож-дения в разработку PHP гораздо ниже, новичку гораздо проще по-нять его работy, чем сложную модель ASP.Net. Но, в свою очередь, низкий уровень разработчиков PHP встречается чаще, чем ASP.Net. При недостатке знаний в объектно-ориентированном программи-ровании на PHP можно создать динамический сайт с нужным функционалом, на ASP.Net – нет. Это доказывает, что на PHP веро-ятность получить низкокачественные продукты выше, чем на ASP.Net. При этом у PHP слабая поддержка объектно-ориентиро-ванного программирования, нет событий, перечислений, многопо-точности, слабая поддержка UTF. PHP – слишком нестрогий язык, в котором отсутствует типизация и слабо развит механизм исклю-чений. По причине отсутствия типизации в PHP нет возможности перегружать методы, переменные объявлять необязательно. Вследствие этого здесь могут быть сформированы опасные кон-струкции кода, которые даже не скомпилируются в компиля- торе Си, но в PHP будет выполнен с непредвиденным результатом. Некоторые из ошибок, например неинициализированные пере-менные, можно увидеть, если включить режим отображения всех ошибок командой error_reporting = E_ALL. Это нужно всегда дер-

20

жать под контролем в процессе программирования, но нет гарантии, что начинающие программисты PHP знают об этой особенности.

Более того, нередко в практике встречаются ситуации, когда разработчики сайтов по причине надоедания просто отключают функциональность по выдаче предупреждений об ошибках PHP. Часто в таких случаях сайт по-прежнему работает, и даже правиль-но, но нет никакой гарантии, что пропущенная ошибка не приведет к серьезным последствиям в дальнейшей работе сайта. При про-граммировании в ASP.Net, пока ошибка не будет исправлена, сайт попросту не скомпилируется и, соответственно, работать не будет. Кроме того, в PHP нет исключений, выкидываемых самим интер-претатором. Например, если в сайте ASP.Net произвести обращение к несуществующему объекту, произойдет исключение и работа по дальнейшему компилированию прекратится. В PHP же произойдет рендеринг страницы браузером с выдачей малозаметного преду-преждения об ошибке, которую можно не заметить. Даже если про-граммист PHP очень опытный, всегда есть опасность воздействия на качество написания кода человеческого фактора, потеря нужной концентрации по каким-либо причинам может привести к ошиб-кам, которые интерпретатор не заметит. Что в PHP всегда нужно помнить, в ASP.Net всегда сделает компилятор и не пустит дальше, пока проблема не будет исправлена.

Нетипизированность PHP также создает ограничения при раз-работке в использовании технологии IntelliSense, которая здесь не может быть так широко использована, как в ASP.Net. Например, у нас есть переменная-объект, которую мы получили не вызовом New, а вызовом метода, который вернул этот объект. В случае с ASP.Net известно, какого типа объект возвращает каждый метод, IntelliSense далее сможет подсказать атрибуты и методы у создан-ного объекта. В PHP такое не осуществимо, нет типизации, значит неизвестно, какого типа будет объект. Конечно, типы в коммента-риях можно указывать принудительно, но это требует лишней ра-боты и лишнего времени – общая производительность программи-ста снижается. В целом с уверенностью можно сказать, что начи-нать изучение веб-программирования с PHP крайне не рекоменду-ется. С другой стороны, в PHP более очевидны принципы работы веб. Однако прозрачность и приближенность PHP к истинным ме-ханизмам работы веб по сравнению с ASP.Net WebForms полностью может компенсировать ASP.Net MVC, но, как писалось ранее, порог вхождения в данную технологию еще выше.

21

Следует особо отметить, что разработка веб-представительств по технологии ASP.Net доступна не только на платформе .Net Framework от компании Microsoft. Существует и развивается про-граммная платформа Mono [17], позволяя разрабатывать корпора-тивные кросс-платформенные приложения. Это платформа создается как opensource-реализация .Net Framework с поддержкой стан-дартов ECMA-334 и ECMA-335. На данный момент доступна версия Mono 3.8.0, где реализована поддержка ASP.Net 4.5, ASP.Net AJAX и ASP.Net MVC4. Веб-сайт, разработанный в Microsoft Visual Studio, может быть без особых затруднений транспортирован в Mono, если не использовались специальные сборки, которые существуют только для систем семейства Microsoft. Mono работает на следую-щих платформах – Linux, OS-X, BSD, Microsoft Windows с возможно-стью развернуть ASP.Net веб-сайт на веб-серверах Apach и Nginx.

Рассмотрев кратко основы технологии ASP.Net, разберем по-нятие системы управления веб-контентом. Современное проек-тирование веб-представительств компаний трудно представить без специализированных систем управления веб-контентом. Англоязычная аббревиатура данных систем прописывается как WCMS – Web Content Management System – или чаще можно встре-тить сокращение CMS. С точки зрения истории развития про-граммного обеспечения такие системы появились недавно. Первой системой принято считать Vignette, которая появилась в США в 1995 г. В нашей стране решения по управлению контентом появились значительно позже. В этой связи необходимо в теорети-ческом плане рассмотреть данное понятие, структуру и классифи-кацию подобных систем.

С развитием интернета и веб-ресурсов сложность и объем сайтов также стремительно рос. Это повлияло на то, что технологии разра-ботки и поддержки сайтов стали не успевать за быстро меняющи-мися условиями бизнеса. Редактирование и поддержка сайтов тре-бовали знания технологий HTML/CSS-верстки; изменения структу-ры сайтов были сопряжены с каскадным изменением большого ко-личества взаимосвязанных страниц, что обусловливало значитель-ную трудоемкость развития веб-ресурса. Такие функциональные возможности сайтов, как гостевые книги и новостные ленты, реали-зованные отдельными скриптами, вдобавок еще написанные раз-ными специалистами, на тот момент ставили под сомнение гаран-тию защиты ресурса от взлома. Так называемые «сборные солянки» из разных технологий и подходов сайтостроения привели к тому,

22

что возникла потребность в стандартизации программных решений для веб, в необходимости разделить программную логику, дизайн и содержимое на независимые составляющие (для конечного пользо-вателя). Как мы можем видеть, такой подход действительно реали-зуется в системах управления веб-контентом: дизайн (внешний вид сайта в целом, отдельных страниц, конкретных блоков информации), информационное наполнение и функциональные модули представ-ляются как разные структуры. Дизайн сайта, как правило, реали-зуется шаблонами, изменяется значительно реже, чем контент, функциональность сайта легко расширяется необходимыми моду-лями. Следствием таких преобразований программных решений для веб-разработки стало то, что CMS открыли богатые и легкодо-ступные технические возможности для реализации динамических веб-ресурсов. Такие ресурсы, содержащие большой объем информа-ции для поддержания соответствующего уровня посещаемости, требующие также постоянного ее обновления, используют коллек-тивную работу контент-менеджеров через механизмы CMS. Именно системы управления контентом предоставляют такую легкую воз-можность сконцентрироваться только на обновлении данных. С по-мощью данных систем можно без труда создавать и редактировать страницы, размещать текстовый и фото-, видеоматериал, управлять правами доступа пользователей, публиковать закрытую информа-цию, доступ к которой есть только у определенных групп. Перечис-ленные возможности являются лишь небольшой частью списка функциональности данных систем.

Итак, система управления веб-контентом – это программное обеспечение, которое реализует функциональность группового со-здания и администрирования веб-контента, управления веб-ресурсом в режиме онлайн без использования для этого програм-мирования. В свою очередь, разбирая детали данного понятия, под контентом следует понимать все виды информации (текст, графи-ка, фото, аудио, видео), составляющей наполнение или визуализи-рованное для посетителя веб-сайта содержимое.

Основные функции CMS – это создание, управление, публикация, представление. Коротко опишем каждую функцию.

Создание – предоставление разработчикам сайтов удобных ин-струментов для создания структуры сайта, страниц и наполнение его контентом.

Управление – распределение прав доступа к веб-страницам и модулям, изменение структуры веб-ресурса, настройка параметров

23

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

Публикация – размещение контента таким образом, что он ста-новится доступным через веб-браузер. Встроенная функциональ-ность CMS автоматически адаптирует внешний вид страницы к ди-зайну всего сайта.

Представление – легкое манипулирование внешним видом сайта посредством шаблонов, которые можно применять как гло-бально ко всему сайту, так и к отдельно взятой странице.

CMS можно условно классифицировать по нескольким типам – простые, шаблонные, профессиональные, универсальные.

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

Шаблонная. CMS инсталлируется разработчиками. Пользова-тельский интерфейс определяет один или несколько модулей с жестко закрепленной структурой сайта. Система имеет набор стандартных сервисных функций для создания сайта и работы с ним. При динамическом формировании страниц может использо-ваться кэширование данных. Совместимость и масштабируемость шаблонных CMS аналогична простым.

Профессиональная. При достаточной квалификации может устанавливаться самостоятельно без привлечения разработчика. Интерфейс легок в освоении и интуитивно понятен, структура сай-та легко изменяется и расширяется. CMS предоставляет возможно-сти создания самых разнообразных сайтов. Функциональность сайта может быть легко расширена дополнительными модулями без какой-либо перестройки структуры проекта. Такие системы легко масштабируются (в технологическом плане), совместимы

24

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

Универсальная. Интерфейс пользователя очень продвинут, дает возможность переопределить атрибуты большинства объек-тов сайта, настраивать функциональность всего сайта. Располагает в своем составе средой разработки c расширенными возможностя-ми API. Такие CMS легко интегрируются с внутрикорпоративными ERP-системами, располагают системой управления прав доступа к сайту, порталу на внутрикорпоративном уровне, обладают функ-циональностью создавать порталы по принципу back и front office. Масштабируемость аналогична профессиональным системам плюс расширение в кластеры [1].

Стоит рассказать о нескольких ведущих системах управления контентом на платформе ASP.Net, имеющих также отражение на российском аналитическом портале веб-разработок CMS Maga-zine. Наиболее популярной и поддерживаемой сообществом разра-ботчиков является система управления контентом DNN (DotNetNuke) [15]. Компания-разработчик данного движка – DotNetNuke Corp, основана в 1996 г. с финансированием из не-скольких венчурных фондов и размещена в США в штате Калифор-ния, г. Сан-Матео. В 2011 г. успех коммерческих продуктов данной компании выделил ее из списка 500 как самую быстрорастущую.

Платформа CMS DNN – решение номер один в экосистеме Microsoft с открытым исходным кодом. Платформа была выпущена на рынок в 2003 г., постоянно развивается и распространяется в свободной и коммерческой версиях. Свободная версия, DotNetNuke Community, лицензирована в соответствии со стандартным согла-шением BSD, которое позволяет широкому кругу пользователей получить программное обеспечение бесплатно. Данное лицензиро-вание позволяет сторонним разработчикам в данной платформе вносить любые изменения в базовый код и выпускать собственные IT-решения в виде коммерческих проектов с условием не перекла-дывать на команду разработчиков DNN ответственность за послед-ствия изменения кода. Коммерческих версий несколько – Dot-NetNuke DNN Evoq Social, DotNetNuke Professional Edition и Enter-prise Edition. Версия Evoq представляет новую тенденцию в раз-витии CMS, направленную на усовершенствование онлайн-коммуникаций между сотрудниками и клиентами организации.

25

DNN Evoq Social позволяет создавать интернет-сообщества клиен-тов компании – не в общедоступных социальных сетях, а на корпо-ративном сайте. При этом сама организация получает возможность более эффективно взаимодействовать со своей целевой аудито-рией, управлять общением и контролировать данные. Движок ра-ботает на основе стека Microsoft – Windows Server, IIS, SQL Server. Существует возможность настроить работу DNN на базах данных MySQL [25] и Oracle [19]. На текущий момент выпущена седьмая стабильная версия движка [20].

В интернете насчитывается более 800 000 сайтов и порталов, построенных на основе DNN. Во внутрикорпоративном секторе на основе DNN построены различные бизнес-решения более чем в 2000 западных компаниях, работающих почти во всех отраслях экономики. Наиболее известных из них – аэрокосмическое агентство США NASA, авиационная компания Lockheed Martin, про-изводители широкого спектра радиоэлектронных товаров Motorola, Samsung, Корнелльский университет США, энергетиче-ская компания Energy Corp. of America, Банк Америки, производи-тель автомобилей KIA и т.д. [21]. Проекты на основе DNN развива-ются и на российском рынке сайтостроительства, сориентирован-ном на так называемый Рунет (российский сегмент сети Интернет). По данным аналитического портала рынка веб-разработок CMS Magazine, в Рунете работает около 115 решений на DNN и по количеству работ в категории «Корпоративный сайт» находится на 30-м месте среди бесплатных CMS [11].

Многими вендорами (порядка 25) разработано более 10 000 про-граммных модулей – расширений по таким основным направлени-ям, как: коммуникации (блоги, чаты, электронная почта), управле-ние контентом (формы, документы, контакты), поиск, навигация, медиа, маркетинг, социальные сети, электронная коммерция. Сайт компании располагает удобным интернет-магазином DNN Store, где можно скачать платные и бесплатные модули по широкому спектру категорий, шаблоны оформления для всех версий DNN.

В октябре 2012 г. между компаниями DotNetNuke Corp и Microsoft заключено четырехлетнее стратегическое соглашение о продвижении системы управления контентом DNN на облачной платформе Windows Azure. Облачными инженерами разработан специальный мастер инсталляции под названием DNN Azure Accelerator [22], с помощью которого DNN сравнительно просто устанавливается в облако Azure на триальный ознакомительный

26

период. Новая стратегия продвижения CMS платформы дает ощу-тимый прирост распространения, более 1000 инсталляций в месяц, и эта цифра стремительно увеличивается.

Следующая широко известная ASP.Net система управления кон-тентом – Kentico CMS. Компания разработчик Kenticо Software ос-нована в 2004 г. в Чешской Республике [18]. Имеет офисы в США, Англии, Европе и Австралии. На соревновании FAST 50, организо-ванном Deloitte In в 2010, Kentico Software s.r.o. была награждена как наиболее быстро растущая технологическая компания в Чеш-ской Республике.

Достаточно серьезное отличие CMS Kentico от DNN состоит в том, что полнофункциональный продукт полностью платный и стоит недешево, opensource-версий нет. Для ознакомления разработчики предлагают продукт с полной функциональностью на 30-дневный период. После прохождения процедуры регистрации на сайте вы по-лучаете ссылку для скачивания пробной CMS c последующим само-стоятельным развертыванием. Также компанией предлагается озна-комительный хостинг системы на 7 дней. Есть возможность полу-чить свободную (free edition) версию продукта, но с очень ограничен-ными возможностями: например, зарегистрированных пользовате-лей сайта может быть не более 100, а также на всех создаваемых страницах будет присутствовать лого компании-разработчика. Kentico предлагается разработчиком в трех коробочных редакциях c бессрочной лицензией – Kentico CMS Base, Kentico CMS Ultimate, Kentico EMS (Enterprise Marketing Solution). Лицензии могут приоб-ретаться как на сайт, так и на сервер. Стоимость зависит от вклю-ченных возможностей. Соответственно, цена базового продукта – 1999 долл., уровня предприятия (Enterprise) – 14 999 долл., но она может колебаться в зависимости от требований заказчика, которые учитывает расположенный на сайте конфигуратор редакций.

Согласно официальной статистике около 3000 клиентов исполь-зуют CMS продукт Kenticо Software. В интернете построено около 18 000 различных решений. В списке компаний-клиентов также есть известные в мире бренды – Microsoft, Sony, Ford, Samsung, Mazda, Electrolux. CMS Kentico присутствует и на российском рынке сайтостроения. Согласно данным ресурса CMS Magazine на этой платформе создано и работает 35 решений, по данным официально сайта Kentico – 65 решений.

В сравнении с DNN для движка Kentico слабо развит рынок моду-лей расширений и шаблонов оформления. На официальной торговой

27

площадке Kentico Marketplace [26] можно найти порядка 250 расши-рений, учитывая то, что продукту уже 10 лет. Конечно, это обуслов-лено типом лицензирования и стоимостью данного продукта, а также встроенной функциональностью в коробочные версии.

Достаточно известная система управления контентом – Umbraco, в России постепенно набирающая популярность. На данный момент в Рунете зарегистрировано 57 решений на основе этой системе, при-чем следует отметить сайт ОАО «Федеральная грузовая компания», дочернего общества ОАО «РЖД», компании, которая предъявляет к своим информационным системам повышенные требования. Дан-ная CMS использует подход с открытым исходным кодом, обеспечи-вает полнофункциональную систему управления контентом, которая проста в использовании и администрировании, может удовлетво-рять высоким требованиям производительности веб-проектов. Раз-работчик движка – американская компания Umbraco HQ с головным офисом в Беллингеме, но изначально система разрабатывалась дат-ским программистом Нилсом Хартвигом для собственных проектов. Первая версия данной системы была представлена в 2003 г.

Umbraco используется на многих языках более чем на 110 тыс. веб-сайтов в широком спектре отраслей экономики. Многие круп-ные компании в своей деятельности используют данный движок. Например, реализованы такие крупные проекты, как Peugeout.com, Heinz.com, Wired.co.uk, Hasselblad.com, sandisk.com, Denmark MSDN Community – msdncommunity.dk. CMS привлекательна для крупного и малого бизнеса тем, что, используя простой и устойчивый подход, позволяет разрабатывать на сайтах пользовательские функции и легко осуществлять последующую поддержку. Разработчикам не требуется изучать специализированный язык, используются стан-дартные инструменты редактора HTML-страниц – Visual Studio или Dreamweaver. Вся разработка идет при помощи средств ASP.Net: ма-стер-страницы, HTML, элементы управления ASP.Net и дополнений на основе технологий XSLT или Razor. Тем не менее, в отличие от DNN, Umbraco не является полностью готовым программным решением. После ее инсталляции обычному пользователю сходу создать сайт не получится, необходим некоторый объем знаний для понимания философии работы и возможностей системы. Одна-ко это удобная среда для разработчиков, которая позволяет гибко кастомизировать сайт под нужды конкретной ситуации.

Система управления контентом Umbraco использует смешанную лицензию – MIT / Umbraco UI License. Вторая, по сути, тот же MIT

28

при сохранении логотипов и бренда Umbraco. Есть также и ком-мерческие лицензии (Confidence и Complete), которые включают поддержку, ряд платных дополнений, полный доступ к обучающе-му видео на Umbraco.tv и разрешают ребрендинг CMS.

Для Umbraco существует площадка для представления сообще-ству модулей расширений, хотя на данный момент слабо структу-рированная по функциональному предназначению. На данной пло-щадке можно найти около 470 различных платных и бесплатных дополнений. Движок официально работает на стеке Microsoft, но также можно использовать в роли базы данных MySQL, VistaDB. Известны случаи запуска Umbraco на платформе Mono [29]. С шестой версии движок полностью поддерживает паттерн ASP.Net MVC.

В топ ASP.Net CMS входит известная в определенных западных и российских организациях система Orckestra CMS (старое назва-ние – Composite C1). Разработчик движка – датская компания Composite с головным офисом в Копенгагене. Компания занимает-ся разработкой коммерческого программного обеспечения по управлению контентом с 1999 г., но с 2007 г. начала движение к открытому исходному коду. В 2010 г. ее основной продукт WCMS Composite C1 был представлен общественности как free opensource [16], считается относительно новой и молодой системой на рынке ASP.Net. Однако эта система также распространяется и по коммер-ческой лицензии. Платная лицензия оформляется как подписка стоимостью 3000 долл. И платная, и бесплатная системы предо-ставляют: полную функциональность системы управления содер-жимым веб-сайта; веб-содержимое как в XML-файлах, так и в базе данных SQL; все необходимые инструменты для разработчика; полную документацию онлайн; поддержку сообщества; модули расширения (большая часть). Платная подписка дополнительно предоставляет: гарантию на продукт; автоматические обновле-ния; техническую поддержку (SLA-0). Система в целом ориентиро-вана на веб-разработчиков, создающих корпоративные веб-проекты, и вектор обучения работы в системе для новичков достаточно сложен.

Во всемирной паутине произведено порядка 40 000 инсталля-ций Orckestra CMS в широком спектре отраслей. Но здесь навряд ли удастся найти общемировые бренды среди клиентуры. В то же время российский ресурс CMS Magazine показывает 26 решений с малым суммарным ТИЦ (табл. 1). Также присутствует русско-язычный ресурс поддержки данного движка в Рунете [2].

29

На официальном сайте реализован магазин расширений, где можно скачать немногим более 90 модулей, как платных, так и бес-платных, тем самым увеличив функциональность CMS-движка. Из расширений примечательно то, что есть возможность легкой интеграции продукта в облако Windows Azure.

В последние несколько лет в российском сегменте интернета при-обретает известность разработка отечественной компании 1С-Битрих системы управления контентом на платформе ASP.Net – .Net Forge CMS, или 1С-Битрикс ASP.Net. Распространяется в Community и бизнес-редакциях. На данный момент существует восьмая версия бесплатной редакции .Net Forge CMS. Система содержит удобные ин-струменты для управления сайтом: визуальный редактор, интерфейс «Эрмитаж», блоги с поддержкой Windows Live Writer, кэширование данных, интернет-магазин с продвинутой логикой скидок и другие.

Таблица 1

Рейтинг ASP.Net CMS в российском сегменте интернета [11]

Поскольку в данном учебном пособии нет возможности рас-

смотреть все системы управления контентом на базе платформы ASP.Net, общие характеристики наиболее известных из них приве-дены в табл. 2.

Таблица 2

Общая характеристика ведущих систем управления веб-контентом на платформе ASP.Net

№ Название WCMS

Базовая направленность

Тип лицензирования

на максимальные возможности

Официальный сайт/сайт поддержки

на русском языке

1 DotNetNuke Корпоративные веб-сайты, многопортальность, мо-дульность функционально-сти. Реализовано отдельное решение для построения корпоративных социальных сетей (Evoq)

Opensource-версия Community свобод-ная по лицензии BSD. Открытый ис-ходный код. Также есть коммерческие версии

http://www.dnnsoftware.com

№ WCMS Количество работ Суммарный ТИЦ 1 DotNetNuke 121 6125 2 Composite C1

(Orckestra CMS) 73 740

3 Kentico CMS 22 200 4 Umbraco 103 5005

30

Окончание табл. 2

№ Название WCMS

Базовая направленность

Тип лицензирования

на максимальные возможности

Официальный сайт/сайт поддержки

на русском языке

2 Kentico Корпоративные веб-сайты, электронная коммерция, маркетинг, социальные сети

Коммерческий про-дукт

http://www.kentico.com/

3 Composite C1

Корпоративные веб-сайты Opensource (MPL 1.1), также есть ком-мерческая версия

http://www.composite.net/

4 Telerik Sitefinity

Корпоративные веб-сайты по технологии back и front office, многопортальность, маркетинг, электронная коммерция

Коммерческий про-дукт

http://www.sitefinity.com/

5 AxCMS.net Корпоративные веб-сайты по технологии back и front office, многопортальность, маркетинг, электронная коммерция

Коммерческий продукт

http://www.axcms.net/

6 Umbraco Корпоративные веб-сайты Opensource (MIT), также есть коммер-ческая версия

http://umbraco.com/

7 MojoPortal Профессиональные веб-сайты (кроссплатформен-ный движок)

Opensource (CPL) http://www.mojoportal.com/ http://mojoportal.net.ua/

8 N2 CMS Профессиональные веб-сайты

Opensource (LGPL) http://n2cms.com/

9 .Net Forge CMS

Профессиональные веб-сайты, многопортальность

Opensource, есть коммерческая вер-сия

http://www.bitrix.net/ru

10 Monox Профессиональные веб-сайты, социальная сеть

Opensource http://monox.mono-software.com/

11 Orchard Корпоративные веб-сайты (ASP.Net MVC)

Opensource (New BSD)

http://orchardproject.net

12 Kooboo CMS

Корпоративные веб-сайты (ASP.Net MVC)

Opensource (Revised BSD)

http://www.kooboo.com/ http://kooboo-cms.ru/

Контрольные вопросы к главе 1

1. Назовите цели создания веб-представительства компании. 2. Каким критериям должен удовлетворять веб-ресурс как веб-

представительство компании?

3. В чем заключаются различия между личным сайтом, корпоратив-ным сайтом, веб-порталом?

4. Дайте определение веб-представительства компании, опишите его структуру.

5. Что должна содержать концепция проектируемого веб-предста-вительства компании?

6. Какие технологические платформы существуют для разработки веб-представительства компании?

7. На каких принципах базируется паттерн разработки веб-сайтов ASP.Net WebForms?

8. Как работает серверный элемент управления ASP.Net? 9. Какую функцию выполняет контроллер страниц ASP.Net WebForms? 10. Из каких базовых компонентов состоит технология веб-разработки

ASP.Net MVC? 11. Каковы существенные отличия при разработке веб-сайтов в ASP.Net

и PHP? 12. Перечислите факторы, которые повлияли на создание систем

управления веб-контентом. 13. Дайте определение системы управления веб-контентом и пере-

числите ее основные функции. 14. Классифицируйте системы управления контентом по типам. 15. Перечислите ведущие системы управления веб-контентом

для создания веб-представительств на платформе ASP.Net. 16. Какие крупные компании и сектора экономики охватывают данные

системы управления веб-контентом?

32

Глава 2

СИСТЕМА УПРАВЛЕНИЯ ВЕБ-КОНТЕНТОМ DNN (DotNetNuke)

ДЛЯ РЕАЛИЗАЦИИ ВЕБ-ПРЕДСТАВИТЕЛЬСТВА

2.1. Архитектура и структура CMS DNN

2.1.1. Ретроспективный анализ развития архитектуры DNN

Для более четкого понимания архитектуры DNN необходимо

сделать небольшой ретроспективный анализ версий исследуемой нами системы управления контентом. Развитие архитектуры Dot-NetNuke начинается с 2000 г., когда платформа .Net Framework имела только первую beta-версию. Архитектура CMS DotNetNuke зарождалась не на пустом месте, у истоков лежит IBuySpy Portal, в то время пример наиболее успешной практики создания веб-приложений по новой технологии веб-разработки ASP.Net. По сути IBuySpy Portal, как фреймворк для разработки ASP.Net-приложений, был одной из первых систем управления контентом, имеющей большие сходства с Microsoft SharePoint и с решениями для органи-зации веб-порталов на стеке LAMP. IBuySpy Portal позволял созда-вать полностью динамические веб-сайты, состоящие из неограни-ченного количества виртуальных страниц. У каждой создаваемой страницы был стандартный заголовок и три области размещения контента – левая, средняя и правая, что является стандартным размещением для сайтов портального типа. В пределах этих па-нелей администратор мог динамично размещать модули. Данные модули представляют собой мини-приложения для управления специфическими типами контента. IBuySpy Portal располагал шестью основными модулями – новостная лента, ссылки, графика,

33

форум, HTML- и простой текстовый редактор, редактор XML, а также модули для администрирования портала.

Как фреймворк для разработки ASP.Net-приложений IBuySpy Portal обеспечивал механизмы для управления пользователями, ролями, правами, шаблонами, модулями. Таких основных сервисов было достаточно, чтобы подогревать аппетиты большинства начи-нающих разработчиков на ASP.Net. После делового предложения разработчикам IBuySpy Portal от Скотта Гуттри, родоначальника технологии ASP.Net, о применении другой модели развития данного проекта были приняты меры по поиску нового бренда. Поскольку проект был сориентирован на opensource-решение, необходима была такая идентичность, которая имела бы максимальную узна-ваемость в сообществе и обеспечивала бы механизм для строи-тельства всемирно признанной программной экосистемы. Прове-денные исследования по конкурирующим портальным решениям на других платформах показали большую тягу к слогану «Nuke!», или «ядерная бомба». Данный слоган был первоначально введен в оборот разработчиком PHP-Nuke Франсиско Бурси, не всеми при-знанный пионер систем управления веб-контентом. Данный слоган был использован в названии многих других аналогичных проектов, что приобрело промышленное признание в прикладном жанре веб-портала. Версия 1.0.5 IBuySpy Workshop была переименована в Dot-NetNuke, что было очень быстро преобразовано сообществом фреймворка в DNN.

В декабре 2002 г. Шон Уокер, разработчик программного обеспе-чения в компании Perpetual Motion Interactive Systems Inc, выпустил DotNetNuke 1.0 как общедоступный проект. В DotNetNuke 1.X поль-зовательский интерфейс допускал слабую возможность для персо-нализации. По существу, в то время все сайты на DNN выглядели однообразно, что являлось негативным фактором по отношению к данной CMS на фоне того, что повсеместно в глобальной паутине рос спрос на креативность и разнообразие в оформлении сайтов.

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

В версии DotNetNuke 3.0 произошли коренные изменения в программной архитектуре. Было модифицировано ядро, вызван-

34

ное необходимостью реализовать управление пользователями и группами на основе API Membership от Microsoft. Эта необходи-мость также повлекла за собой другие изменения: почти полную перестройку пространства имен с переводом API в логические компоненты; обеспечение расширяемости без разрушения совме-стимости на уровне двоичного кода. До третьей версии сервисная архитектура DotNetNuke была полностью однонаправленной. Пользовательские модули могли обращаться к функциональности ядра, но не наоборот. Введенные в новое ядро дополнительные интерфейсы позволили пользовательским модулям внедрять свои функции взамен встроенных в ядро. Это обеспечило простой ме-ханизм для основной программной структуры с целью взаимодей-ствия со сторонними модулями, тем самым обеспечивая двуна-правленный информационный обмен с ядром CMS. Были произве-дены модификации кода, в результате чего DotNetNuke мог ис-пользовать стандартные URL, переработан поисковый движок, позволявший индексировать контент в сторонних, не основных модулях CMS. Был введен API клиента, позволяющий усилить в модулях движка обработку на стороне клиента (так называемый «толстый клиент»), реализована полная статическая локализация, почти аналогичная технологии локализации в ASP.Net 2.0. Dot-NetNuke 3.0, благодаря своим серьезным усовершенствованиям в архитектуре, обеспечил основной импульс развития рынка раз-работчиков модулей – дополнений к CMS.

В то же время обретение модулями сторонних разработчиков официального статуса как поддерживаемого DNN требовало опре-деленных усилий. Требовался так называемый период «инкуба-ции», чтобы заставить модуль соответствовать стандартам проекта DNN. Должно было быть определено официальное название проек-та модуля, стандартам должны соответствовать наименования пространств имен API, папок, файлов, комментарии к программно-му коду, названия объектов базы данных, метаданные инсталляци-онного пакета модуля и документация к нему. Модуль также дол-жен был пройти проверку на предмет безопасности и дефектов, дабы не затронуть негативно сообщество DNN. С точки зрения ин-фраструктуры разрабатываемого модуля его код должен быть за-гружен в специальную базу кода. На официальном ресурсе Dot-NetNuke необходимо создать раздел для отслеживания проблем с дискуссионным форумом и блогом. В настоящее время эти требо-вания реализуются на ресурсе Codeplex.com.

35

Работа по созданию следующей версии системы управления контентом – DotNetNuke 4 – была направлена на перемещение кода движка на новую версию платформы ASP.Net 2.0. Одно из самых больших достижений данного перехода была полная совмести-мость сторонних модулей и шаблонов оформления для старых вер-сий DNN, разработанных на ASP.Net 1.1. В DotNetNuke 4 стала при-меняться технология AJAX. Также был внедрен полнофункцио-нальный API JavaScript, что позволило сторонним разработчикам модулей усиливать функциональность на стороне клиента. Это обусловило новый подход к созданию функциональности главного меню сайта на DNN. Так как в новой версии ASP.Net были нововве-дения, ускоряющие разработку сайтов, в частности реализован ви-зуальный конструктор внешнего оформления страниц – IDE для ASP.Net 2.0, разработчики DNN также реализовали аналогич-ные дополнения. Был создан стартовый пакет разработчика, кото-рый при инсталляции в Visual Studio в течение минуты полностью формировал функциональную среду проектирования модуля. Для сообщества DNN это было значительным плюсом, так как по-низил барьер входа в разработку модулей и позволил без значи-тельных усилий интегрировать его в структуру веб-приложения DNN. Более того, выпущенные в то время бесплатные версии Microsoft SQL Server 2005 и Visual Studio Express в сочетании с шаб-лоном разработки для DNN позволили формировать качественную среду разработки приложений под DNN совершенно бесплатно.

В DotNetNuke 5 при поверхностном рассмотрении может пока-заться, что это незначительный следующий релиз CMS-движка, но при серьезной разработке сайта можно отметить большое количе-ство серьезных улучшений. Полностью перестроен весь упаковоч-ный формат для расширений. Усилена безопасность благодаря ре-ализации запрещающих прав (Deny), оптимизировано создание и управление страницами, улучшена производительность на основе новой модели кэширования данных, административная панель управления переработана с целью предоставления полной гибко-сти управления. Улучшился движок оформления сайта (шаблонов) в CMS, предоставляя разработчикам концепцию дружественного проектирования, сохраняя при этом всю былую стабильность и ка-чество их применения.

20 июля 2011 г. была анонсирована следующая версия системы управления контентом – DotNetNuke 6. Главным изменением стало то, что полностью было переработано ядро движка и, как видимый

36

результат этой переработки, код полностью переписан на C#. Дан-ный язык с момента анонсирования версии официально стал ос-новным языком развития платформы. До этого ядро движка было написано на Visual Basic.Net, но платформа не категорична для про-граммиста в выборе языка, модули и классы также можно продол-жать разрабатывать на Visual Basic.Net, произведя соответствую-щие предварительные настройки. В данной ситуации все зависит от предпочтений разработчика. Упрощенный пользовательский интерфейс DotNetNuke 6 существенно повысил производитель-ность создания и поддержки веб-сайтов. Появились новые выпа-дающие диалоги и панель управления, обновились администра-тивные модули, объединенные с улучшенным меню. Следует отме-тить, что в данном ключе обновилась вся линейка продуктов Dot-NetNuke, т.е. не только Communty-версия, но и Professional и Enter-prise Edition, причем с некоторыми нововведениями только в по-следней версии. В частности, в Enterprise-версии DotNetNuke 6 был реализован коннектор для взаимодействия с внутренними корпо-ративными порталами на Microsoft SharePoint, который позволяет быстро и безопасно публиковать документы, хранящиеся в Share-Point, на веб-сайте вне зависимости от его места расположения (интернет, интранет, экстранет). Также эти версии дополнены но-выми и разработанными с нуля модулями для ведения электрон-ной коммерции, причем адаптированные для продавцов с неболь-шим портфелем товаров. Таким образом, четко просматривается универсальная направленность данной системы управления кон-тентом.

Последняя на момент написания данного учебного пособия вер-сия DotNetNuke – 7.x. Основные изменения в данной версии направлены на поддержку возможностей HTML 5, ASP.Net 4.5 и об-лачной платформы Windows Azure. В архитектурном срезе в этой версии значительно улучшен поисковый механизм, что всегда яв-ляется актуальным для всех CMS. В частности, расширено храни-лище поисковых данных и увеличена скорость поиска на базе Lu-cene.Net, улучшен алгоритм присвоения релевантности контенту. Теги, название и ключевые слова имеют релевантность выше, что позволяет найти необходимую информацию быстрее. Также реали-зована функциональность включения в поиск данных профиля пользователя, интерактивности, интернационализации, локализа-ции, расширения поиска фильтрами для индексации информации внутри файлов различных форматов (Word, PDF и др.)

37

Соответственно, претерпел изменения и пользовательский ин-терфейс CMS, оптимизированный в сторону производительности рендеринга в браузере и комфортности выполнения частых опера-ций. Например, снижает нагрузку на сервер реализованная функци-ональность для редакторов страниц загружать их только в режиме просмотра, управляемая флагом «Stay in Edit mode». Также появи-лась возможность перетаскивать модуль мышью на страницу из па-нели управления и располагать его не только на страницах текуще-го портала, но и на других порталах внутри одной инсталляции.

Обобщая итоги проведенного анализа, видим, что архитектур-ное развитие рассматриваемой нами системы управления кон-тентом определяло несколько ключевых факторов: изменения в базовой веб-платформе ASP.Net и Windows; достижение макси-мальной гибкости и удобства в разработке модулей-расширений и шаблонов дизайна (внешнего оформления) для CMS; ориента-ция на тенденции в сообществе opensource-проектов; совмести-мость с прошлыми версиями CMS; обеспечение гибкой системы безопасности на основе прав доступа; увеличение производи-тельности и времени отклика веб-страниц; удобство и комфорт-ность интерфейса управления функциональностью CMS (интер-фейс пользователя).

2.1.2. Внешние и внутренние компоненты архитектуры DNN

Рассмотрим архитектуру DNN на уровне программного окруже-

ния и внутреннего устройства. Уровень программного окружения можно разделить на уровень сервера и уровень системы управле-ния контентом. DNN удобней всего работать на стеке Microsoft, т.е. это операционная система Windows Server c развернутой ролью веб-сервера (Internet Information Services). На веб-сервере должна быть установлена служба роли – ASP.Net. Также обязательно нали-чие установленного на сервере пакета .Net Framework, включаю-щего в себя классы ASP.Net, необходимой версии для работы той или иной версии DNN. Следует отметить, что версия ASP.Net равна версии пакета .Net Framework. Например, для версий Dot-NetNuke 4, 5 и 6 необходим ASP.Net 2.0, для DNN 7 уже минимальное требование – ASP.Net 4. Уровень хранения данных обеспечивает предпочитаемая из совместимых с портальным движком СУБД. Наиболее удобно использовать MS SQL Server, но также поддержи-

38

вается использование MySQL Server и Oracle. Данная поддержка обеспечивается специальным программным модулем, реализую-щим провайдер данных для той или иной СУБД, и именно его нали-чие определяет возможность работы с разными СУБД.

На рис. 1 показаны блоки архитектуры DNN, разделенные на два уровня – уровень сервера и уровень CMS.

В общем виде уро-вень системы управле-ния контентом разделя-ется на два подуровня: уровень библиотеки классов программного кода, реализующий ту или иную функциональ-ность ядра или провай-деров данных, и модули. CMS также дополнен ин-терфейсом прикладного программирования для взаимодействия с раз-

личными внешними службами, например с платежными системами или поисковой системой. Подуровень данных – это созданные сай-ты на одной инсталляции продукта, так как DNN является много-портальной CMS, страницы сайтов и размещенные ссылки на моду-ли на каждой странице. Все данные на этом подуровне хранятся в файловой системе на диске сервера, где развернута CMS, и в базе данных. База данных может находиться на отдельном сервере. Для работы с базами данных система управления контентом ис-пользует технологию ADO.Net, входящую в состав .Net Framework. Она имеет обширный набор компонентов для разработки распре-деленных приложений, совместно использующих данные. Данная технология работает со всеми источниками данных – СУБД, OLE DB, ODBC, текстовые и табличные файлы, XML-данные, данные прило-жений.

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

Данные модели подразделяются на следующие виды: • модель провайдера;

Рис. 1. Блоки архитектуры DNN

39

• инверсия контроллов (элементов управления, начиная с DNN 5); • пользовательские объекты прикладной логики; • централизованный гидратор объектов; • членство, роли и провайдеры профилей на основе ASP.Net API; • локализация, зеркально повторяющая локализацию в ASP.Net [28]. Модель провайдера используется в DNN как шаблон, позволяю-

щий заменять функциональность ядра системы без изменения ба-зового программного кода ядра. Главная цель таких провайдеров – обеспечить хорошо документированный, легкий для понимания API, в преимущества которого должна входить простота и гибкость расширений. Для достижения такой цели провайдер устанавливает своеобразный контракт между конкретным внедренным API и пользовательской логикой. Слой пользовательской логики в коде устанавливает такую функциональность, которую должен обеспе-чить тот или иной внедренный API . Когда производится вызов ме-тода API провайдера, этот метод далее вызывает конкретный API, который и выполняет необходимую функцию, запрос. Данный ме-тод не заботится о том, как происходит выполнение, пока не полу-чит результат данного выполнения. Проще говоря, модель провай-дера обеспечивает реализацию принципа: стройте объекты так, чтобы они не зависели от деталей других объектов.

В DotNetNuke провайдеры используются в следующих функцио-нальных областях:

• источники данных; • ролевое членство пользователей; • профиль пользователей; • роли пользователей; • навигация; • кэширование трафика; • аутентификация пользователей; • планировщик заданий на выполнение; • журнал событий сайта (логирование); • редактор HTML; • провайдер поисковой машины; • провайдер дружественных URL. Первым провайдером, появившимся в DNN, был провайдер ис-

точников данных. В ранних версиях система управления контентом поддерживала только MS SQL Server. Методы для работы с данной СУБД были плотно интегрированы в CMS, что в данной архитектуре

40

построения делало невозможным использовать для сайтов другие СУБД. С другой стороны, сообщество разработчиков просило реа-лизовать в DNN поддержку других СУБД, что напрямую влияло на популярность данной CMS. При изменении архитектуры построе-ния DNN программный код провайдера данных становится незави-симым от прикладного интерфейса программирования для кон-кретной СУБД. В нем также не прописывается, какой конкретно сервер и какое имя базы данных должны быть использованы. Путь к базе данных конфигурируется в файле конфигураций web.config в формате XML. Единственное требование к провайдеру данных, кроме конфигурации источника данных, заключается в том, чтобы внутренний API провайдера для конкретной СУБД выполнил все условия по обеспечению необходимой функциональности, опреде-ленной в абстрактном базовом классе доступа к данным (рис. 2). Например, все методы в абстрактном базовом классе доступа к данным, помеченные как MustOverride, должны быть переопре-делены во внутреннем программном коде провайдера для кон-кретного источника.

Базовый абстрактный класс доступа к данным должен быть настроен для корректной работы с конкретным API провайдера

Рис. 2. Компоненты концепции модели провайдеров данных в DNN

41

той или иной СУБД. Это необходимо для указания типа сборки, ко-торую нужно использовать для работы с указанным конкретным API. Каждый API может нуждаться в различных параметрах настройки. Например, провайдеру данных нужно указывать строку подключения, определенную в параметрах настройки конфигура-ции, тип базы данных. Для провайдера аутентификации на основе XML необходимы конфигурационные данные об имени и располо-жении файла записи лога.

Для провайдера данных конфигурационные данные находятся в секции “configuration > dotnetnuke” и в секции “connectionStrings” файла “webconfig”. Пример строк:

<configuration> <!-- register local configuration handlers --> <connectionStrings> <!-- Connection String for SQL Server 2005/2008 Express --> <add name="SiteSqlServer" connectionString="Data Source=localhost;Initial

Catalog=dnn060209;User ID=sa;Password=1234567" providerName="System.Data. SqlClient" />

<!-- Connection String for SQL Server 2005/2008 <add name="SiteSqlServer" connectionString="Server=(local);Database=

DotNetNuke;uid=;pwd=;" providerName="System.Data.SqlClient" /> --> </connectionStrings> <dotnetnuke> <data defaultProvider="SqlDataProvider"> <providers> <clear /> <add name="SqlDataProvider" type="DotNetNuke.Data.SqlDataProvider,

DotNetNuke.SqlDataProvider" connectionStringName="SiteSqlServer" upgradeConnectionString="" providerPath="~\Providers\DataProviders\ SqlDataProvider\" objectQualifier="" databaseOwner="dbo" />

</providers> </data> </dotnetnuke>

Следующий паттерн в архитектуре DNN – пользовательские объекты прикладной логики (Custom Business Object, CBO). По су-ти, это определенные правила того, как программно описывать классы прикладной логики в DNN, направленные на максимально удобную разработку. В коде DNN ярким примером данного под-хода является класс DotNetNuke.Services.Vendors.AffiliateInfo, написанный в файле AffiliateInfo.cs, расположенный в каталоге дистрибутива по пути Community\Library\Services\Vendors. Если

42

мы посмотрим на код в данном файле, то увидим одни пропи-санные свойства класса (рис. 3). Это является важным отличием CBO, методов в нем нет. Мето-ды, которые управляют в дан-ном классе, находятся в специ-альном контроллере, написан-ном для данного CBO. Контрол-лер CBO содержит прикладную логику, необходимую для рабо-ты со связанным пользователь-ским объектом класса CBO, причем данная логика не со-всем стандартная на первый взгляд. Это обусловлено тем, что данные для свойств объек-тов CBO хранятся в базе данных и методы в контроллере CBO инициируют гидрацию (слия-ние, перетекание) с данными, расположенными в базе дан-ных, с объектами класса. Сам механизм гидрации реализует класс CBO, обеспечивающий мощный сервис на уровне ядра DNN по слиянию данных для пользовательских объек-тов CBO. Файл с написанным классом гидратора расположен

по пути Community\Library\Common\Utilities в дистрибутиве DNN. Код представляет собой коллекцию методов, которая является централизованным средством для обеспечения данными объектов или их коллекций в пользовательском объекте прикладной ло-гики (рис. 4). Контроллер CBO вызывает центральный гидратор и передает ему типы объектов для заполнения. В зависимости от вы-званного метода в границах гидратора он возвращает единствен-ный гидрированный объект или их коллекцию. В процессе запол-нения свойств объекта гидратор обнаруживает свойство CBO, ко-торое использует отражение, или свойство-рефлектор. Такие свой-

Рис. 3. Свойства класса пользовательского объекта CBO

43

ства предполагают кэширование данных, которые при следую-щем цикле гидрирования в объектах того же самого типа будут загружаться не из базы данных, а из кэша оперативной памяти. Для получения данных свойств из базы данных для коллекции объектов используется метод FillCollection-гидратора. Данный ме-тод принимает интерфейс IDataReader и тип данных объекта как входные параметры. Затем происходит возвращение гидрирован-ной ArrayList коллекции объектов определенного типа, указанного в параметре odjType. Например, код, который работает в модуле отображения списка порталов, требует коллекцию объектов Por-talInfo и затем обеспечивает их отображение на странице, где рас-положен данный модуль. В DNN по умолчанию данный модуль находится в разделе Host > Site Management и отображается, когда происходит вход в портал под учетной записью узла (host). Код данного модуля вызывает метод GetPortalsByName() для получения коллекции объектов PortalInfo. Коллекция ArrayList заполняется методом DotNetNuke.Common.Utilities.СBO.FillCollection, который преобразовывает объект iDataReader (из запроса базы данных) в коллекцию гидрированных объектов PortalInfo, т.е. объектов, объединенных с данными, хранящимися в базе данных DNN. Для гидрирования единственного объекта используется метод CBO.FillObject.

Рис. 4. Схема гидрирования свойств объектов пользовательского CBO

Использование гидратора CBO значительно уменьшает количе-ство строк программного кода для заполнения свойств объектов данными. Например, для методов, которые выполняют получение

44

данных из базы с использованием централизованного гидратора, требуется написание всего одной строки кода:

public AffiliateInfo GetAffiliate(int AffiliateId, int VendorId, int PortalID)

{ return (AffiliateInfo)

CBO.FillObject(DataProvider.Instance().GetAffiliate(AffiliateId, VendorId, PortalID), typeof (AffiliateInfo)); }

При непосредственном обращении через провайдер данных необходимо инициировать объект и прописать для каждого свой-ства строку с присвоением типа данных. Гидратор позволяет вы-полнять программный код с разъединенными коллекциями объек-тов, избавляя от необходимости непосредственно прописывать код для объектов работы с базой данных, таких как DataReaders, DataTables или DataSets. Гидратор усиливает сервисные возможно-сти кода, позволяя с меньшими затратами времени проводить рефакторинг.

Внутренняя архитектура DNN делится на несколько уровней (рис. 5):

• уровень представления; • уровень прикладной логики (бизнес-логики); • уровень доступа к данным; • уровень данных (СУБД).

Рис. 5. Блоки внутренней архитектуры DNN

45

Рассмотрим данные уровни подробнее. Уровень представле-ния обеспечивает интерфейс клиентам для доступа к порталу и его приложениям. Данный уровень состоит из следующих элементов: веб-формы; шаблоны внешнего оформления сайта; области или панели расположения контента; контейнеры; модули; скрипты на стороне клиента.

Первичной веб-формой в DNN является страница Default.aspx, обеспечивающая точку входа в портал. На данный файл возложена функция динамической загрузки других элементов уровня представ-ления DNN. Файл Default.aspx расположен в корневой директории раз-вернутого портала. Данная форма загружает шаблон оформления для каждой страницы, применяя параметры настройки для каждой стра-ницы или портала. Главный класс шаблона находится в пространстве имен DotNetNuke.UI.Skins. Шаблон содержит так называемые области или панели. Он включает вложенные контент-панели, которые фор-мируют коллекцию объектов панели, каждый из которых принимает дизайн и настройки для каждого шаблона, страницы или портала. Основной программный класс панелей находится в пространстве имен DotNetNuke.UI.Skins, открытый код можно найти в файле /Library/UI/Skins/Pane.cs. Объект панелей загружает контейнеры для каждого расположенного модуля, основываясь на его настройках, а также для страницы и портала в целом. Базовый класс контейнеров расположен в пространстве имен DotNetNuke.UI.Containers. Открытый код находится в файле Containers.cs (рис. 6).

Модули имеют хотя бы один пользовательский элемент управления, являющийся интерфейсом взаимодействия пользова-теля с данным модулем. Данный пользовательский элемент управ-ления, или интерфейс, загружается объектом контейнера, который считывает параметры настроек для каждого модуля, страницы и портала в целом. Данные элементы для интерфейса модуля являют-ся файлами с расширением .ascx и находятся в каталоге установки модулей. В DNN присутствует несколько клиентских Java-скриптов, относящихся к ядру пользовательского интерфейса фреймворка. Например, /DotNetNuke/js/dnn.controls.dnnmenu.js используется элементом управления DNNMenu для отображения и обеспечения функциональности меню на сайтах. Сторонние модули, как и шаб-лоны оформления, также могут иметь ссылки на Java-скрипты. Дан-ные скрипты могут располагаться как в директориях установки мо-дулей и шаблонов, но также могут использовать Java-скрипты ядра DNN, расположенные в корне в каталоге /js.

46

Рис. 6. Схема загрузки объектов DNN уровня представления

Рассмотрим процесс загрузки сайта на DNN на уровне представ-ления. Когда происходит посещение сайта, веб-форма загружает страницу Default.aspx. Программный код логики Default.aspx загру-жает назначенный шаблон оформления для активной страницы. Данный шаблон как пользовательский элемент управления должен быть унаследован из базового класса DotNetNuke.UI.Skins.Skin. Объект шаблона создает объект секции или панели для каждой па-нели контента, присутствующие в шаблоне, и размещает их в кол-лекции панелей. Затем объект шаблона производит перебор через все модули, которые ассоциированы с данной страницей, и при-крепляет их к назначенным секциям. Если в секцию вложен больше чем один модуль, то у секции создается коллекция модулей. Далее каждый объект секции должен определить контейнер, назначен-ный каждому модулю. Объект секции производит инициализацию объекта контейнера для каждого модуля и передает их каждому связанному контейнеру. В версиях DNN до 5-й контейнер обеспечи-вал визуальную границу для отделения модулей друг от друга и меню действий для модуля, определенных системным админи-стратором. В следующих версиях контейнер также отвечает за внедрение, впрыскивание модулей на страницы.

47

Программный класс контейнера может влиять на модули в пределах всего портала или на конкретный модуль. Далее кон-тейнер определяет наличие у модуля специального интерфейса DotNetNuke.Entities.Modules.iActionable, и если он имеется, то проис-ходит обнаружение действий, назначенных администратором для данного модуля, и они добавляются к соответствующему кон-тейнеру. Шаблоны, контейнеры и модули могут добавлять ссылки на каскадные таблицы стилей в отображаемой странице. Каждый из этих объектов производит поиск CSS-файлов в своей инсталляци-онной директории. Если такой файл найден, объект добавляет HTMLGenericControl к странице, чтобы сослаться на таблицу стилей. Данный процесс выполняет программный код внутри класса шабло-на по событию Init. Окончательное представление контента в модуле обрабатывается в пределах жизненного цикла модуля по каждому событию. В последней операции загрузки код логики страницы Default.aspx отображает ссылки соответствующих каскадных таблиц стилей в зависимости от настроек портала и его главного шаблона.

Слой прикладной логики системы управления контентом DNN обеспечивает логику выполнения для всей основной функцио-нальности портала. Этот уровень предоставляет много сервисов для модулей ядра и модулей третьих разработчиков. Сервисы биз-нес-логики включают:

• локализацию; • кэширование; • управление исключениями в модуле; • журналирование событий; • персонализацию; • поиск; • установку и обновление; • членство, роли и профили; • права доступа. Слой прикладной логики является фундаментом для CBO –

пользовательских объектов прикладной логики, главная цель ко-торых состоит в том, чтобы хранить информацию об объекте.

2.1.3. Уровень данных, безопасность, классы DNN

Рассмотрим уровень данных. Данный уровень обеспечивает

двунаправленную (чтение, запись) работу с данными для уровня прикладной логики и CBO. Данный слой использует модель про-

48

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

• Data Provider API – абстрактный базовый класс, который уста-навливает правила выполнения для установленного API, разрабо-танного под конкретную систему управления базами данных;

• API для конкретного источника данных – программный класс, который находится в режиме наследования от абстрактного базо-вого класса Data Provider API и выполняет установленные правила по перегрузке необходимых членов и методов.

По умолчанию DotNetNuke имеет в наличии провайдер для Microsoft SQL Server в реализации для абстрактного базового класса. Рассмотрим на примере программного кода, как происходит взаи-модействие описанных выше элементов:

public AffiliateInfo GetAffiliate(int AffiliateId, int VendorId, int PortalID) { return (AffiliateInfo) CBO.FillObject(DataProvider.Instance().GetAffiliate(AffiliateId, VendorId, PortalID), typeof (AffiliateInfo));

}

Эта функция производит получение или возвращает данные для свойств из базы данных для указанных параметров, используя гидратор. Интерфейс IDataReader отправляет данные объекту FillObject, который производит вызов экземпляра провайдера для конкретной СУБД DataProvider.Instance(), унаследованный от абстрактного класса DNN. В данном коде метод Instance() возращает экземпляр провайдера СУБД и производит дальнейшее выполнение метода самостоятельно внутри провайдера. Метод GetAffiliate является абстрактным методом и частью правил соглашения при взаимодействии абстрактного базового класса DataProvider и провайдера для конкетной СУБД. В следующей строке кода провайдера для MS SQL сервера видно, как данный метод реализуется:

public override IDataReader GetAffiliate(int AffiliateId, int VendorId, int PortalId) { return SqlHelper.ExecuteReader(ConnectionString, DatabaseOwner + ObjectQualifier + "GetAffiliate", AffiliateId, VendorId, GetNull(PortalId)); }

49

В этом коде используется SqlHelper, являющийся частью Microsoft Data Access Application Block. В DotNetNuke данная биб-лиотека используется для увеличения производительности и уменьшения пользовательского кода в провайдере для обращения к данным. Microsoft Data Access Application Block является компо-нентом .Net, работающим с технологией ADO.Net. Данный компо-нент производит вызов хранимых процедур и выполнение SQL-команд на стороне сервера баз данных.

Слой данных обеспечивает данными слой доступа к данным. СУБД, используемые на этом уровне, должны поддерживаться реа-лизацией для данной СУБД специфическим API, унаследованным от базового класса Data Provider в DNN, чтобы полноценно реали-зовывать все запросы данных. Включенный в прикладной API набор SQL-скриптов создает в процессе инсталляции DNN базу данных. Дан-ные скрипты прописывают таблицы базы, хранимые процедуры и необходимые данные для запуска системы управления контентом. Инсталляционные скрипты запускаются на выполнение только при новой инсталляции DNN методом DotNetNuke.Services.Upgrade. Upgrade.InstallDNN. Скрипты следующие:

• DotNetNuke.SetUp.SqlDataProvider. Данный скрипт производит подготовку базы данных к инсталляции, ограничиваясь установкой ключевых таблиц;

• DotNetNuke.Schema.SqlDataProvider. Формирует в базе данных таблицы и хранимые процедуры;

• DotNetNuke.Data.SqlDataProvider. Производит заполнение таб-лиц базы данных DNN данными для функционирования системы.

Для последующих обновлений или модернизаций после началь-ной установки, коллекция скриптов, которые модифицируют схему базы или текущие данные в процессе обновлений, используют ме-тод DotNetNuke.Services.Upgrade.Upgrade.UpgradeDNN.

Перечисленные скрипты написаны на языке SQL, но используют два важных тега не относящиеся к SQL – {databaseOwner} и {ob-jectQualifier}. Данные теги с точки зрения программы представляют переменные, значение которых может меняться. Например, следу-ющий код создает хранимую процедуру в базе данных:

CREATE PROCEDURE {databaseOwner}{objectQualifier}GetSearch Settings.

Значения указанных тегов в строке возвращаются из файла web.config. Если значение databaseOwner = dbo и значение objectQualifier = DNN_, то действительное название хранимой про-

50

цедуры будет выглядеть так: dbo.DNN_GetSearchSettings. Тег object Qualifier используется в части реализации в системе управления контентом многопортальности, используя при этом только одну базу данных. Так как для каждого нового портала создается свой набор таблиц, хранимых процедур и триггеров, то в одной базе данных ко всем именам созданных объектов приписывается назва-ние данного портала.

Перейдем к рассмотрению следующей важной архитектурной компоненты системы управления контентом DotNetNuke – безо-пасность. Здесь разработчиками применяются лучшие методы, ко-торые реализовывались на протяжении всех версий данной CMS и которые работают в сочетании с методами родительской плат-формы – ASP.Net. Результатом является расширяемая модель безо-пасности, которая ставит DNN в этом направлении в один ряд c пе-редовой практикой ASP.Net.

Как мы уже говорили, DNN является многопортальной системой управления контентом. Данная многопортальность реализуется на одном экземпляре базы данных. Каждый портал должен распо-лагать собственным набором пользователей и ролей, которые не имеют доступа к другому порталу. Портал в базе данных иденти-фицируется по уникальному ключу PortalID. Поскольку провайдер членства по умолчанию в DNN взят из ASP.Net и является унаследо-ванным решением, он в принципе не поддерживает систему учет-ных записей и ролей, необходимую для многопортальности в од-ной базе данных. Для преодоления такого унаследованного плат-форменного ограничения в DNN реализована программная оболоч-ка для провайдера данных, через который работает провайдер членства. Эта оболочка реализует поддержку прикладной виртуа-лизации, в результате чего стандартный провайдер членства ASP.Net становится способным создавать пользователей и роли для многих порталов. Для достижения полной реализации провайдера членства важно знать, какую пользовательскую информацию мож-но провести в базу DNN, не зависящую от главного хранилища. Например, DNN может использовать Microsoft SQL Server как базу данных для хранения контента и системных настроек, но провай-дер членства также может использовать аутентификацию Windows, LDAP или другой механизм реализации аутентификации и авторизации. Поскольку реализация безопасности основывается на модели провайдеров, становится очень важным, чтобы конкрет-ная реализация механизма для поставщика членства не меняла код

51

или таблицы базы данных, используемые провайдером. Также дан-ные таблицы должны быть не зависимы от других таблиц уровня ядра DNN. Этот подход ограничивает применение встроенных ме-ханизмов синхронизации или каскадной целостности данных таб-лиц DNN и данных провайдера членства внутри базы. По этой при-чине механизмы синхронизации реализованы на уровне модулей прикладной логики DNN.

Проблема существовала в реализации применения провайдера членства и касалась разнородной поддержки областей самим про-вайдером и ядром DNN.

Что не мог поддержать провайдер, поддерживало ядро DNN. Как в идеале планировали разработчики, можно было полностью заме-нить таблицы аутентификации и авторизации базы DNN таблица-ми провайдера членства. Но данная цель не была достигнута по причине массовой привязки таблиц аутентификации DNN к су-ществующим и необходимым особенностям в приложении. Напри-мер, в таблице базы данных DNN «Пользователи» присутствует столбец UserID, содержащий глобальный уникальный идентифика-тор для каждого пользователя. Данный идентификатор использу-ется во всех основных модулях DNN и модулях, разработанных тре-тьими фирмами. В провайдере членства ASP.Net такого атрибута не существует, и это создавало самую большую проблему в его ис-пользовании. Аналогом атрибута UserID в таблицах провайдера членства является атрибут Username, выступающий в качестве уникального ключа в пределах применяемого приложения. Таким образом, команде разработчиков необходимо было найди метод поддержки данных атрибутов в синхронной работе провайдера членства ASP.Net и модели аутентификации DNN. Решение было найдено путем создания дополнительных таблиц базы данных для размещения необходимых атрибутов безопасности DNN, которыми не мог управлять провайдер членства. Такая модель данных реали-зовывалась без создания отношений между таблицами, за связи от-вечает программный код уровня логики работы приложения (рис. 7). Хотя этот подход построения модели данных приводит к наруше-нию основного правила – «одни данные в одном месте», полное представление о пользователе в DNN можно получить, собрав ин-формацию из всех таблиц, обеспечивающих инфраструктуру без-опасности в системе управления контентом. В дополнение к агре-гации данные в таблицах, используемые провайдером членства и ядром DNN, должны автоматически синхронизироваться. В ASP.Net

52

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

Рис. 7. Таблицы БД аутентификации провайдера членства и ядра DNN

Важной частью архитектуры системы управления контентом

DNN является пространство имен классов. Перечислим их: 1. DotNetNuke.Common – применяется всем классами, работаю-

щими внутри приложения DotNetNuke. Например, глобальные кон-

53

станты, которые могут использоваться на уровне всего портала или приложения, можно обнаружить в DotNetNuke.Common.Global class.

2. DotNetNuke.Data – используется всеми классами, имеющими отношение к уровню доступа к данным. Например, базовый класс доступа к данным, реализующий API провайдера данных, находит-ся в данном пространстве имен.

3. DotNetNuke.Entities – используется классами, которые пред-ставляют и управляют пятью сущностями, определяющими портал DNN. Сюда входят узел, порталы, таблицы, пользователи и модули. Пространство имен Modules, находящихся внутри DotNetNuke.Entities, является начальной стадией обеспечения функциональности ад-министративных модулей управления. Для общих наружных поль-зовательских модулей создано отдельное пространство имен вто-рого уровня DotNetNuke.Modules.

4. DotNetNuke.Framework – начальная библиотека для не-скольких базовых классов и утилит, используемых в приложении DotNetNuke.

5. DotNetNuke.Modules – пространство имен, используемое для ор-ганизации портальных модулей. Дочернее пространство имен в корне DotNetNuke.Modules.Admin применяется модулями уровня админи-стрирования. Для примера, модуль настройки узла Host Setting напи-сан в классе DotNetNuke.Modules.Admin.Host.HostSettingsModule class.

6. DotNetNuke.Security – используется программными классами авторизации и аутентификации. Здесь написаны методы для рабо-ты с правами для страниц, модулей, каталогов, групп и других классов безопасности.

7. DotNetNuke.Services – используется любой службой, которая обеспечивает ту или иную функциональность ядра CMS для моду-лей. В данном пространстве имен находится дочернее простран-ство для управления локализацией, персонализацией, поиском, ис-ключениями выполнения кода и другими функциями системы управления контентом.

8. DotNetNuke.UI – используется всеми классами, работающими с пользовательским интерфейсом. Для примера, классы шаблона и кон-тейнеров можно найти в пространстве имен DotNetNuke.UI.Skins.Skin и DotNetNuke.UI.Containers.Container соответственно.

Итак, рассмотрев основные компоненты архитектуры DNN, кратко резюмируем ключевые моменты:

• паттерн проектирования приложений на основе модели про-вайдеров значительно увеличил функциональные возможности

54

расширения системы управления контентом DNN без необходимости изменения ядра системы для реализации такой расширяемости;

• использование модели объектов прикладной логики (CBO) в сочетании с гидратором CBO (CBO Hydrator) создает фундамент лучших практик и стандартов для программистов, позволяющий создавать гибкие модули и провайдеры с большой производитель-ностью программирования и обслуживания;

• провайдер членства DNN реализует расширяемую модель безо-пасности с интерфейсом прикладного программирования (API), зеркально отражающий таковой в ASP.Net;

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

2.1.4. Функциональная структура административных средств управления DNN

Перейдем к рассмотрению структуры DNN относительно ее

пользовательского интерфейса управления. Конечно же, данная структура из версии к версии претерпевает некоторые изменения, причем иногда значительные. Поэтому мы будем рассматривать самую последнюю на момент написания этого учебного пособия стабильную версию DNN – 7.3.3.

Средства управления сайтом и узлом DNN доступны для пользо-вателей, обладающих правами администратора. Данный интерфейс называется административной панелью управления или консолью (рис. 8). Администраторы делятся на две категории – администра-торы уровня отдельного сайта и администраторы всего узла DNN. В контексте DNN администратор узла работает под учетной запи-сью host, ему доступны права управления всеми сайтами, разверну-тыми на данном узле, а также инсталляция или удаление модулей расширения функциональности. Это самые востребованные права в процессе эксплуатации DNN. Учетная запись host, конечно, имеет гораздо больше возможностей влияния на работу всего узла, кото-рые мы рассмотрим позднее.

При входе на портал DNN под учетной записью admin или host административная панель отображается одним компактным рядом и включает в себя ряд меню:

• администратора сайта (Admin);

55

• администратора узла (Host); • меню инструментов (Tools); • помощь (Help); • управление модулями (Modules); • управление страницами (Pages); • управление пользователями (Users).

Рис. 8. Административная панель управления DNN

Меню администратора сайта и администратора узла содержит

три области: основные настройки, дополнительные настройки и закладки. В каждой области находятся кнопки запуска модулей, различающиеся у каждого администратора. В закладки попадают кнопки запуска модулей в зависимости от предпочтения админи-стратора при нажатии на соответствующий значок «Добавить в за-кладки». Рассмотрим основные модули администратора сайта (рис. 9):

• просмотр событий (Event Viewer); • управление ролями (группами) безопасности (Security Roles); • управление файлами (File Management); • управление страницами (Page Management); • управление учетными записями пользователей (User Accounts); • корзина (Recycle Bin); • настройки сайта (Site Settings).

Рис. 9. Меню административной панели с основными опциями для администратора сайта

Модуль «Просмотр событий» обеспечивает отображение журнала регистрации событий сайтов, генерируемых планировщиком зада-ний, исключениями выполнения кода, управлением пользователями,

56

изменениями на страницах и модулях, активностью пользователей и групп безопасности и многими другими компонентами DNN.

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

Модуль «Группы безопасности» предназначен для создания и контроля групп пользователей с распределением прав доступа между ними. В DNN уже присутствует ряд групп по умолчанию:

• администраторы (Administrators). Пользователи, включенные в данную группу, обладают неограниченными правами по управ-лению конкретным сайтом;

• зарегистрированные пользователи (Registered Users). В дан-ную группу автоматически заносятся пользователи, прошедшие одобрение при регистрации на сайте;

• подписчики (Subscribers). Является публичной группой, поль-зователи попадают в нее автоматически после прохождения про-цедуры регистрации;

• переводчики (Translator). Предназначена для пользователей, в функции которых должен входить перевод контента на сайте;

• не прошедшие проверку (Unverified Users). В данную группу администратором заносятся пользователи, которые зарегистриро-вались на сайте, но пока не одобрены для использования своей учетной записи.

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

57

ния в таблицу доступа. Кроме того, в модуле есть возможность груп-пировать созданные группы по категориям, которые также можно создавать. По умолчанию в системе управления контентом суще-ствуют две категории групп ролей – глобальные группы и все группы.

Модуль «Управления файлами» в меню «Администратор» предна-значен для загрузки либо удаления файлов с различным типом рас-ширения, предназначенных для работы с конкретным сайтом (рис. 10). Следует отметить, что и в меню администратора узла (host) присут-ствует файловый менеджер, но его область видимости каталогов го-раздо шире. По умолчанию в файловом менеджере на уровне сайта есть несколько каталогов: картинки (Images); шаблоны (Templates); пользователи (Users). Администратор имеет возможность создать любое количество каталогов. Функциональность для управления ка-талогами в менеджере есть в верхней строке меню модуля и в кон-текстном меню при нажатии правой кнопкой мыши. Особенностью файлового менеджера DNN является то, что он позволяет создать три типа каталогов для хранения файлов: стандартный каталог, каталог безопасности и каталог, находящийся в базе данных портала.

Рис. 10. Интерфейс модуля файлового менеджера

58

Последний тип каталога реализует хранение всех загружаемых в него файлов в MS SQL Server, т.е. не в файловой системе. В файловой системе мы увидим сам каталог, без файлов. Следует отметить, что лучшей практикой считается создание каталогов сайта именно через файловый менеджер DNN, а не путем прямого добавления в папку \Portals\0, так как в такой ситуации сайт может не «увидеть» каталог. Более того, все названия каталогов и файлов помещаются в базу данных для контроля безопасности загружаемого контента.

Административный модуль «Управление страницами» (Page Mana-gement) выполняет функциональность обзора и управления всеми страницами портала и узла в целом (рис. 11). Страницы отображаются в иерархической структуре с возможностью вызова контекстного меню для выполнения стандартных операций над страницами: про-смотр страницы, свойства страницы, удаление страницы, добавление страницы. Выделяя страницу, мы получаем свойства с группировкой в правой части модуля с возможностью внесения необходимых изме-нений. Свойства страницы группируются по следующим признакам: основные (Сommon); безопасность (Permission); модули (Modules); поисковая оптимизация (SEO); метатеги (Metatаgs); внешний вид (Appearance); ссылка (Link). Подробно разберем данные категории настроек в разделе технологии создания веб-страниц.

Рис. 11. Модуль «Управление страницами»

59

В административном меню располагается ссылка на страницу с модулем «Корзина» (Recycle Bin). В корзину попадают страницы и модули, которые были удалены с сайта с регистрацией даты и времени удаления (рис. 12). Модуль обеспечивает стандартную функциональность по восстановлению удаленного объекта или полного удаления с узла. Модуль «Корзина» может быть добав-лен на любую страницу сайта. Незарегистрированные пользова-тели, имеющие права на просмотр данной страницы, могут уви-деть детальную информацию об удаленных страницах и модулях, но не смогут выполнить операции по восстановлению или удале-нию объектов.

Рис. 12. Модуль «Корзина» (Recycle Bin)

Окно модуля состоит из двух вкладок – страницы и модули. Сле-

дует отметить, что при удалении страницы модули, расположен-ные на ней, попадают в соответствующую вкладку корзины. Кроме

60

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

Административный модуль «Учетные записи пользователя» (User Accounts) позволяет создавать учетные записи, управлять за-регистрированными на сайте пользователями и распределять их роли безопасности (рис. 13). Данный модуль имеет статус «преми-ум», т.е. при создании нового сайта он не назначается ему автома-тически, найти его в списке модулей при добавлении не получится. Список пользователей представлен в табличном виде с возможно-стью поиска по многим заданным критериям.

Рис. 13. Модуль «Управление пользователями»

У каждой учетной записи пользователя есть опции по измене-

ниям данных, которые в дополнительном окне группируются на нескольких вкладках: управление учетной записью (Manage Ac-count); управление группами пользователя (Manager Roles for this User); управление паролем (Manager Password); управление дан-ными профиля пользователя (Manage Profile) (рис. 14). На вклад-ке «Управление учетной записью» администратор может обнов-лять либо удалять отображаемое имя, адрес электронной почты. Также здесь присутствуют значимые с позиции администратора данные о состоянии учетной записи пользователя, такие как дата создания записи, дата последнего входа на сайт и т.д. Админи-стратор может авторизовать пользователя либо отозвать его ав-торизацию (UnAuthorize), сделать запрос на изменение пароля (Force Password Change) или дать ему права администратора сай-та (Make SuperUser).

61

Рис. 14. Окно управления состоянием и данными пользователя

Рассмотрим подробно один из самых важных конфигурацион-ных модулей сайта DNN – «Настройки сайта» (Site Settings) (рис. 15). Данный модуль позволяет конфигурировать основные и дополни-тельные параметры сайта, включая оформление, внешний вид, пла-тежную систему, удобство использования, регистрационные дан-ные и т.д. Если на сайте используются несколько языков, парамет-ры настройки могут формироваться для каждого из них. Настройки сайта имеют структуру, состоящую из следующих групп: основные настройки (Basic Settings); дополнительные настройки (Advanced Setting); настройки учетных записей (User Account Settings); табли-ца стилей (Stylesheet Editor); дополнительные настройки URL (Ad-vanced URL Settings).

В основных настройках сайта мы имеем несколько разделов: • описание сайта; • маркетинг сайта; • внешний вид сайта. В разделе описания сайта вводится информация о названии

сайта, его описание, ключевые слова. Как правило, описание и клю-

62

чевые слова вводятся для поисковых систем с целью его SEO-оптимизации. Соответственно, данные параметры применяются в зависимости от выбранного языка.

Рис. 15. Модуль настроек сайта

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

В разделе настроек «Маркетинг сайта» (Site Marketing) опреде-ляется поисковая система, которая будет индексировать контент сайта, указывается страница с размещением карты текущего сайта. Здесь определяется, могут ли использоваться баннеры сайта или баннеры, которые транслируются на все сайты узла DNN. Также в данном разделе осуществляется проверка текущего сайта на предмет подписки в Google Webmaster Tools, инструментов для веб-мастера от Google. В текстовое поле Verification вводится имя HTML-файла для проверки подлинности, которое генерируется при регистрации на сервисе Google Webmaster Tools. «Инструменты

63

для вебмастеров» от поисковой системы Google не только позво-ляют получить ценную информацию, но и дают рекомендации по устранению всех недоработок.

Необходимо знать, что использование «Инструментов для веб-мастеров» не дает привилегий от поисковой системы, но правиль-ное применение позволит настроить сайт для повышения ранжи-рования в популярной поисковой системе Google.

«Инструменты для веб-мастеров» предлагают следующую функциональность: понять, какие проблемы возникли при скани-ровании роботом сайта; сообщить Google о файле Sitemaps; создать и проанализировать файл robots.txt; удалить URL, уже просканиро-ванные Googlebot; выбрать основной домен; проверить правиль-ность метатегов <title> и <description>; просматривать наиболее частые поисковые запросы; увидеть свой сайт так, как его видит Googlebot; удалить нежелательные ссылки сайта, которые Google может показывать в результатах поиска; получать уведомления о нарушении рекомендаций Google по обеспечению качества и от-правлять заявки на пересмотр сайта.

В разделе основных настроек «Внешний вид» (Appearance) уста-навливается лого или эмблема сайта, картинка фона страниц и символизирующая иконка (FavIcon). Лого сайта отображается в са-мой верхней части сайта на каждой веб-странице, к нему применя-ется стандартный шаблон оформления (рис. 16). Отображение лого зависит от специального элемента управления DNN, внедряемого при разработке шаблонов оформления в задуманные дизайнером части. Поэтому место отображения лого в зависимости от применя-емого шаблона может быть разным. Символизирующая иконка яв-ляется файлом с расширением .ico 16×16 пикселей, связанная с осо-бым сайтом или страницей. Отображается данная иконка в адрес-ной строке браузера в самом начале URL.

Метод добавления того или иного файла в данном разделе прост. Выбирается каталог расположения файла и сам файл. При отсутствии нужного графического файла его тут же можно загру-зить, нажав на кнопку Upload File.

В данном разделе настроек также активируется применение до-ступных шаблонов оформления для всех страниц сайта и контей-неров модулей. Шаблоны могут применяться как для режима отоб-ражения, так и для режима редактирования модулей. Это обуслов-лено скоростью загрузки шаблонов, и в режиме редактирования следует выбирать самый простой по дизайну. На уровне отдельной

64

страницы DNN позволяет применять любой другой шаблон оформ-ления независимо от установок по умолчанию.

Рис. 16. Раздел «Внешний вид» модуля настроек сайта Дополнительные настройки (Advanced Settings) модуля

«Настройки сайта» (Site Settings) включают следующие группы настроек:

• управление страницами (Page Management); • параметры безопасности (Security Settings); • параметры платежной системы (Payment Settings ); • параметры удобства использования (Usability Settings); • псевдонимы сайта (Site Aliases); • параметры сервера SMTP (SMTP Server Settings);

65

• параметры SSL (SSL Settings); • параметры сообщений (Messaging Settings); • параметры узла (Host Settings). В группе настроек «Управление страницами» (Page Management)

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

В группе настроек «Настройки безопасности» (Security Settings) указывается пользователь, который будет выполнять роль адми-нистратора данного сайта, а также предоставляется возможность скрыть окно для ввода логина и пароля пользователя.

В группе настроек «Настройки платежной системы» (Payment Settings) выбирается платежный процессор, который по умолчанию будет использовать данный сайт, тип валюты, регистрационные данные пользователя в платежной системе, ссылки для перехода на страницы электронных платежных систем в интернете.

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

В группе настроек псевдонимов сайта (Site Aliases) настраиваются имена, которые может иметь текущий сайт. Привязка псевдонима может быть нескольких типов – как есть и «перенаправление». По умолчанию псевдонимы сайта добавляются автоматически.

В группе настроек параметров сервера SMTP (SMTP Server Set-tings) прописывается адрес и порт почтового сервера для отсылки сообщений. Данные настройки могут применяться с учетом пара-метров, указанных на уровне узла, в такой ситуации в этой группе настраивать ничего не надо. На уровне индивидуальных настроек портала также указывается предельное число подключений к сер-веру, время ожидания и аутентификационные данные пользовате-ля почты. Функциональность DNN по сопряжению с почтовым сер-вером также реализует SSL-шифрование передачи сообщений. Вне-сенные параметры настройки можно протестировать.

В группе настроек «Параметры SSL» (SSL Settings) указываются опции по работе на сайте по зашифрованному протоколу. Включе-

66

ние функциональности возможно, если порталу присвоен SSL-сертификат и веб-страницы помечаются как безопасные. Если на сервере IIS узел DNN не настроен на работу по HTTPS-протоколу, то необходимо в настройке SSL URL произвольно определить URL, который будет использоваться для безопасных соединений. При активировании такой настройки также нужно указывать про-извольный URL-адрес для небезопасных соединений, т.е. по обыч-ному HTTP-протоколу.

Параметры сообщений (Messaging Settings) определяют актив-ность пользователя сайта по передаче сообщений. Здесь указыва-ются такие параметры, как: интервал передачи сообщений, макси-мальное число пользователей, которым одновременно можно от-править сообщения, фильтр неприемлемых слов. Также админи-стратор может разрешить или не разрешить прикреплять файлы к сообщениям, а также отправлять электронную почту.

Группа настроек «Параметры узла» (Host Settings) позволяет ад-министратору портала внести ряд ограничений на использование ресурсов сайта: дата истечения аренды хостинга; сумма месячной платы за использование сайта; размер выделенного дискового про-странства; количество страниц, которое может быть создано на сайте; количество пользователей, которые могут зарегистриро-ваться; ограничение дней на запись журнала событий; модули, ко-торые могут быть доступные сайту.

На вкладке модуля настроек сайта «Настройки учетных запи-сей» (User Account Settings) указываются параметры поведения ак-каунтов. Кратко – это режим и сложность регистрации, форматы адресов электронной почты пользователя и пароля, настройки входя пользователя на сайт, использование CAPTCHA, установки свойств профиля пользователя. Следует отметить, что поля профи-ля можно добавлять, указывая свойства через детализированное окно параметров.

Администратор может гибко и детально управлять текущим стилем оформления сайта через редактор таблиц стилей на вклад-ке модуля Stylesheet Editor. В данном редакторе отображается раз-метка CSS, которую содержит файл в пакете шаблона оформления, примененный к порталу. Редактор позволяет вносить изменения в таблицу стилей и применять изменения к порталу, не перезапи-сывая при этом основной файл шаблона оформления. Таблица сти-лей по умолчанию может быть восстановлена в любое время, одна-ко это удалит любые модификации, сделанные в редакторе.

67

На вкладке модуля настроек сайта Advanced URL Settings указы-ваются установленные расширения CMS, которые управляют фор-матом URL или дружественным представлением адресов. Данные провайдеры позволяют администраторам расширять поведение адресов URL для определенного модуля. По умолчанию такие про-вайдеры не установлены, но они могут быть загружены с ресурса Codeplex.com.

Мы подробно рассмотрели основные инструменты администра-тора портала. Теперь перейдем к рассмотрению дополнительных инструментов. Ввиду ограничения объема данного учебного посо-бия опишем подробно только дополнительные конфигурационные параметры. Остальным инструментам дадим только краткую опи-сательную характеристику. Для подробного изучения всех пара-метров инструментов администратора сайта и администратора уз-ла (суперадминистратора), зависимостей и тонкостей настроек ав-тор рекомендует изучить руководства администратора и супер-пользователя платформы DNN 7.3 [23].

Меню дополнительных параметров администратора сайта пока-зано на рис. 17.

Настроечные модули: • дополнительные параметры конфигурации (Advanced Configu-

ration Settings); • языки сайта (Languages); • карта сайта для поисковой системы (Search Engine Site Map); • шаблоны оформления (Skins);

Рис. 17. Меню административной панели с дополнительными опциями для администратора сайта DNN

68

• управление мобильными устройствами для предварительного просмотра прорисовки контента (Device Preview Management);

• списки (List); • журнал статистики сайта (Site Log); • таксономия (Taxonomy); • расширения портала (Extensions); • новостная рассылка (Newsletters); • управление перенаправлениями сайта (Site Redirections Man-

agement); • разработчики (Vendors); • анализатор Google (Google Analytics); • настройки поискового механизма сайта (Search Admin); • мастер сайта (Site Wizard). Модуль дополнительных параметров конфигурации (Advanced

Configuration Settings) предоставляет администратору сайта аль-тернативное место расположения модулей для настройки. В модуле содержатся следующие вкладки:

• шаблоны оформления (Scins & Containers); • SMTP-сервер (SMTP server); • языковые пакеты (Language Packs); • системы аутентификации (Authentication Systems); • провайдеры (Providers); • дополнительные модули (Optional Modules). Настройки шаблона оформления сайта позволяют установить

необходимый дизайн. При указании типа шаблона (Skin Type) в выпадающем списке отображаются установленные пакеты шаб-лонов (рис. 18). Пакет позволяет применить тот или иной дизайн к страницам и (или) контейнерам, указывая его название в выпа-дающих списках. Дизайн может применяться в зависимости от ре-жима отображения. Например, для режима редактирования стра-ниц требуется быстрая прорисовка для снижения времени приме-нения настроенных параметров. Здесь целесообразнее применять легкий шаблон без всякой графики.

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

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

69

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

Рис. 18. Выбор и применение шаблонов оформления (дизайна) DNN На вкладке модуля «Языковые пакеты» (Language Packs) отоб-

ражаются установленные языковые пакеты. Если необходимо ис-пользовать на сайте более одного языка, то здесь можно выбрать нужный. Пакеты позволяют пользователям просматривать опре-деленную информацию на предпочтительном языке. Эта информа-ция включает имена полей DNN и справочную информацию, сооб-щения, такие как приветственные письма, или напоминания о пароле, или данные для текущей даты и времени. Так как система управления контентом по своей архитектуре является мульти-язычной CMS, возможна инсталляция других языков. Пакеты, до-ступные для загрузки, располагаются на официальном сайте си-стемы. Также в DNN достаточно развита технология создания соб-ственных языковых пакетов.

На вкладке «Системы аутентификации» (Authentication Systems) отображаются доступные пакеты, которые можно применить для текущего сайта. Данные модули обеспечивают реализацию ал-горитмов проверки подлинности для таких ресурсов, как Facebook, Google, Windows Live, Twitter.

70

На вкладке «Провайдеры» (Providers) показаны доступные модули провайдеров, обеспечивающие различные варианты навигации по меню сайта. Навигация различается в зависимости от применяе-мых элементов управления ASP.Net, например Drop Down (выпадаю-щих список), TreeView, DNNTree (древовидная структура), SolpatMenu.

Модуль «Языки сайта» (Languages) позволяет администраторам устанавливать многоязыковой сайт, управлять переводами и фай-лами языка.

Модуль «Карта сайта для поисковой системы» (Search Engine Site Map) позволяет администратору настроить карту сайта для пред-ставления поисковым системам с целью улучшения поисковой оп-тимизации. Файлы карты сайта, сгенерированные встроенным для этих целей провайдером DNN, полностью совместимы со спе-цификацией протокола. Провайдер карты сайта для DNN позволяет любому DNN-модулю включаться в генератор карт от различных поисковых систем, например Google, Yahoo, Bing.

Модуль «Управление мобильными устройствами для предвари-тельного просмотра прорисовки контента» (Device Preview Man-agement) предоставляет администратору сайта функциональность для предварительного просмотра их сайта при прорисовке на раз-личных мобильных устройствах. Списки профилей предваритель-ного просмотра для большинства используемых устройств вклю-чены по умолчанию и могут быть отредактированы или удалены. Новые профили предварительного просмотра также могут быть созданы с нуля или с использованием предварительно сконфигу-рированного списка общих профилей.

Модуль «Списки» (List) позволяет администраторам вести списки информации, которая может быть идентифицирована значением ключа и значением данных. Список использует структуру списков и записей, которые являются в действительности одним и тем же, но их использование определяет их различия:

1. Список является набором записей, у которого есть ключевой идентификатор и данные.

2. Запись является отдельным элементом данных, которые ка-саются списка и составлены из ключевого идентификатора и части данных. Например, список стран, используемый в DNN. Список – «Страны», записи – фактические страны (например, Австралия, Англия, Голландия).

3. Записи также могут быть и списком. Пример этого – список областей, используемый в DNN. В этом случае страна, которая

71

является записью в соответствии со списком стран, может быть его собственным списком и связывать записи областей.

Модуль «Журнал статистика сайта» (Site Log) реализует стати-стическую отчетность по работе портала, состоящую из 12 отчетов. В каждом отчете для анализа информации устанавливается диапа-зоном дат в сравнении предыдущим периодом (по дням, неделям, месяцам), будучи настройкой по умолчанию. Администратор узла DNN может отключать сбор статистики посещаемости, а также устанавливать период сбора информации.

Модуль «Таксономия» (Taxonomy) предоставляет возможность создавать словари терминов (теги) с последующим присоединени-ем к веб-страницам или модулям с публикацией в виде кон-текстных списков. Таксономия улучшает навигацию по сайту и контекстный поиск контента. Менеджер таксономии может быть добавлен к любой странице сайта.

Модуль «Расширения портала» (Extensions) позволяет админи-страторам управлять расширениями, которые установлены на узле и используются на сайте. Из соображений безопасности Extensions-модуль может быть добавлен только к страницам сайта суперполь-зователя (host). Администраторы могут выполнить все дополни-тельные задачи управления расширениями. Пользователи, которым предоставили права редактирования на модуль «Расширения порта-ла» (Extensions), могут просмотреть основную информацию об уста-новленных расширениях и обновить некоторые настройки аутенти-фикации. Пользователи, которым предоставили права редактирова-ния на страницу расположения модуля, могут просмотреть дополни-тельную информацию об установленных расширениях.

Модуль «Новостная рассылка» (Newsletters) отсылает членам одной или более ролей безопасности и/или на один или несколько адресов электронную почту (новостные рассылки). Сообщения от-правляются каждому получателю отдельно для исключения ин-формации о деталях рассылки. Модуль идентифицирует много-кратную рассылку и гарантирует, что только одна копия новостной рассылки будет отправлена адресату. Сообщение может быть или простым текстом, или в формате HTML. К сообщениям могут быть присоединены файлы и включены заменяющие маркеры. Отчет об успешном состоянии или ошибках отправки появляется сразу по-сле передачи сообщения на сервер SMTP. Характер отчета об от-правке сообщений зависит от типа передачи, которая может быть синхронной или асинхронной.

72

Модуль «Поставщики» (Vendors) позволяет администраторам создавать и управлять учетными записями организации-поставщика, его баннерами и учетными записями филиала органи-зации. Созданные учетные записи организаций и их баннеры в дан-ном модуле распространяются только на этот конкретный сайт. Другой экземпляр модуля контроля организаций расположен на административной странице суперпользователя (host), которая позволяет ему создавать баннеры, отображаемые на любом сайте узла DNN. Баннеры могут быть с изображениями, текстом или сце-нарием. Они могут быть выведены на сайте с использованием мар-кера [BANNER] шаблона оформления или модуля Banners. Данный модуль собирает статистические данные об использовании банне-ров, включая отслеживание щелчков, времени просмотра и комис-сионные сборы. Модуль учета поставщиков может быть развернут на любой странице сайта, разрешающей другим пользователям управлять учетными записями организаций на данном сайте. Пользователи с полномочиями редактирования могут просматри-вать, искать и фильтровать данные учетные записи.

Модуль «Анализатор Google» (Google Analytics) дает возмож-ность проводить анализ и улучшать результаты поиска в системе Google. Аналитика Google – веб-решение для аналитики уровня предприятия, которое дает глубокое понимание трафика сайта и проведение маркетинга эффективности. Мощные, гибкие и про-стые в использовании функции позволяют полностью проанализи-ровать трафик современными методами.

Модуль настройки поискового механизма сайта (Search Admin) позволяет администраторам определять параметры настройки си-стемы поиска DNN. Функциональность модуля позволяет содержанию быть повторно индексированным, при наличии существенных изме-нений начиная с последней индексации, управлять списками слов-синонимов и выбирать слова, которые игнорируются при поиске.

Последний модуль в череде дополнительных инструментов администратора – «Мастер сайта» (Site Wizard). Реализует настройки основных параметров работы сайта, выбор дизайна оформления, шаблонов контейнеров для модулей, описания, ключевых слов для поиска и логотипа.

Перейдем к рассмотрению структуры DNN относительно адми-нистратора узла, или суперпользователя (host). Узел DNN может размещать большое количество сайтов, и настройки на данном уровне распространяются на каждый сайт.

73

Основные опции (рис. 19): • панель информации (Dashboard); • управление сайтами (Site Management); • расширения узла (Extensions); • управление файлами (File Management); • настройки узла (Host Settings).

Панель информации является средством просмотра основных

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

В разделе (модуле) «Управление сайтами» отображается список сайтов, развернутых на узле с основными характеристиками. Здесь можно добавить новый сайт, отредактировать свойства существующего и сохранить его шаблон оформления.

Раздел расширения узла (Extensions) полностью повторяет опи-санный модуль на уровне администратора сайта, но дает админи-стратору узла полные права по управлению его дополнительными модулями, провайдерами, библиотеками и шаблонами оформле-ния. Управление расширениями делится на несколько категорий: установленные расширения (Installed Extensions), доступные рас-ширения для установки на узел (Available Extensions), платные расширения (Purchased Extensions) и дополнительные расширения (More Extensions). Дополнительные модули отображаются списком, который формируется из данных, расположенных в магазине рас-

Рис. 19. Меню административной панели с основными опциями для администратора узла DNN

74

ширений DNN. Модуль расширений с правами администратора узла позволяет устанавливать новые модули, создавать новые расши-рения и модули. Расширения группируются по следующим призна-кам: система аутентификации, контейнер, языковой пакет ядра, элемент управления панелью информации, дополнительный язы-ковой пакет, библиотека скриптов Java, библиотека, модуль, про-вайдер, шаблон оформления, объект шаблона, виджет.

Модуль управления файлами также полностью аналогичен та-ковому на уровне сайта, за исключением появления дополнитель-ных папок для управления – Cache, Containers, EventQueue, Logs, Skins.

Настройки узла также разделяются на несколько разделов и групп внутри них. Это основные настройки узла (Basic Setting), дополнительные (Advanced Settings), другие (Other Settings) и лог-файлы (Logs).

В основных настройках присутствуют следующие группы пара-метров: конфигурация (Configuration), детали узла (Host Details), внешний вид (Appearance), настройки платежной системы (Payment Settings). В дополнительных настройках присутствуют следующие группы параметров: настройки дружественных URL (Friendly URL Settings); настройки прокси-сервера (Proxy Settings) и SMTP; производительность (Performance Settings); настройки JQuery (JQuery Settings); настройка распределения контента (CDN Settings); управление ресурсами клиента (Client Resource Management); управление параметрами членства (Membership Management); фильтр IP адресов (Login IP Filters); настройки поис-кового механизма (Search Settings). В разделе «Другие настройки» (Other Settings) находятся параметры для управления лог-файлами, расширениями и размером файлов для загрузки на узел, локализа-цией контента, генерацией ошибок. В разделе «Лог-файлы» (Logs) можно выбрать журнал за определенную дату, который регистри-рует ошибки во время запуска узла.

Дополнительные настроечные модули на уровне администра-тора узла (рис. 20):

• управление конфигурационными файлами (Configuration Manager);

• планировщик (Schedule); • управление активацией устройств (Device Detection

Management);

75

• SQL-запросы (SQL); • управление параметрами модуля HTML-редактора (HTML Editor

Manager); • учетные записи суперпользователя (SuperUser Accounts); • списки (List); • поставщики (Vendors).

Модуль управления конфигурационными файлами предназначен

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

Модуль планировщика (Schedule) запускает различные задачи по облуживанию узла в фоновом режиме. К таким задачам относятся, например, очистка кэша, буфера логирования для журналов собы-тий, индексация контента и т.д. В планировщике настраивается дата запуска задания, частота запуска, интервал времени переза-пуска в случае неудачного старта. У каждого задания в планиров-щике можно посмотреть историю его выполнения (рис. 21).

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

Рис. 20. Меню административной панели с дополнительными опциями для администратора узла DNN

76

Рис. 21. Модуль планировщика заданий узла DNN

Модуль настроек редактора HTML формирует конфигурацию

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

Модуль контроля учетных записей администраторов узла полностью повторяет модуль управления зарегистрированными пользователями на уровне администратора сайта, но предназначен для управления учетными записями только администраторов узла. Также полностью аналогичны по своей структуре модули «Списки» (List) и «Поставщики» (Vendors), отличие только в уровнях доступа и количестве редактируемых каталогов и функциональности.

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

77

2.2. Модули DNN, применимые к веб-представительству

Веб-представительство компании, как правило, многогранно. Оно может иметь в сети Интернет несколько тематических сайтов, например основной сайт компании и, как инструмент электронной коммерции, интернет-магазин. Также компания может организо-вать несколько тематических промо-сайтов для привлечения целе-вой аудитории. Этот подход к построению веб-представительства целесообразнее организовывать на многопортальной CMS с воз-можностью сквозного управления модулями на каждом сайте узла. Следует отметить, что модуль – это модульный фрагмент кода, предоставляющий возможности по расширению веб-приложения. Анализ различных веб-сайтов компаний показал наличие следую-щей необходимой функциональности или модулей, ее реализую-щих: новости, анонсы; RSS-лента (News Feeds); HTML-модуль; блог; документы; вопрос-ответ (FAQs); обратная связь (FeedBack); фо-рум; фотогалерея; ссылки; медиа; голосование; помощь; отчеты; онлайн-пользователи; интернет-магазин (Store).

Весь перечисленный модульный функционал достаточно силь-но развит в DNN. Причем большинство из перечисленных модулей являются базовыми, т.е. разрабатываются и поддерживаются ко-мандой программистов CMS DNN и распространяются бесплатно. До пятой версии DNN включительно базовые модули входили в установочный пакет DNN Community Edition. В последующих верси-ях (6 и 7) из внешних модулей (т.е. для посетителей) в пакет входит только HTML-модуль. Остальные можно загрузить с ресурса http://www.codeplex.com и установить на узел под правами супер-пользователя (host). Codeplex – это бесплатное решение в форме веб-сайта от компании Microsoft. Предназначен для размещения разработчиками проектов с открытым исходным кодом и взаимо-действия с широким кругом заинтересованных лиц с целью даль-нейшего развития программного кода сообществом.

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

Модули отличаются в первую очередь реализуемой задачей, набором функциональностей и качеством работы. У каждого базо-

78

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

Модуль электронного магазина (Store) легко устанавливается и персонализируется. Он позволяет быстро конфигурировать храни-лище электронной коммерции для использования покупателями, продажи продуктов и сервисов, используя CMS DNN. Хранилище электронной коммерции поддерживает товары, их категории, кор-зину, расчеты за доставку, налоги, многоканальные шлюзы, про-стые элементы для управления шаблоном оформления и формиро-вания стилей модуля.

Система шаблонов электронного магазина создает динамиче-ские страницы на основе тегов HTML и несколько каскадных таб-лиц стилей. Шаблоны по умолчанию и таблицы стилей XHTML сов-местимы и прошли необходимое тестирование в браузерах Internet Explorer 8 и Firefox 3.

Все метки и диалоги модуля соответствуют стандартам локализа-ции DNN, что обеспечивает возможности перевода на другие языки, подключение своих валют и налоговых ставок. Архитектура шаблона оформления модуля позволяет создать пользовательский дизайн и преобразовать его в собственный пакет, корректируя надписи кнопок и других элементов модуля под конкретную аудиторию покупателей. Рассматриваемый нами модуль электронного магазина предлагает администраторам DNN, разработчикам и проектировщикам сайтов мощную, гибкую и простую в использовании «витрину» электронной коммерции в духе лучших технологических решений DNN.

Рассмотрим процесс установки модуля интернет-магазина, ко-торый аналогичен для всех модулей расширения. Для установки необходимо зайти в портал под учетной записью суперпользовате-ля (host) и перейти в панель управления узла в закладку «Расшире-ния» (Extensions) (рис. 22).

В окне модуля запускаем расширенный мастер установки (Install Extension Wizard) и выбираем инсталляционный файл модуля элек-тронного магазина Store_03.01.07_Install.zip (последняя версия на мо-мент написания пособия). Предварительно инсталляционный файл магазина необходимо загрузить с ресурса http://dnnstore.codeplex.com.

79

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

Рис. 22. Меню установки дополнительных модулей в DNN

Для начала настроек модулей необходимо определить их кате-горию. В каталоге расширений вызываем свойство модуля, в поле «Категория модуля» (Module Category) выбираем «Основной» или «Административный».

Рис. 23. Модули интернет-магазина в списке модулей

Применяем сделанные настройки и после этого можем легко найти наши установленные модули магазина в меню добавления модулей на страницу (рис. 24). Опишем функциональную принад-лежность модулей магазина.

• Store Admin (администрирование магазина) – главный модуль для запуска электронного магазина в работу. Здесь осуществляются первоначальные настройки, где, помимо всего прочего, указываются страницы расположения каталога товаров и управления зареги-стрированными пользователями.

• Store Account (учетные записи) – обеспечивает управление ло-гинами заказчиков товаров, их платежными картами и возможно-стями выбора заказов.

80

• Store Catalog (витрина товаров) – обеспечивает загрузку и предоставление информации о товарах, управление отображением дополнительными детализированными данными.

• Store Menu (меню категорий товаров) – обеспечивает отобра-жение меню категорий выбора товаров.

• Store Mini Cart (корзина) – обеспечивает представление в кор-зине и свод выбранных товаров интернет-магазина для приобре-тения.

Перед началом настройки магазина необходимо определиться с названиями страниц расположения моделей Store Catalog и Store Account и, соответственно, создать их. Модуль Store Admin должен располагаться на отдельной странице портала, доступ-ной только администраторам. Технологию создания веб-страниц рассмотрим в следующем разделе. Перейдем к конфигурации магазина.

Рис. 24. Панель добавления модулей магазина на страницу

После добавление модуля конфигурации электронного магази-на на странице появятся поля опций специфической настройки. Если страница расположения модуля находится в режиме редакти-рования, то появятся специальные значки редактирования свойств модуля. Это свойства контейнера для модулей, и они есть у каждо-го модуля, если контейнер разработан с учетом стандартов DNN. При нажатии на иконку появится выпадающий список выполняе-мых действий над модулем: настройки; экспортировать контент; импортировать контент; помощь; разработка; удалить; обновить (рис. 25). Настройки состоят из нескольких вкладок: это настройки модуля, права доступа к модулю, настройки страницы по отноше-нию к модулям и специфические настройки функционального предназначения модуля. Настройки модуля подразделяются на не-сколько групп – основные и дополнительные.

81

К основным настройкам отно-сятся привязка модуля к языку, заголовок и теги. Дополнитель-ные настройки призваны отобра-жать модуль на всех страницах сайта, указывать, является ли он общедоступным, скрывать модуль при работе в режиме администра-тора, текст в верхнем и нижнем колонтитулах, начальную и ко-нечную дату отображения модуля на странице. Также в группе «До-бавлен на страницы» (Added to Pages) перечисляются страницы, кроме текущей, на которые до-

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

На последней вкладке производится настройка параметров функциональной принадлежности модуля (применительно к наше-му интернет-магазину мы рассмотрим их далее).

После добавления модуля «Администрирование магазина» (Store Admin) в поле Store Name указывается имя магазина. Поле Description – краткое описание направления торговли и того, что будет продаваться в интернет-магазине. Поле Keywords должно содержать разделенные ключевые слова, характеризующие про-дажи. Оба поля нацелены на поисковые системы. Опция SEO яв-ляется мощной функцией, которая включает автоматическую ге-нерацию скрытого кода, на который смотрят поисковые системы для индексирования веб-сайтов (метатеги). Ниже мы рассмотрим, как сконфигурировать шаблон SEO, чтобы получить самое эффек-тивное распознавание продуктов магазина поисковыми система-ми (рис. 26).

Рис. 25. Контекстное меню свойств модуля

82

Рис. 26. Окно начальных настроек магазина

Поле «Шаблоны портала» определяет, что шаблонные файлы

будут скопированы с общего хост-сервера на совместно использо-ванное шаблонное хранилище сайта, который конфигурируется для магазина. Любое изменение, которое вносится в шаблоны пор-тала, будет определено для этого портала и не будет удалено при последующем обновлении модуля электронного магазина. Это означает, что если новая версия модуля делает какие-то изменения в стандартные шаблоны, то администратор должен будет приме-нить эти изменения вручную после обновления. Отменять опцию «Шаблоны портала» (Portal Templates) целесообразно, если нужно использовать стандартный шаблон сайта или если есть необходи-мость в том, чтобы изменения применились ко всем сайтам в узле DNN. В последнем случае нужно сделать копию файлов шаблона, чтобы избежать откатывания после обновления. В случае наличия прав администратора на уровне конкретного сайта, где будет рас-полагаться магазин, необходимо активировать опцию «Шаблоны портала» для предоставления доступ к ним. Только у суперпользо-вателей узла (host) может быть доступ для размещения шаблонов конкретного сайта и шаблонов для всего узла.

83

Далее в модуле можно настроить различные параметры выбора товара покупателем, отображение информации о товаре на вит-рине магазина в зависимости от их состояния на складе. Например, при отсутствии товара на складе есть следующие варианты дей-ствия: принимать заказ для последующей закупки; скрыть кнопки для добавления товара в корзину; полностью убрать отсутствую-щий товар на складе с витрины магазина. Кроме того, есть опция Avoid Negative Stock, при активации которой производится провер-ка запасов товара на складе с целью предупреждения об отсут-ствии. Модуль позволяет назначить группу пользователей портала для управления заказами и каталогами товаров магазина, обеспе-чить шифрование cookie-файлов, запретить возможность настрой-ки доставки, позволить расчеты скидок. Затем модуль предлагает выбор и настройку провайдеров для ввода информации об адресе покупателя (Address Provider), налоговых ставок (Tax Provider), стоимости доставки (Shipping Provider) и способах оплаты (Payment Gateway). Способы оплаты, или платежный шлюз, модуль предла-гает в виде выпадающего списка доступных вариантов: AutoProvider; AuthorizeNetProvider; EmailProvider; PayPalProvider.

Платежный шлюз (Payment Gateway) представляет собой авто-матизированную систему для совершения платежей потребителя-ми услуг, проведения банковского эквайринга, а также для реали-зации прочих финансовых трансакций. Платежный шлюз предо-ставляет возможность обработки пользовательских трансакций – запросов на списания денежных средств с пластиковых карт и от-правки их в процессинг банка, осуществляющего операции через международные платежные системы.

Провайдер информации об адресе покупателя предоставляет возможность выбора полей для заполнения и порядковый номер их размещения друг за другом. Интерфейс провайдеров налоговых ставок и доставки товаров показан на рис. 27. Функциональность провайдера по налоговым ставкам позволяет настраивать значе-ния в зависимости от страны и региона заказов. В таблице провай-дера расчета доставки указывается информация о диапазоне веса товаров и цена за единицу расстояния доставки данного товара. В области настроек доставки должна быть сконфигурирована по крайней мере одна строка. Если ваша торговля в интернет-магазине не предполагает взимания платы за доставку, то необхо-димо обнулить минимальный вес и стоимость, а максимальный вес необходимо указать как 99999. После внесения всех необходимых

84

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

Рис. 27. Настройка провайдеров для расчета налогов и доставки

Пункты меню следующие: информация о магазине (Store Info);

заказы (Orders); категории (Categories); товары (Products); обзор (Reviews). На основании данного функционального меню следую-щим логическим шагом по настройке интернет-магазина будет до-бавление категорий товаров (рис. 28). Для этого нужно перейти в пункт «Категории» (Categories) и нажать на кнопку «Добавить ка-тегорию» (Add Category). На странице отобразятся поля ввода для заполнения, которые интуитивно понятны. Из особенностей формирования категорий товаров магазина следует отметить ввод данных для оптимизации под поисковые сервисы интернета (SEO Name, SEO Keywords) и возможность создавать дерево категорий продуктов, указывая родительскую категорию. Также возможно разработать качественное описание категории в многофункцио-нальном HTML-редакторе.

После формирования категорий нужно вводить в базу данных сами товары. Соответственно, переходим в пункт меню «Товары» (Products), выбираем соответствующую категорию и нажимаем на кнопку «Добавить товар» (Add Product).

Модуль магазина позволяет вводить достаточно обширное количество данных о товаре, что отражается на его привлекатель-

85

ности перед онлайн-покупателями. Это подробная информация о производителе, номере и имени модели, а также информация для SEO-оптимизации, краткая описательная характеристика, раз-личные типы цен, габариты товара при доставке, управление дан-ным товаром на складе, данные по специальным предложениям (акциям), периоду их действия и ценам. Можно внести большое ко-личество фотографий товара, создать подробную описательную характеристику в многофункциональном HTML-редакторе. После сохранения введенной информации товар появится на админи-стративной странице продуктов в виде таблицы в зависимости от выбранной категории. По каждой записи товара в таблице можно перейти в режим редактирования, нажав на ссылку Edit. Количе-ство наименований товаров, которое может быть введено в базу данных магазина, ограничивается только выделенным объемом дискового пространства или характеристикой работающей СУБД, выбранной для узла.

Рис. 28. Настройка категорий товаров

После ввода категорий и товаров необходимо разместить на за-ранее выделенной странице модули витрины (Store Catalog), меню категорий (Store Menu) и корзину (Store Mini Cart). Модули отдель-ные, но программно связаны между собой. Разграничение данной функциональности по отдельным модулям обусловлено прежде всего дизайнерскими соображениями, реализацией возможности их размещения на разных панелях страницы. Также предоставля-ется возможность вставить несколько одинаковых модулей, при-

86

менив к ним разные шаблоны оформления и фильтры для отобра-жения товаров. Например, один экземпляр модуля каталога или витрины отображает только новые товары, другой – все товары магазина в зависимости от выбранной категории. Каждый из пере-численных модулей имеет специфические настройки. Большое ко-личество настраиваемых параметров представляет витрина мага-зина, располагаются они на отдельной вкладке (рис. 29).

Рис. 29. Настройка витрины интернет-магазина

Специфические настройки витрины также сгруппированы по нескольким категориям: основные параметры; настройки кате-горий продуктов; поисковые настройки; параметры сортировки; настройки для отображения детальной информации о товаре. Основные параметры предлагают выбор типа шаблона дизайна, использования категории товаров по умолчанию. Если указана ка-тегория по умолчанию, то при каждом новом посещении магазина витрина будет отображать товары только указанной категории. Также можно задать отображение лозунга категории, продуктов и их детального описания, новых, популярных и будущих поставок товаров, позволять посетителям распечатывать информацию о то-варе, производить индексацию контента, включать кэширование фотографий товаров с определением времени перезаписи кэша.

87

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

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

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

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

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

88

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

Рис. 30. Отображение введенных товаров в модуле витрины интернет-магазина

Рис. 31. Настроенные модули проводника категорий товаров и покупательской корзины

89

Модуль заказов располагается на отдельной странице, выполняет функцию оформления заказа или покупки добавленных в корзину товаров интернет-магазина. Его настройки также состоят из не-большого количества пунктов. Это тип представления модулем ин-формации на странице, включение защищенной передачи информа-ции о заказе по протоколу SSL, оформление внешнего вида корзины заказов конкретного покупателя (My Cart). После нажатия на вит-рине кнопки «Купить сейчас» (Buy Now) посетитель либо попадает на страницу оформления заказа, либо ему предлагают зайти в мага-зин по своим учетным данным. Естественно, если учетных данных нет, посетителю необходимо зарегистрироваться. Далее покупатель оформляет заказ в несколько этапов. На первом этапе указывается адрес доставки. Таких адресов здесь может быть несколько, и поку-патель способен сохранить каждый их них под определенным име-нем, впоследствии выбирая их из выпадающего списка для достав-ки. После ввода информации об адресе покупатель переходит к об-зору товаров в своей корзине, потом к способу оплаты. На этапе оплаты покупатель должен подтвердить оформление заказа. В зави-симости от установленного платежного провайдера магазина поку-патель производит оплату. Информация о подтвержденном заказе должна прийти покупателю по электронной почте. В данном модуле покупатель может просмотреть все свои заказы, а также их статус во вкладке «История заказа» (Order History).

Рис. 32. Модуль оформления заказов в модуле интернет-магазина DNN

Администратор интернет-магазина может просматривать все

заказы и менять их статус. Более того, администратор определяет

90

группу безопасности DNN для управления заказами. Реестр заказов может фильтроваться по номеру заказа, статусу и имени заказчика.

Если включена SEO-оптимизация, то необходимо настроить сайт магазина таким образом, чтобы четко указывать актуальные слова для поиска, что даст возможность поисковым системам лучше отобразить направление созданного электронного магазина. Мож-но подчеркнуть имя портала, категории продукта или название то-варов. Если какой-либо из них содержит специфические свойства, указывающие на уникальность товаров, их также необходимо включить в SEO-оптимизированный поиск. Бессмысленные харак-теристики (например, числовые или общие значения) предпочти-тельно не вставлять в шаблон SEO. Шаблон SEO может быть найден в ресурсах локализации.

Мы рассматривали модуль электронного магазина как есть, без локализации для русского языка. Безусловно, возможности встроенного функционала системы управления контентом по пе-реводу контента в процессе разработки и поддержки сайтов очень важны. Локализация представляет собой преобразование контента для другой культуры, где важнейшей частью является перевод на иностранный язык. В DNN 7 значительно развит механизм локали-зации сайтов, перевести можно буквально все, что изначально раз-рабатывалось с учетом стандартов разработки под платформу DNN. Не исключение и модуль нашего электронного магазина.

С практической позиции рассмотрим, как произвести локали-зацию для русского языка модуля администрирования интернет-магазина. На портал DNN необходимо зайти под суперпользовате-лем (host), перейти в настройки узла Host setting, на вкладке «Дру-гие настройки» (Other setting) включить опцию локализации кон-тента «Разрешить локализацию контента» (Allow Content Localiza-tions). Затем нужно открыть модуль настройки языков (Language Management), находящийся в меню администратора сайта, и нажать кнопку «Добавить новый язык» (Add New Language) (рис. 33). Появится окно выбора языков, где необходимо найти русский язык и указать его статус по отношению к сайту, в нашем случае указываем системный (System Default). После применения настроек переходим на вкладку языков, где видим выбранный нами язык и нажимаем кнопку «Активировать локализацию контента» (Enable Localized Content). После успешной активации таблица свойств языков расширится дополнительными параметрами, относящи-мися к процессу локализации.

91

Рис. 33. Активация локализации контента

В заголовке таблицы (Static Resources) в столбце Site необходимо перейти в режим редактирования. В появившемся окне редактиро-вания в области дерева каталога Resources переходим по пути Local Resources/DesktopModules/Store/App_LocalRecources/ и в ветке выбираем файл ресурсов StoreAdmin.ascx. После выбора появится таблица со столбцами Deault Value и Localized Value, в ячейках кото-рой содержатся надписи интерфейса модуля на английском языке и соответствующее значение, которое может быть переведено на рус-ский (рис. 35). После выполнения перевода и сохранения всех зна-чений необходимо переключить язык сайта на русский, нажав на соответствующий флажок. При переходе на страницу модуля ад-министрирования магазина мы увидим русскоязычный интерфейс

Рис. 34. Окно ввода перевода на русский язык надписей модуля администрирования интернет-магазина

92

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

Рис. 35. Переключение сайта на другой язык

Рассмотренные процедуры установки и техники настроек мож-но произвести для каждого из перечисленных выше DNN-модулей, составляющих большинство веб-представительств компаний. Модули делятся на платные, бесплатные, с открытым исходным кодом. От этого зависит их уровень функциональности, полнота документации и возможности поддержки. Инструментарий DNN для работы с модулями хорошо развит, позволяет ими гибко управлять на страницах сайтов, применять различный дизайн, настраивать общие и специфические параметры, сохранять в от-дельные пакеты, производить локализацию. Также из интерфейса DNN доступна дальнейшая разработка дизайна и функционально-сти модулей, что для небольших задач снимает необходимость ис-пользования средств программирования и разработки MS Visual Studio. Модули DNN могут быть очень сложны по функционально-сти, для разработки таких модулей может быть задействована большая команда программистов в течение длительного времени, представляя собой серьезный коммерческий проект.

93

2.3. Технология дизайна и создания страниц веб-представительства в CMS DNN

Любой сайт той или иной компании должен иметь внешнее

оформление, определенную стилистику, которая, в свою очередь, может диктоваться применяемым брендом. Как правило, бренды в компаниях утверждаются руководством и обязательны к приме-нению для большого числа объектов оформления, в том числе в разработке веб-представительства. Этот и многие другие факто-ры определяют требования к системе управления веб-контентом в плане гибкого оформления страниц и возможностей расположе-ния на них модулей. Для таких целей создаются специальные дизайнерские шаблоны оформления, управление которыми осу-ществляется на всех уровнях узла DNN, от портала до модуля. Шаб-лон оформления, или skin, относится к технологии разработки про-граммного обеспечения, которая предоставляет способ сепариро-вания логики приложения и контента от его внешнего представле-ния, оформления. При таком подходе в программном обеспечении образуются понятия формы и функции, для описания которых под-ходит двухуровневая модель представления. Архитектура шабло-нов оформления в DNN направлена на разработку пользователь-ского интерфейса, который легко интегрируется с приложением-порталом, формирует визуально привлекательные сайты. Большой плюс такой архитектуры шаблонов оформления состоит в том, что логика приложения и внешняя форма страницы могут разрабаты-ваться и модифицироваться отдельно. Программисты и веб-дизайнеры могут работать над разработкой одного сайта парал-лельно, без риска негативного влияния на деятельность друг друга.

Как говорилось ранее, DotNetNuke использует родительскую технологию ASP.Net и некоторые ее методы зеркально отражает при разработке сайта, но к шаблонам оформления это не относится. В качестве основного элемента шаблона оформления в ASP.Net ис-пользуются главные страницы (Master Page). Они позволяют созда-вать конкретную и четкую структура всех страниц сайта, стандар-тизируют их поведение, оформление и наполнение контентом. Для идентификации главных страниц используется директива @Master, которая заменяет директиву @Page для обычных страниц ASPX. Файл главной страницы имеет расширение Master (например, WebSait_1.master) с заранее обозначенной структурой, которая включаeт элементы HTML, статический текст, серверные элементы

94

управления ASP.Net, в число которых входит важный элемент управления ContentPlaceHolder. Данные серверные элементы назы-ваются «местозаполнителями» и определяют области, в которых отображается заменяемое содержимое. Заменяемое содержимое, в свою очередь, определяется на страницах содержимого. Это стра-ницы ASP.Net (ASPX-файлы и файлы с выделенным кодом), связан-ные с главной страницей. Связывание осуществляется в директиве @Page страницы содержимого путем включения атрибута MasterPageFile, указывающего на используемую главную страницу. Содержимое создается путем добавления элементов управления Content и сопоставления их с контроллами ContentPlaceHolder на мастер-странице. Например, главная страница может содержать «местозаполнители» содержимого с названиями Test1 и Test2. Далее можно создать два элемента управления Content: один сопо-ставляется с элементом управления ContentPlaceHolderTest1, а вто-рой – с элементом управления ContentPlaceHolderTest2, как показано на рис. 36. Тем не менее такая программная архитектура шаблонов не применяется в DNN.

Рис. 36. Способ организации шаблона оформления в ASP.Net

95

Помимо преимуществ, главные страницы имеют и недостатки – отсутствие полного разделения при разработке между програм-мистом и дизайнером. Через главные страницы разработчик про-екта может изолировать области контента и затем определить для дизайнера шаблона строго определенную область для размет-ки. Но такое преимущество можно использовать, работая только в MS Visual Studio, функциональность которой позволяет отобра-жать главную страницу и страницу содержания в одном окне в режиме дизайнера.

Такой сценарий разработки не подходит для максимальной привлекательности и выгодности создания шаблонов под DNN. Более того, многие дизайнеры сайтов используют операционную систему компании Apple, на которой невозможно работать в Visual Studio, соответственно, нецелесообразно изолировать такой кон-тингент разработчиков из-за ограничений продуктов Microsoft. В существующей архитектуре движка шаблонов оформления DNN дизайнеры свободны и могут проектировать на любой операци-онной системе, используя любые инструменты, что увеличивает их производительность. Другое ограничение главных страниц ASP.Net – программный код платформы .NET, описывающий также область контента страницы содержания. Если дизайнер имеет ма-ло опыта работы с технологией .Net и редактирует шаблон в обычном редакторе HTML, он может легко удалить специальные директивы или ошибиться в их написании, например @Page и @Master или серверных элементов управления. В свою очередь, это потребует много времени на поиск ошибок и усложнит после-дующий рефакторинг разметки. Поскольку DotNetNuke полностью изолирует разметку от программного кода при помощи шаблонов наряду с их модулями и объектами, эта ситуация может произойти с минимальной вероятностью. Это в максимальной степени изо-лирует функциональную работу программиста и дизайнера и дает возможность работать одновременно в рамках проекта разработки сайта, не дожидаясь очередности.

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

96

уровнях – узла, портала, страницы, модуля. Хотя шаблон оформле-ния может применяться на нескольких уровнях сайта, в файловой системе сервера они сохраняются в двух каталогах. Фактическое расположение файлов дизайна зависит от того, под какими права-ми и для какого сайта происходила инсталляция шаблона оформ-ления. При установке с правами администратора узла (host) файлы помещаются в каталог Portals\_default\Skins. Если установку шаб-лона производит администратор конкретного портала на узле, то шаблон копируется в каталог Portals\PortalId\Skins. Идентифика-ционный номер следующего портала (PortalId) на узле начинается с 0 и продолжается по возрастанию на единицу. В течение процесса установки каталог, который создается по указанному выше пути, именуется как имя инсталляционного пакета .zip. Структура ката-лога шаблона полностью аналогична изначальной структуре запа-кованного файла установки.

Для создания шаблонов оформления, сформированных в раз-личных графических дизайнерах сайтов, необходимо преобразо-вать выходные файлы в формат HTML и разнообразить их специ-альными ключами (токенами) в новом формате HTML-объектов или элементами управления ASCX. Это необходимо, чтобы шаблон-ный сервис DNN распознавал, где в шаблоне импортируется функ-циональность, требующаяся для запуска сайта. Процесс преобразо-вания файлов графического дизайна, созданных, например, в про-граммном обеспечении Adobe Photoshop или в Illustrator к формату HTML, который, в свою очередь, должен соответствовать стандар-там форматирования разметки для шаблонов и контейнеров DNN, называется фазой производства шаблона.

В движок оформления DNN встроен специфический анализатор разметки, который преобразовывает *.HTM и *.HTML в необходи-мый тип файлов с целью предоставления разработчикам HTML максимальных возможностей использования инструментов разра-ботки. Для того чтобы первичный HTML-дизайн шаблона мог рабо-тать в DNN, файлы проекта шаблона должны быть преобразованы в элементы управления ASP.Net с расширением ASCX. Файлы для преобразования шаблона оформления по умолчанию при развора-чивании для узла DNN 5 находятся в каталоге MinimalExtropy фай-ловой системы (рис. 37).

Рассмотрим процесс преобразования и применения шаблона оформления по умолчанию для DNN 5 в версии DNN 7. Скопируем шаблон оформления MinimalExtropy из каталогов Containers и Skins

97

в аналогичный каталог шаблонов DNN 7. Затем удаляем из катало-гов шаблона все файлы с расширением ASCX. Таким образом, в дан-ных каталогах файлы шаблона представлены только HTML-разметкой, таблицами стилей и графикой. Далее переходим в меню администратора и запускаем модуль управления дизайном узла Skins. На загрузившейся странице модуля в выпадающем списке выбираем скопированный шаблон оформления и нажимаем кнопку Parse Skin Package (рис. 38).

После успешного завершения работы мастера в каталоге по-явятся файлы с расширением *.ascx, название которых соответ-ствует всем файлам с расширением *.html. В процессе парсинга по специальным меткам в элементы управления внедряются и форматируются стандартизированные объекты DNN, например ACTIONBUTTON, ACTIONS, BANNER, BREADCRUMВ, COPYRIGHT, CURRENTDATE и т.д. В скин-модуле появятся мини-изображения внешнего вида шаблона и контейнеров для модулей. Затем можно предварительно посмотреть и применить каждый доступный ва-риант шаблона. В общем, создавать проект шаблона на HTML или непосредственно в ASP.Net посредством пользовательских элемен-тов управления ASСX – вопрос предпочтения разработчиков. Разра-ботчики HTML, которые лучше знают инструменты, созданные для проектирования на HTML, например Adobe Dreamweaver или Microsoft Expression, будут производительней. Но для проверки им каждый раз необходимо делать преобразование через мастер шаб-лонов DNN.

Рис. 37. Расположение файлов шаблона оформления в формате HTML

98

Разработчики в Visual Studio, естественно, будут создавать шаблоны в родном формате, используя визуальный редактор. В такой ситуации преимуществ больше, так как включается в работу функция IntelliSense в Visual Studio для средств управления Skinobject и возможность проверить изменения проектируемого шаблона без необходимости преобразования через скин-мастер DNN (рис. 39).

Рис. 38. Преобразование шаблона оформления HTML в ASСX-формат для DNN

Рис. 39. Преобразованный шаблон MinimalExtropy

99

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

Как уже говорилось ранее, шаблон дизайна DNN состоит из HTML-разметки, каскадных таблиц стилей (CSS), специальных DNN-объектов шаблона и областей размещения контента. В шаб-лон оформления вкладываются HTML-таблицы, которые структу-рируют часть шаблона на строки и столбцы. Каскадные таблицы стилей определяют цвета, графику и используемые шрифты. Объ-екты скина являются битами функциональности, в которой нужда-ется каждый сайт.

Можно выделить следующие объекты шаблона оформления по умолчанию, которые следуют сверху вниз по странице сайта:

• лого сайта; • меню; • элемент ввода информации для поиска (search box); • текущая дата; • элементы навигации, которые указывают, на какой странице

в данный момент находится пользователь и в каком участке меню; • имя пользователя; • вход/выход из системы; • уведомление об авторском праве и т.д. Отметим типичные файлы, из которых собирается любой шаб-

лон оформления в DNN: • НТМ – основной файл, из которого изначально строится шаб-

лон оформления. При инсталляции шаблона оформления данный файл анализируется специальной программой и создается файл ASCX;

• ASCX – главный действующий файл шаблона оформления, ко-торый создается машинным способом, перезаписываемый при по-вторном анализе файла HTM;

• CSS – файл каскадной таблицы стилей, который определяет внешний вид для всех элементов шаблона оформления;

100

• XML – содержит все пары типа «атрибут/значение» для встав-ки ASP.Net серверных элементов управления, который использует-ся при разборе файла HTM для создания ASCX-файла;

• JPG/GIF/PNG – графические файлы. Это изображе-ние/графические файлы, которое будут включаться вместе с дру-гими файлами, чтобы составить проект шаблона. Файлы, снабжен-ные префиксом 'thumbnail_', служат маленькими предварительны-ми просмотрами относительно того, на что будет похож портал при установке данного шаблона как основного.

Создание шаблона оформления включает следующие типичные шаги [24]:

1. Создать папку в файловой системе, где расположен каталог портала для файлов шаблона оформления.

2. Создать файлы, определяющие работу шаблона. 3. Подготовить все необходимые графические изображения. 4. Определить структуру расположения при помощи HTML и CSS. 5. Создать ссылки на изображения. 6. Определить области или панели шаблона. 7. Вставить пользовательские объекты DNN для шаблона. 8. Настроить правильное расположение объектов шаблона. 9. Упаковать файлы шаблона оформления в формат .zip. Перечисленные шаги выполняются в среде разработки MS Visual

Studio, например Visual Web Developer 2010 Express. Вернемся к шаблону оформления Minimal Extropy и применим

его к нашему сайту. Данный пакет шаблона имеет несколько видов, в зависимости от разрешения экрана можно применить подходя-щий либо применить вид index full. Для этого зайдем с правами суперпользователя на наш сайт и перейдем в модуль Skins. В выпа-дающем списке выберем шаблон оформления Minimal Extropy и в превью шаблона найдем index full, далее применим данный шаб-лон (рис. 40). Для понимания основ создания и редактирования шаблонов оформления добавим в выбранный дизайн еще несколь-ко областей размещения модулей (или контента), так как области или панели имеют большое значение в дизайне. По умолчанию данный шаблон имеет 5 областей размещения контента: TopPane, LeftPane, ContentPane, RightPane, BottomPane. Их можно увидеть, пе-рейдя в режим страницы View in Layout Mode. Для примера добавим еще несколько панелей и разместим в них наши модули интернет-магазина. Для этого в Visual Studio Express открываем сайт с ло-кального узла (Файл > Открыть веб-узел), как показано на рис. 41.

101

После открытия проекта в дереве необходимо перейти в каталог

Portals\_default\Skins\MinimalExtropy и открыть файл index full.html. Это первичный файл HTML-разметки, который формирует скелет шаблона оформления и из которого затем собирается .ascx-файл. Далее нужно увидеть структуру данного файла для определения ме-стоположения разметки, создающего панели размещения контента.

.

Рис. 40. Стандартные панели шаблона MinimalExtropy

.

Рис. 41. Открытие сайта DNN на локальном узле по средствам Visual Studio

102

Для этого в меню Visual Studio необходимо установить расширенный режим отображения функциональности, перейдя в «Сервис > Пара-метры» и поставить галку «Расширенные параметры». В меню «Вид» выберем режим «Структура документа». По умолчанию в левой части Visual Studio отобразится вкладка структуры документа, на которую нужно нажать.

Из информации по структуре видно, что наша разметка в основном состоит из элементов DIV. Он является блочным элементом и предна-значен для выделения фрагмента документа с целью изменения вида содержимого. Вид блока управляется с помощью стилей, находящихся во внешней таблице. В данном шаблоне каждый элемент DIV имеет привязку к стилям. Необходимые для правки или вставки панели находятся в элементе DIV с привязкой к классу стиля content_pad.

При дальнейшем разворачивании блоков мы увидим таблицу или элемент table, в которой находятся строки tr и ячейки td. Каждый из указанных элементов также привязан к классу стилей. Соответ-ственно, каждая ячейка имеет идентификатор определенной панели. Данные идентификаторы отображаются в режиме разметки на сайте.

Рис. 42. Структура файла шаблона оформления с разметкой в Visual Studio Express

103

Сформируем дополнительные области со специфическими настройками стилей. Для этого добавим еще несколько таблиц в разметку. Таблица также будет включать в себя три ячейки (об-ласти) для расположения контента. Также создадим отдельные классы в каскадных таблицах стилей и пропишем там фиксирован-ные процентные параметры ширины ячейки. Процентные пара-метры – это относительные величины, которые отталкиваются от максимально возможной величины, установленной в вышестоя-щих по каскаду файлах стилей. В DNN присутствует система иерар-хического переопределения стилей, каждая ссылка переопределяет предыдущую. Данные переопределения необходимо учитывать при проектировании стиля, опираясь на стандарты иерархии сти-лей в шаблонах. Рассмотрим предназначение файлов стилей DNN от высокого до низкого приоритета:

• Portal.css – сохраняется в корне текущего портала. Данный стиль может быть использован для переопределения стилей оформления для страниц администратора и настроек сайта.

• HTMLContainer.css – специфический файл стиля для пере-определения оформления контейнера. Принимая во внимание, что файл Container.css определяет общий стиль для всех контейнеров в шаблоне оформления, HTMLContainer.css может поменять, например, цвет для одного контейнера в пакете.

Рис. 43. Разметка кастомизированных панелей шаблона и их стилей

104

• Container.css – файл класса, который определяет внешний вид для всех контейнеров текущего шаблона.

• Default.css – файл определяет стили для всех сайтов в теку-щем экземпляре установка DNN. Стили относятся к администра-тивной панели управления, файловому менеджеру, мастеру эле-ментов управления, HTML-элементам H1, H2, a, UL и др.

• Module.css – стандартный файл стилей, включенный в ката-лог каждого модуля и определяющий их внешний вид. Файл со-держит классы, которые необходимо учитывать при разработке дополнительных свойств отображения.

Помимо перечисленных файлов стилей, при разработке дизайна необходимо учитывать классы стилей, которые должны присут-ствовать в каждом шаблоне оформления, чтобы элементы управ-ления DNN и Skinobjects соответствовали неким стандартам. Пере-числим данные классы:

• Normal, NormalDisabled – применяется к тексту на уровнях от сайта до конкретного элемента управления. Разработчики должны применять данный стиль для текста HTML-таблиц, элементов управления ASP.Net datagrid, gridviews, datalists.

• NormalRed – используется для создания стиля отображения сообщений об ошибках в модулях.

• NormalBold – используется для отображения текста в полу-жирном виде.

• NormalTextBox – используется для формирования стиля диа-логовых окон ввода.

• SubHead – используется для внешнего вида заглавия секций или названий параграфов и меток на форме.

• SubSubHead – используется для формирования вида заголов-ков нижестоящего уровня относительно SubHead.

• Head – используется для главных заглавий или названия сек-ций везде, где это необходимо.

• SkinObjectSkinobject – используется для определения внеш-него вида объектов DNN в шаблоне, например дата, пользователь, вход и др.

В нашем примере мы определили классы стилей для дополнитель-ных панелей в текущем файле шаблона оформления. Далее сохраняем сделанные нами изменения. Поскольку правка разметки производи-лась в файле index full.html, необходимо произвести парсинг данного файла с целью перезаписи рабочего файла index full.ascx. Для этого надо перейти в модуль Scins и в разделе парсинга выбрать соответ-

105

ствующий шаблон оформления и наш файл index full. Важно отметить, что в выпадающем списке появляются файлы только HTML-разметки. Затем нужно нажать на кнопку Parse Skin Package и дождаться окон-чания процесса работы мастера.

Переходим на страницу размещения модулей тестового интер-нет-магазина и переключаем ее в режим отображения разметки. Мы увидим добавленные нами новые секции размещения модулей: CustomPaneLeft1, CustomPaneLeft, CustomPaneRight, CustomPaneFull-Right. Переместим модули магазина в созданные секции размеще-ния, имеющие фиксированные относительные размеры. После успешного распределения модулей оформление сайта будет таким, как показано на рис. 44.

Резюмируя часть раздела создания дизайна сайта, можно сде-лать вывод о том, что, принимая во внимание ряд правил движка DNN для разработки шаблонов оформления, можно строить высо-кокачественные и гибкие скины, используя в основном только HTML и CSS. Архитектура механизма шаблонов оформления DNN не ограничивает разработчиков в выборе инструментов проекти-рования. Технология использования заполнителей в виде фраг-мента HTML-разметки [Token] позволяет включать в шаблон кон-троллы ASP.Net как объекты. Механизм загрузки шаблона оформ-ления DNN производит замену заполнителей элементами управле-ния .ascx, которые в дальнейшем обрабатываются ядром CMS DNN.

Рис. 44. Внешний вид тестового интернет-магазина электроники

106

Поскольку на различных интернет-ресурсах можно найти бесплат-ные шаблоны для DNN, их можно брать за основу и в дальнейшем дорабатывать под специфические потребности вашей деятельно-сти, что значительно ускоряет создание сайтов.

DNN имеет в своем арсенале богатый инструментарий создания и управления веб-страницами сайтов. В этот список входят такие возможности, как: добавление новой страницы, просмотр любой страницы сайта или всего узла, копирование, импорт и экспорт страниц, копирование дизайна и прав доступа на дочернюю страни-цу, удаление страниц, настройка параметров страниц, публикация или закрытие для публикации, тегирование контента страниц.

Алгоритм создания новой страницы в DNN следующий: 1. Необходимо зайти в портал под учетной записью администра-

тора или суперпользователя, перейти в меню «Страницы» (Pages) административной панели инструментов и нажать на пункт «Доба-вить новую страницу» (Add New Page) (рис. 45).

2. В появившемся окне настроек веб-страницы необходимо вве-сти имя страницы. Это единственное поле, являющееся обязатель-ным для заполнения в свойствах новой страницы. При дальнейшей установке свойств по умолчанию страница добавится в нейтраль-ной языковой культуре.

3. Рекомендуется вести (необязательно) полную детализиро-ванную информацию о странице: загаловок страницы, описание, ключевые слова, теги, родительская страница, порядок очередно-сти вставки страницы, влючать/не включать в меню сайта.

4. На вкладке окна настроек страницы «Безопасность» (Permissions) необходимо установить группы пользователей сайта, которые смогут увидеть данную страницу. По умолчанию права на страницу выставляются только группе администраторов сайта. Вкладка безопасности страницы отображается только пользовате-лям, которые авторизованы для управления правами. При данных параметрах настройки новые страницы наследуют права безопас-ности от родительской страницы.

5. Для тонкой настройки внешнего вида страницы необходимо перейти на вкладку «Дополнительно» (Advanced Settings). Помимо шаблона оформления, который указывается в базовых настройках, на данной вкладке можно определить иконку страницы, которая отображается в меню сайта, и иконку, которая будет использовать-ся в консоли администратора сайта. Для конкретной страницы можно указать конкрентый шаблон, который переопределяет дизайн, указанный для сайта.

107

6. Если для данного портала, для которого создается новая стра-ница, включена локализация контента, то в настройках будет отоб-ражена вкладка локализации. В зависимости от установленного второго языка можно произвести перевод текстовых полей страницы, например, название страницы и название добавленных модулей.

7. Последний шаг для добавления страницы – нажать на кнопку «Добавить страницу» (Add Page).

Созданные страницы можно увидеть на сайте несколькими спо-собами. В зависимости от параметров, которые были указаны при создании страницы, он может отображаться в центральном меню сайта, либо, если указывалось, что данная страница является дочер-ней, то увидеть ее можно в выпадающем меню основного меню сай-та, за родительской страницей. Также в стандартной инсталляции DNN присутствует модуль управления страницами Page Manager, который мы рассматривали ранее. В зависимости от уровня прав администратора в данном модуле можно увидеть все страницы сайта или узла, а также произвести с ними необходимые манипуляции.

В модуле Page Manager реализована функциональность добавле-ния сразу нескольких страниц на портал с указанием их иерархиче-ской структуры. В области проводника страниц необходимо выбрать уровень подчиненности и правой кнопкой мыши вывести контекстное меню, выбрать функцию «Добавить страницу(ы)». Справа появится поле для ввода названий страниц. Применяя синтаксис типа [Уро-вень][Название страницы], пропишем необходимую структуру стра-ниц (рис. 46). Это позволяет на основе проекта веб-представительства быстро реализовать необходимую структуру и показать карту сайта.

Рис. 45. Меню создания новой веб-страницы DNN

.

Рис. 46. Массовое создание веб-страниц при помощи модуля Page Manager

108

Процесс генерирования займет в такой ситуации несколько секунд, и созданные страницы отобразятся в проводнике модуля (рис. 47).

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

В случае импортирования стра-ницы можно поменять больше па-раметров, например выбрать шаб-лон оформления, указать имя стра-

ницы, выбрать родительскую страницу. Данный режим не позволяет выбрать модули, расположенные на импортируемой странице, по-этому в результате импорта создается новая страница без модулей или заменяется текущая. DNN предоставляет возможность копиро-вать права родительских страниц на дочерние. Данная функция ста-новится доступной, если у страницы есть дочерние страницы. Функ-ция копирования прав Copy permission to Children появляется в выпа-дающем меню управления страницами административной панели управления. При ее активации появится предупреждающее окно о замене прав доступа к дочерним страницам (рис. 48).

При работе на портале под администратором или суперпользова-телем в административной панели становится доступным режим ре-дактирования существующих страниц. При нажатии на конопку «Ре-дактировать эту страницу» (Edit This Page) над каждым внедренным на страницу модулем появляется ряд функциональных иконок.

Рис. 47. Структура массово сгенерированных страниц

в модуле Page Manager

109

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

панели расположения контента. Наличие тех или иных областей зависит от дизайна шаблона оформления, установленного на портале в данный момент. Эти перемеще-ния производятся через меню в выпадаю-щем списке иконки перемещения модуля по странице. В зависимости от функцио-нальности модуля в режиме редактирова-ния страницы может появиться специфи-ческая иконка добавления информации в модуль. Разметку страницы на области размещения контента (Pane) можно уви-деть, выбрав галку «Вид в режиме размет-ки» (View in Layout Mode).

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

системы управления контентом такова, что разработчик макси-мально нацелен на реализацию внешнего вида и иерархии страниц представительства в короткие строки, а также их безопасности, ми-нуя уровень программного кода и разметки. Более того, все страни-цы по сути являются виртуальными, кроме одной – default.aspx. DNN использует данную страницу в единственном экземпляре

Рис. 48. Окно замены прав дочерних страниц

Рис. 49. Меню

редактирования веб-страниц

110

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

2.4. Microsoft Visual Studio и программирование дополнительной функциональности модулей CMS DNN

в веб-представительстве

Для создания новых модулей DNN со специфической функцио-нальностью для веб-представительства или доработки существу-ющих необходимо развернуть тестовую среду разработки, лучше на виртуальной машине, включающей в себя ряд программных средств. В данный перечень входит Windows Server 2008-2012 с развернутой ролью веб-сервера IIS 7, MS Sql Server 2008-2012, развернутый портал DNN 7, MS Visual Studio 2013, специальные шаблоны для разработки модулей DNN для Visual Studio.

Рассмотрим установку шаблонов разработки модулей. Обяза-тельное требование: перед этим должна быть установлена MS Visual Studio 2013 редакции Community или Professional, а также дополни-тельное программное обеспечение MSBuild Community Tasks по-следней версии. MSBuild является инструментом по умолчанию для построения инсталляционных файлов проектов модуля DNN в Visual Studio. Необходимо загрузить с ресурса https://christoctemplate. codeplex.com шаблон проекта под соответствующую версию Visual Studio. В разделе загрузок выбираем релиз шаблона DNN 7 Project Templates V4 for VS2013, производим его загрузку и последующую настройку. Стандартно шаблон проекта модуля настроен на работу с сайтом IIS dnndev.me, и для успешного создания проекта в Visual Studio сайт по умолчанию необходимо поменять на существующий, в нашем случае на localhost/dnn7. Для данной операции необходимо перейти в каталог установленного шаблона конкретного языка про-граммирования. Для примера возьмем шаблон проекта для Visual Basic. Каталог имеет название DNN-VB-Module, найти его лучше всего через функцию поиска в стандартном проводнике Windows. В данном каталоге ищем файл DNN-VB-Module.vstemplate, открываем его в тек-стовом редакторе «Блокнот». После открытия для редактирования

111

ищем в файле строку <CustomParameter Name=«$devenvironmenturl$» Value =«dnndev.me»/> и меняем значение параметра на URL-строку нашего сайта без http://, сохраняем. Открываем Visual Studio на ком-пьютере с установленным порталом DNN и создаем проект нашего тестового модуля на Visual Basic. В настройках расположения нужно указать каталог действующего на IIS DNN сайта – DesktopModules, убрать галку «Создать каталог для решения» (рис. 50).

После нажатия кнопки «ОК» начнется процесс создания проекта

модуля через подключение к веб-серверу, где расположен разверну-тый портал DNN и копирование необходимых файлов. При успешном завершении создания проекта в окне обозревателя решений Visual Studio будет отображено решение с именем разрабатываемого модуля и все необходимые файлы проекта (рис. 51). В главном окне откроется файл с кратким описанием шаблона разработки. О структуре файлов проекта расскажем ниже. Далее необходимо произвести интеграцию созданного модуля на портал DNN для визуализации и тестирования разработки. Чтобы установить модуль на портал, необходимо собрать установочный архивный файл. Для этого следует корректно настро-

Рис. 50. Окно выбора проекта модуля DNN в Visual Studio 2013

112

ить проект модуля в части веб-ссылок. В свойствах проекта модуля перейдем в меню «Веб» и укажем следующие настройки:

• начальный URL-адрес портала http://localhost/dnn704; • серверы: локальный сервер IIS; • URL-адрес проекта http://localhost/dnn704/DesktopModules/

DNNModeleTest1; • переопределить корневой URL-адрес приложения http://

localhost/dnn704. В опции нужно поставить галку. После сохранения параметров про-

ект модуля нужно построить (ском-пилировать) и упаковать. В меню Visual Studio «Конфигурации реше-ния» выбираем Debug, в меню «Сбор-ка» нажимаем «Собрать решение». В окне «Вывод» появятся характери-стики процесса сборки, где главный параметр контроля – наличие оши-бок, которых быть не должно. После успешной компиляции проекта выби-раем конфигурацию Release и по-вторно собираем проект. Эта конфи-гурация, которая состоит из про-граммных скриптов MSBuild, после построения создает два архивирован-ных zip-файла по шаблону именова-ния [Имя проекта]_[версия сбор-ки]_install.zip и [Имя проекта]_[версия сборки]_source.zip. В последнем файле сохраняются все файлы программно-го кода в исходном состоянии, в фай-ле инсталляции код VB компилирует-ся в отдельную библиотеку динами-ческой компоновки (dll), находящую-ся в папке bin пакета модуля. Таким образом, данные пакеты, созданные с помощью MSBuild, являются полно-ценными пакетами инсталляции,

не привязанными к конкретному сайту, и могут устанавливаться на любой DNN-сайт. Пакеты инсталляции формируются в папке проекта модуля install. Затем необходимо установить созданный

Рис. 51. Проект

модуля DNN в Visual Studio 2013

113

нами «пустой» модуль на DNN-сайт. Для выполнения данной про-цедуры нужно войти под учетной записью сурерпользователя (host), перейти в модуль «Расширения» (Extensions), нажать на кнопку «Мастер установки расширения» (Inastall Extension Wizard). Далее нажимаем на кнопку «Выбрать файл» (Choose File) и в диалоговом окне переходим в каталог расположения инсталля-ционного пакета .zip. После успешной инсталляции модуля на пор-тал его необходимо разместить на странице сайта для последую-щих тестов. При последующей разработке и внесении существен-ных изменений в код модуля можно менять номер версии собирае-мых пакетов в файлах assemblyinfo.vb и [имя проекта].dnn, который является файлом манифеста, в нашем случае DNNModuleTest1.dnn.

Рассмотрим структуру сформированного проекта модуля. Ката-лог App_LocalResources содержит файлы ресурсов для перевода кон-тента на другие языки и привязаны к основным трем файлам – кон-троллам, из которых собственно и состоит модуль: View.ascx, Edit.ascx, Setting.ascx. Каталог BuildScripts содержит файлы в форма-те xml, в которых прописаны инструкции – скрипты для MSBuild, ка-ким образом необходимо создавать инсталляционные пакеты для данного проекта, какие файлы должны быть в них включены. В ка-талоге Components находится файл программного кода FeatureCon-troller.vb, в котором написан программный класс FeatureController. Он определен в файле манифеста с расширением .dnn как контрол-лер прикладной логики модуля. DNN прослушивает данный класс на предмет наличия определенных интерфейсов. В данном классе для модуля включено несколько программных интерфейсов DNN:

• IPortable – используется для реализации импортирова-ния/экспортирования содержания модуля DNN;

• ISearchable – предназначен для индексирования контента мо-дуля для поисковой системы портала DNN;

• IUpgradeable – позволяет разработчикам выполнять про-граммный код для обновления модуля в процессе его модерниза-ции, улучшений.

В каталоге Data находится файл программного кода DataPro-vider.vb, в котором реализован абстрактный класс DataProvider. Данный программный класс определяет методы, которые должен выполнять уже конкретный класс доступа к данным. В этом шаб-лоне модуля реализовывается работа только с единственным по-ставщиком данных. Секции кода абстрактного провайдера данных выглядят просто. Создается константа с областью видимости толь-

114

ко из данного класса, которая содержит реализацию указанного провайдера данных. С модификатором доступа связи с классом или структурой целиком, а не с определенным экземпляром класса или структуры прописывается конструктор, который создает вывод провайдера в коде, когда требуется его инициализация. Далее в коде прописывается процедура динамического создания указанного про-вайдера. По умолчанию шаблон кода использует пространство имен, которое является корневым в данном проекте. Затем прописывает-ся функция Instance, которая возвращает созданный объект провай-дера. Следующая секция, содержащаяся в файле DataProvider.vb, яв-ляется декларацией абстрактных методов доступа к данным. Эти методы используются для возврата данных из СУБД. Поскольку DataProvider является абстрактным классом, все методы данных должны быть определены здесь. При таком подходе устанавливает-ся своеобразный «контракт» для конкретных классов, которому они должны подчиняться. Это гарантирует, что все методы работы с данными в модуле будут поддержаны даже при работе портала DNN с различными системами управления базами данных, например не только MS SQL Server, но и Oraqle, MySQL. При работе с методами доступа к данным внутри DNN типы данных, возвращаемые функ-циями, используют общий программный интерфейс IDataReader. Поддержка различных конкретных провайдеров данных была бы невозможной, если бы функции возвращали, например, SqlDataReader или другие подобные программные объекты.

Следующий значимый каталог в проекте шаблона модуля – Provider\DataProviders\SqlDataProvider, который содержит файл SqlDataProvider.vb. Данный файл является реализацией продолже-ния модели доступа к данным в DNN. Файл реализует класс с ана-логичным названием и намного сложнее, чем абстрактный класс DataProvider, так как фактически реализует необходимые методы работы с данными и получает конфигурационные данные подклю-чения из файла web.config. Класс SqlDataProvider является наследу-емым от класса DataProvider, что прописано в начале кода:

Public Class SqlDataProvider ' модификатор доступа «общий» для создания

класса Inherits DataProvider ' класс наследуется от класса DataProvider

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

115

много проблем в разработке кода. Далее в коде прописываются специальные закрытые переменные и методы, которые в процессе работы получают конфигурационные данные. Часть некоторых пе-ременных является константами, например тип провайдера и название модуля.

'Объявляем строковую константу с доступом только из кода класса, при-

сваиваем значение “data” Private Const ProviderType As String = “data” 'Объявляем строковую константу с доступом только из кода класса, при-

сваиваем значение “YourCompany_” Private Const ModuleQualifier As String = “YourCompany_” ‘создаем объект для считывания прараметров провайдера данных Private _providerConfiguration As ProviderConfiguration = ProviderConfiguration.GetProviderConfiguration(ProviderType) ‘Создаем строковую переменную для хранения строки подключения к базе

данных портала Private _connectionString As String ‘Создаем строковую переменную для хранения пути к провайдеру данных Private _providerPath As String ‘Создаем строковую переменную для хранения префикса создаваемых объ-

ектов базы данных портала Private _objectQualifier As String ‘Создаем строковую переменную для хранения имени владельца объектов

базы данных портала Private _databaseOwner As String Приведенный код показывает члены (поля) класса SqlDataPro-

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

Шаблон содержит два ключевых закрытых метода для гарантии выполнения всех различных запросов модуля к базе данных. Пер-вый метод, GetFullyQualifiedName, прост и предназначен для воз-

116

врата имени объекта с полными данными (данные владельца базы данных, спецификации объекта и спецификации модуля). Такой метод избавляет от повторных запросов и создает гибкость при ра-боте с наборами конфигураций. Второй метод, GetNull, возвращает нулевые значения, если при работе с данными модуля будут воз-вращены пустые значения. В классе SqlDataProvider применяются перегружаемые методы. Компонент Application Block Data исполь-зуется для оптимизации доступа к данным. Хранимая процедура на стороне сервера баз данных выполняется при использовании про-граммного класса SqlHelper, включенного в код модуля.

Приведенный пример кода демонстрирует, что метод SqlHelp-er.ExecuteReader имеет стандартный синтаксис, который содержит строку подключения первым параметром; вторым параметром вы-ступает имя хранимой процедуры; третий параметр – это перемен-ные для передачи ключевых параметров хранимой процедуре. Такие ключевые параметры, как идентификационный номер моду-ля (ModuleID), контент (Content), пользователь для определения прав доступа к модулю (UserID), показанные в примере кода, ана-логичны коду хранимой процедуры, находящейся на сервере СУБД.

‘Создаем функцию с видимостью на уровне всего проекта, которая пе-

реопределяет унаследованную функцию “GetAll”, прописанную на уровне про-вайдера данных в коде «DataProvider.vb»

Public Overrides Function GetAll(ByVal ModuleId As Integer, ByVal ItemId As Integer) As IDataReader

‘Оператор возвращает приведенные данные к типу интерфейса IData-Reader, полученные вызовом при помощи объекта «SqlHelper» хранимой проце-дуры «GetAll» в базе данных портала

Return CType(SqlHelper.ExecuteReader(ConnectionString, GetFullyQuali-fiedName(“GetAll”), ModuleId, ItemId), IDataReader)End Function

‘Создаем процедуру, переопределяющую унаследованную процедуру «Insert-GBRec» в коде провайдера данных «DataProvider.vb», передаем параметры процедуре, в которой записаны данные для вставки в базу данных

Public Overrides Sub InsertGBrec (ByVal ModuleId As Integer, ByVal Content AsString, ByVal UserId As Integer)

‘Запускаем процедуру на вставку данных в таблицу гостевой книги базы данных портала

SqlHelper.ExecuteNonQuery(ConnectionString, GetFullyQuali-fiedName(“InsertGBrec”), ModuleId, Content, UserId)End Sub

В подкаталоге SqlDataProvider мастером создания формируются

два файла: 00.00.01.sqldataprovider и UnInstall.sqldatapovider. В начале файла указывается номер версии разрабатываемого мо-

117

дуля. Данный файл включает SQL-скрипты, используемые при ин-сталляции модуля и его обновлении, а также по своей структуре отражают специфику установки модулей, поддерживаемый DNN. В модуле может быть несколько таких файлов, которые отражают модернизацию модуля и в процессе установки запускаются пооче-редно снизу вверх по номеру версии. Код данного файла содержит работу с тремя основными аспектами: создание таблиц модуля, об-новление таблиц в базе данных, создание хранимых процедур. Спе-цифику создания таблиц и хранимых процедур покажем при созда-нии кода тестового модуля.

В проекте шаблона модуля формируется файл с расширением .dnn, в нашем случае – DNNModuleTest1.dnn. Это так называемый декларативный модуль, или файл манифеста в формате XML. Он предназначен для завершения интеграции разработанного модуля в портал DNN, предоставляет необходимое описание компонентов модуля и всех точек интеграции с CMS. В процессе инсталляции модуля на портал CMS использует данный файл для считывания сценария установки компонентов, а также здесь прописывается лицензионное соглашение.

В корне проекта модуля присутствуют два файла: DNNMod-uleTest1ModuleBase.vb и DNNModule1TestSettingsBase.vb. В коде дан-ных модулей создаются аналогичные по названию классы, которые наследуются от базовых классов DNN: PortalModuleBase и PortalSet-tingsBase. Это наследование используется для каждого стандартного пользовательского элемента представления .ascx в модулях DNN для правильной интеграции в портал и обеспечения в коде модуля си-стемной информации, безопасности и аутентификации. Это позволя-ет с легкостью конфигурировать и использовать служебную инфор-мацию внутри кода модуля. Ключевой момент в системе настроек модуля – это использование двух свойств: ModuleSettings и TabModuleSetings. В том случае, если элемент управления .ascx в мо-дуле, выполняющий роль главного окна модуля, использует класс PortalModuleBase, мы имеем специфические свойства, которые воз-можно группировать и использовать изолированно. Также в классе PortalSettingsBase присутствуют перегружаемые методы с общим мо-дификатором доступа LoadSettings и SaveSettings, которые гаранти-руют загрузку и сохранение настроек модуля.

Элементы управления, которые делают модуль DNN осязаемым для использования на портале DNN, обозначаются как Edit.ascx, Settings.ascx, View.ascx. На основе данных элементов строится ин-терфейс модуля DNN, включающий в себя отображаемые для по-

118

сетителей компоненты, редактирование контента и настройку модуля. Так как управление параметрами настройки является первичным после инсталляции модуля, написание кода разметки и кода логики в модуле Settings.ascx рекомендуется производить первоначально. Чтобы обеспечить интерфейс параметров настройки, используется простой HTML-код и отдельные .aspx-элементы управления (метки, чекбоксы, флажки). После заверше-ния основной работы над модулем Settings.ascx до момента готов-ности ресурсов взаимодействовать с установленными конфигура-циями можно переходить к созданию основного элемента управ-ления представления – View.ascx. Данный элемент управления – витрина разрабатываемого модуля, интерфейс для взаимодей-ствия с посетителями, и к созданию разметки здесь нужно подхо-дить строже, чем в скрытых частях модуля. В коде логики данного модуля прописывается процедура считывания настроек, произве-денных через элемент управления Settings.ascx модуля. Элемент управления View.ascx не имеет средств для правки контента, за эту функциональность отвечает компонент Edit.ascx и подключа-ется к View.ascx в зависимости от прав пользователя сайта. В дан-ном элементе управления может реализовываться различный функционал по работе с базой данных для добавления, редакти-рования и удаления данных контента. Весь контент указанных элементов управления можно привязывать к конкретному языку посетителей сайта через файлы .resx. В шаблоне проекта модуля они находятся в каталоге AppLocalResources, и каждый файл ре-сурса по своему названию привязывается к файлу представления модуля. Как правило, в данных файла прописываются надписи элементов управлении, чтобы изначально создавать локализуе-мый модуль. Следует отметить, что элементов управления View.ascх, отвечающих за внешнее представление, у модуля может быть несколько.

В шаблоне проекта также присутствуют важные файлы – компо-ненты модуля: module.css; packages.config; web.config. Соответственно, здесь переопределяется внешний дизайн модуля, цветовая гамма и расположение интерфейсных элементов управления на странице. Файл web.config представляет собой xml-документ, и на уровне моду-ля он может переопределять настроечные параметры такого же фай-ла, находящегося на уровне инсталляции портала DNN. В нем хранит-ся информация о параметрах поставщиков состояний сеансов, член-ства, определяются ссылки на страницы ошибок, строки соединения

119

с базами данных, средства управления трассировкой и т.д. Обычно при разработке модулей данный файл остается пустым, чтобы не возникало конфликтов при работе с порталом DNN.

Разобрав структуру проекта, приступим к наглядной разработке модуля. Целевое предназначение модуля – гостевая книга посети-телей сайта интернет-магазина [37]. Фундаментом полноценного модуля в DNN являются таблицы данных в СУБД или информаци-онно-логическая модель предметной области, реализованная в ба-зе данных. То есть начинать разработку модуля нужно с ответа на вопрос, какие данные модуль должен хранить и обрабатывать. Для примера обойдемся одной таблицей, которая будет хранить данные о сообщениях посетителей. Данные следующие: уникаль-ный идентификатор (entryId); идентификатор модуля (moduleId); имя гостя (name); веб-сайт (website); комментарий (comment); дата (daterec); одобрение записи (approved).

Определимся с методами, посредством которых можно работать с данными в СУБД SQL Server (табл. 3).

Таблица 3 Методы для работы с данными в модуле гостевой книги

Имя метода Возвращаемый тип данных Описание метода

InsertGBrec – Применяется для вставки данных в базу ApproveGBrec – Применяется для одобрения гостевых запи-

сей DeleteGBrec – Удаление гостевых записей из базы GetApproveRec IDataReader Чтение всех одобренных гостевых записей

из базы данных GetAll IDataReader Получение всех записей таблицы гостевой

книги

Затем программируем данные методы в файле проекта DataPro-vider.vb в разделе абстрактных методов:

’Указываем сворачиваемый блок кода в редакторе под именем «Abstract

methods» #Region «Abstract methods» ’Создаем процедуру вставки данных гостевой книги, которая должна быть

переопределена в коде класса провайдера для конкретной СУБД, перадаем в процедуру данные для вставки в таблицу

Public MustOverride Sub InsertGBRec(ByVal moduleId As Integer, ByVal Name As String, ByVal website As String, ByVal comment As String, ByVal daterec As DateTime, ByVal approved As Boolean)

120

’Создаем переопределяемую процедуру вставки в базу информации одобре-ния записи пользователя гостевой книги

Public MustOverride Sub ApproveGBrec(ByVal moduleid As Integer, ByVal entryId As Integer)

’Создаем переопределяемую процедуру удаления данных гостевой книги из базы, используя передоваемые в процедуру параметры ID модуля и записи

Public MustOverride Sub DeleteGBrec(ByVal moduleid As Integer, ByVal entryId As Integer)

’Создаем переопределяемую функцию получения из базы одобренных запи-сей гостевой книги, возвращаем эти данные посредствам методов интерфей-са IDataReader

Public MustOverride Function GetApproveRec(ByVal moduleId As Integer) As IDataReader

’Создаем переопределяемую функцию получения из базы всех записей гос-тевой книги, возвращаем эти данные посредствам методов интерфейса IDa-taReader

Public MustOverride Function GetAll(ByVal moduleId As Integer) As IData-Reader

#End Region

Методы имеют модификатор доступа на уровне всего проекта, решения должны быть переопределены в производном классе для реализации их использования, поэтому в коде отсутствуют операторы завершения процедур и функций. В этой связи такие методы работы с данными реализованы в классе SqlDataProvider с модификатором Overrides и прописаны в секции #Region Pablic Methods в файле кода класса:

’Создаем блок кода методов #Region "Public Methods" ’Создаем переопределенную процедуру с модификатором доступа на уровне

всего проекта для вставки данных гостевой книги в базу данных SQL Server Public Overrides Sub InsertGBRec(ByVal moduleId As Integer, ByVal Name As

String, ByVal website As String, ByVal comment As String, ByVal daterec As DateTime, ByVal approved As Boolean)

’При помощи специального объекта «SqlHelper» производим вызов процеду-ры «InsertGBRec» базы данных портала, передаем процедуре данные для вставки через параметры процедуры. Работа с процедурами базы данных про-исходит аналогично в последующих процедурах и функциях данного блока кода.

SqlHelper.ExecuteNonQuery(ConnectionString, GetFullyQuali-fiedName("InsertGBRec"), moduleId, Name, website, comment, daterec, approved)

End Sub ’Создаем переопределенную процедуру с модификатором доступа на уровне

всего проекта для вставки информации в таблицу базы данных об одобрении

121

записи в гостевой книге. Аналогично создаются последующие процедуры и функции

Public Overrides Sub ApproveGBrec(ByVal moduleid As Integer, ByVal en tryId As Integer)

SqlHelper.ExecuteNonQuery(ConnectionString, GetFullyQualifiedName("ApproveGBrec"), moduleid, entryId)

End Sub Public Overrides Sub DeleteGBrec(ByVal moduleid As Integer, ByVal entryId

As Integer) SqlHelper.ExecuteNonQuery(ConnectionString, GetFullyQualifiedName("DeleteGBrec"),

moduleid, entryId) End Sub Public Overrides Function GetApproveRec(ByVal moduleId As Integer) As

IDataReader Return CType(SqlHelper.ExecuteReader(ConnectionString, GetFullyQuali-

fiedName("GetApproveRec"), moduleId), IDataReader) End Function Public Overrides Function GetAll(ByVal moduleId As Integer) As IDataReaer Return CType(SqlHelper.ExecuteReader(ConnectionString, GetFullyQuali-

fiedName("GetAll"), moduleId), IDataReader) End Function #End Region

Как мы писали ранее, в приведенном коде используется про-

граммный класс SqlHelper, который значительно упрощает и уменьшает объем кода в каждом методе на 5–6 строк. Следующим шагом программирования уровня доступа к данным модуля явля-ется необходимость реализации класса, поставляющего данные из базы в свойства класса. Свойства класса, объекта имеют такие же названия и тип данных, как поля таблицы базы данных. Такой под-ход называется объектно-ориентированным и предоставляет все преимущества для программирования логики работы с данными. В Visual Studio в обозревателе решений кликаем по названию про-екта правой кнопкой мыши и добавляем новый файл класса, пред-варительно назвав его GBEntryInfo.vb.

’Импортируем пространства имен классов в созданный модуль класса

свойств Imports System Imports System.Configuration Imports System.Data Namespace DataGBModule ’Создаем класс свойств Public Class GBEntryInfo

122

’Отмечаем блок кода #Region "Private Members" ’Создаем переменные с модификатором доступа только из данного класса Private _entryid As Integer Private _moduleid As Integer Private _name As String Private _website As String Private _comment As String Private _daterec As DateTime Private _approved As Integer #End Region ’Отмечаем конец блока кода #Region "Constructor" ’Прописываем конструктор для создания нового объекта класса свойств Public Sub New() End Sub #End Region ’Отмечаем блок кода свойств #Region "Public Properties" ’Создаем числовое свойство для хранения id записи гостевой книги Public Property entryid() As Integer ’Создаем инструкцию чтения данных из свойства Get Return _entryid End Get ’Создаем инструкцию записи данных в свойство Set(value As Integer) _entryid = value End Set End Property ’Создаем числовое свойство для хранения id модуля гостевой книги Public Property moduleid() As Integer ’Создаем инструкцию чтения данных из свойства Get Return _moduleid End Get ’Создаем инструкцию сохранения данных в свойство Set(value As Integer) _entryid = value End Set End Property ’Создаем строковое свойство для хранения имени пользователя, который

вводит сообщение в гостевую книгу Public Property name() As String

123

’Создаем инструкцию чтения данных из свойства Get

Return _name End Get ’Создаем инструкцию сохранения данных в свойство Set(value As String) _name = value End Set End Property ’Создаем строковое свойство для хранения URL-адреса сайта

Public Property website() As String Get Return _website End Get Set(value As String) _website = value End Set End Property

Public Property comment() As String ’Создаем строковое свойство для хранения комментария пользователя

в гостевой книге Get Return _comment End Get Set(value As String) _comment = value End Set End Property Public Property datarec() As DateTime ’Создаем строковое свойство для хранения даты и времени записи в госте-

вую книгу Get Return _daterec End Get Set(value As DateTime) _daterec = value End Set End Property Public Property approved() As Boolean ’Создаем свойство для хранения логического значения метки одобрения/

отклонения записи в гостевой книге Get Return _approved End Get

124

Set(value As Boolean) _approved = value End Set End Property #End Region End Class End Namespace

В классе определены свойства для чтения данных и присвое-

ния им новых значений, что применяется при записи введенной через внешний интерфейс модуля в базу данных информации. Далее необходимо создать класс контроллера, являющийся про-граммным слоем, который обеспечивает доступ к методам работы с данными и преобразования возвращений интерфейса IDataReader в рабочие объекты и коллекции объектов, которые могут быть ис-пользованы модулем в запросах данных. Добавим новый файл класса в проект, назовем его GB.Controller.vd. Ниже приведен код класса контроллера.

’Импортируем в модуль необходимые пространства имен Imports System Imports System.Configuration Imports System.Data Imports System.Xml Imports System.Web Imports System.Collections.Generic Imports DotNetNuke Imports DotNetNuke.Common Imports DotNetNuke.Common.Utilities Imports DotNetNuke.Common.Utilities.XmlUtils Imports DotNetNuke.Services.Search Namespace DNNModule1 ’Создаем общий класс контроллера данных гостевой книги Public Class GBController ’Создаем метод класса с общим модификатором доступа, который отве-

чает за вставку данных, введенных пользователем в веб-форме, в таблицу гос-тевой книги в базе данных

Public Sub InsertGBRec(ByVal oInfo As GBEntryInfo) ’Вызываем объект провайдера данных в нашем проекте модуля и его метод

вставки данных InsertGBRec, передаем методу набор необходимых параметров. Таким образом, видно, что процедура вставки данных InsertGBRec является абстрагированным методом работы с данными модуля гостевой книги, не свя-занным непосредственно с СУБД, под управлением которой работает база банных портала.

125

DataProvider.Instance().InsertGBRec(oInfo.moduleid, oInfo.name, oInfo.website, oInfo.comment, oInfo.datarec, oInfo.approved)

End Sub ’Создаем метод класса с общим модификатором доступа, который отве-

чает за вставку данных одобрения модератором записи гостевой книги. Public Sub ApproveGBrec(ByVal oInfo As GBEntryInfo) DataProvider.Instance().ApproveGBrec(oInfo.moduleid, oInfo.entryid) End Sub ’Создаем метод класса с общим модификатором доступа, который отве-

чает за удаление данных из гостевой книги Public Sub DeleteGBrec(ByVal oInfo As GBEntryInfo) DataProvider.Instance().ApproveGBrec(oInfo.moduleid, oInfo.entryid) End Sub ’Создаем метод класса как функцию с общим модификатором доступа,

который отвечает за чтение данных из базы данных одобренных записей гос-тевой книги

Public Function GetApproveRec(ByVal moduleid As Integer) As List(Of GBEn-tryInfo)

’Загружаем (или возвращаем) одобренные записи гостевой книги в класс с применением объекта гидрации из служебных утилит DNN

Return CBO.FillCollection(Of GBEntryIn-fo)(DataProvider.Instance().GetApproveRec(moduleid))

End Function ’Создаем метод класса как функцию с общим модификатором доступа,

который отвечает за чтение данных из базы данных всех записей гостевой книги

Public Function GetAll(ByVal moduleid As Integer) As List(Of GBEntryInfo) ’Загружаем (или возвращаем) все записи гостевой книги в класс с приме-

нением объекта гидрации из служебных утилит DNN Return CBO.FillCollection(Of GBEntryIn-

fo)(DataProvider.Instance().GetAll(moduleid)) End Function End Class End Namespace

В приведенном коде используется класс гидратора CBO, постав-

ляемый фреймворком DNN. Данный класс включает различные методы гидрации (в контексте данного кода под гидрацией пони-мается чтение данных из базы и возращение их как объекта или коллекции объектов для загрузки в свойства класса, который пред-ставляет методы работы с данными).

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

126

скрипт пишется на версии языка TSQL с дополнительным использо-ванием токенов DNN «{databaseOwner}[{objectQualifier}», с кото-рыми работает используемая на хостинге СУБД. В нашем примере это MS SQL Server 2012. Токены при инсталляции модуля преобразуются DNN в специальные префиксы – значения. Алгоритм работы скрипта, который активируется при инсталляции модуля, следующий:

• создание таблиц, если таковых еще нет в базе; • изменение структуры таблиц для добавления первичных и

вторичных ключевых полей, индексирования; • проверка наличия нужных хранимых процедур в базе и при их

наличии – удаление из базы; • создание хранимых процедур. Файл скрипта находится в каталоге шаблона проекта MyPro-

ject\Providers\DataProvides\SqlDataProvider c названием 00.00.01 sqldataprovider. Приведем код с учетом синтаксиса:

/** Проверяем наличие таблицы в базе данных, если нет, то создается новая

таблица**/ if not exists (select * from dbo.sysobjects where id = object_id (N’{databaseOwner}[{objectQualifier} DNNModule1]’) and OBJECTPROPERTY(id, N’IsTable’) = 1) BEGIN /** Создаем новую таблицу**/ CREATE TABLE {databaseOwner}[{objectQualifier}DNNModule1] ( [moduleId] [int] NOT NULL, [entryId] [int] NOT NULL IDENTITY(1, 1), [name] nvarchar(255) NOT NULL, [website] nvarchar(255), [comment] ntext, [daterec] DateTime NOT NULL, [approved] BIT NOT NULL ) /**Добавляем в созданную таблицу первичный кластеризованный ключ

на основе поля ([EntryId], создаем некластеризованный индекс на основе поля [moduleID] **/

ALTER TABLE {databaseOwner} [{objectQualifier}DNNModule1]

127

ADD CONSTRAINT [PK_{objectQualifier}DNNModule1] PRIMARY KEY CLUSTERED ([EntryId]) CREATE NONCLUSTERED INDEX [IX_{objectQualifier}DNNModule1] ON {databaseOwner}[{objectQualifier}DNNModule1] ([moduleID]) /**Добавляем логическую связь между таблицами [DNNModule1] и [Modules]

на основе внешнего ключа [moduleID] c каскадным удалением данных**/ ALTER TABLE {databaseOwner}[{objectQualifier}DNNModule1] WITH NOCHECK ADD CONSTRAINT [FK_{objectQualifier}DNNModule1_{objectQualifier}Modules] FOREIGN KEY ([moduleID]) REFERENCES {databaseOwner}[{objectQualifier}Modules] ([moduleID]) ON DELETE CASCADE NOT FOR REPLICATION END GO /** Проверяем наличие хранимой процедуры «DNNModule1_InsertGBRec»

в базе данных, если есть, то удаляем ее**/ if exists (select * from dbo.sysobjects where id = object_id(N’{databaseOwner} [{objectQualifier}DNNModule1_InsertGBRec]’) and OBJECTPROPERTY(id, N’IsProcedure’) = 1) drop procedure {databaseOwner} [{objectQualifier}DNNModule1_InsertGBRec] GO /** Проверяем наличие хранимой процедуры «DNNModule1_ApproveGBrec» в

базе данных, если есть, то удаляем ее**/ if exists (select * from dbo.sysobjects where id = object_id(N’{databaseOwner} [{objectQualifier}DNNModule1_ApproveGBrec]’) and OBJECTPROPERTY(id, N’IsProcedure’) = 1) drop procedure {databaseOwner}[{objectQualifier}DNNModule1_ApprovedGBrec] GO /** Проверяем наличие хранимой процедуры «DNNModule1_DeleteGBrec»

в базе данных, если есть, то удаляем ее**/ if exists (select * from dbo.sysobjects where id = object_id(N’{databaseOwner}

128

[{objectQualifier}DNNModule1_DeleteGBrec]’) and OBJECTPROPERTY(id, N’IsProcedure’) = 1) drop procedure {databaseOwner}[{objectQualifier}DNNModule1_DeleteGBrec] GO /** Проверяем наличие хранимой процедуры «DNNModule1_GetApprovedRec»

в базе данных, если есть, то удаляем ее**/ if exists (select * from dbo.sysobjects where id = object_id(N’{databaseOwner} [{objectQualifier}DNNModule1_GetApprovedRec]’) and OBJECTPROPERTY(id, N’IsProcedure’) = 1) drop procedure {databaseOwner}[{objectQualifier}DNNModule1_GetApprovedRec] GO /** Проверяем наличие хранимой процедуры «DNNModule1_GetAll» в базе

данных, если есть, то удаляем ее**/ if exists (select * from dbo.sysobjects where id = object_id(N’{databaseOwner}[{objectQualifier} DNNModule1_GetAll]’) and OBJECTPROPERTY(id, N’IsProcedure’) = 1) drop procedure {databaseOwner}[{objectQualifier}DNNModule1_GetAll] GO /** Создаем в базе данных хранимую процедуру «DNNModule1_InsertGBRec»

для вставки данных в гостевую книгу**/ CREATE PROCEDURE {databaseOwner} [{objectQualifier}DNNModule1_InsertGBRec] @moduleId INT, @name NVARCHAR(255), @website NVARCHAR(255), @comment NTEXT, @date DATETIME, @approved BIT AS INSERT INTO {databaseOwner}[{objectQualifier}DNNModule1] (moduleId, name, website, comment, daterec, approved) VALUES (@moduleId, @name, @website, @comment, @daterec, @approved) GO

129

/**Создаем в базе данных хранимую процедуру «DNNModule1_ApproveGBrec» для вставки данных одобрения записей гостевой книги**/

CREATE PROCEDURE {databaseOwner}[{objectQualifier} DNNModule1_ApproveGBrec] @moduleId INT, @entryId INT AS UPDATE {databaseOwner}[{objectQualifier}DNNModule1] SET approved = 1 WHERE moduleId = @moduleId AND entryId = @entryId GO /**Создаем в базе данных хранимую процедуру «DNNModule1_DeleteGBrec»

для удаления записей гостевой книги**/ CREATE PROCEDURE {databaseOwner}[{objectQualifier}DNNModule1_DeleteGBrec] @moduleId INT, @entryId INT AS DELETE FROM {databaseOwner}[{objectQualifier}DNNModule1] WHERE moduleId = @moduleId AND entryId = @entryId GO /**Создаем в базе данных хранимую процедуру «DNNModule1_GetApprovedRec»

для возвращения одобренных записей гостевой книги**/ CREATE PROCEDURE {databaseOwner}[{objectQualifier}DNNModule1_GetApprovedRec] @moduleId INT AS SELECT moduleId, entryId, name, website, comment, daterec, approved FROM {databaseOwner}[{objectQualifier}DNNModule1] WHERE moduleId = @moduleId AND approved = 1 ORDER BY date DESC GO

130

/**Создаем в базе данных хранимую процедуру «DNNModule1_GetAll» для возвращения всех записей гостевой книги**/

CREATE PROCEDURE {databaseOwner}[{objectQualifier}DNNModule1_GetAll] @moduleId INT AS SELECT moduleId, entryId, name, website, comment, daterec, approved FROM {databaseOwner}[{objectQualifier}DNNModule1] WHERE moduleId = @moduleId ORDER BY daterec DESC GO

Следует отметить, что данный синтаксис не совсем обычен и

редактором SQL-кода в СУБД SQL Server будет воспринят с ошибка-ми, так как здесь применяются два префикса – {databaseOwn-er}{objectQualifier}. Из практического опыта данные скрипты лучше писать в модуле-редакторе SQL портала, доступном в меню под учетной записью суперпользователя (host). Указанные префик-сы здесь воспринимаются нормально, а также есть подсветка син-таксиса операторов языка TSQL. В момент установки модуля код провайдера DNN для баз данных SQL Server обрабатывает соответ-ствующим образом эти префиксы и подставляет значения соб-ственника базы данных и имя портала. По умолчанию собственник таблиц указывается dbo (например, имя таблицы будет выглядеть как dbo.DNNModule1). Если на одной инсталляции DNN только один сайт, то префикс {objectQualifier} игнорируется. В случае многопор-тальности вместо данного префикса к имени модуля подставляется имя сайта для гарантии использования одного и того же модуля на разных сайтах, имеющих одну СУБД.

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

131

структуру данных DNN. После установки таблиц в базе данных вы-полняются скрипты по проверке наличия хранимых процедур, их удаления и создания заново. Данные хранимые процедуры факти-чески производят обработку всей необходимой информации для работы модуля. Методы и типы данных хранимых процедур зеркально отражают логику модуля, созданных методов в коде классов провайдера данных (DataProvider.vb, SQLDataProvider.vb), свойств (GBEntryInfo.vb) и контроллера (GBController.vb). Анало-гичный код, но только для удаления объектов базы данных, при-надлежащих конкретному модулю, прописывается в файле деин-сталяции UnInstall.sqldataprovider.

Мы рассмотрели технику на уровне программного кода модуля, как создавать уровень бизнес-логики, уровень доступа к данным и саму структуру данных в СУБД. Теперь для модуля необходимо со-здать его интерфейс пользователя, включая настройки модуля и режим редактирования контента. По технологии DNNcorp целесо-образно начинать создание интерфейса модуля с дизайна элемента управления настроек. Данный элемент включает в себя собственно файл разметки Settings.ascx, файл отдельного кода логики элемента управления Settings.ascx.vd, файл локализации контента Set-tings.ascx.resx. В Visual Studio перейдем в обозреватель решения и откроем файл Settings.ascx. Пропишем код разметки:

’Объявляем, что данный файл является пользовательским элементом

управления, будет использоваться язык программирования логики «Visual Basic.Net», будет включено автоматическое подключение событий для данного элемента к функциям обработки событий, указываем файл кода логики и наследование от класса.

<%@ Control Language="vb" AutoEventWireup="true" CodeBehind= "Settings.ascx.vb" Inherits="GBModule.Settings" %>

’Регистрируем в элементе управления настроек дополнительный элемент управления “Label”

<%@ Register TagName="label" TagPrefix="dnn" Src="~/controls/labelcontrol.ascx" %>

’Создаем таблицу для расположения на странице элементов управления <table cellspacing="0" cellpadding="2" border="0"

summary="Guestbook CS Design Table"> ’Создаем строку таблицы <tr> ’Создаем ячейку и вкладываем элемент управления «dnn:Label» <td class="SubHead" width="50"> <dnn:label id="lblAllowAnon" runat="server" controlname="chkAllowAnon"

suffix=":"/> </td>

132

’Создаем ячейку и вкладываем элемент управления «asp:CheckBox» <td> <asp:CheckBox ID="chkAllowAnon" runat="server" /> </td> </tr> <tr> ’Создаем ячейку и вкладываем элемент управления «dnn:Label» <td class="SubHead"> <dnn:Label ID="lblEnableCaptcha" runat="server" Con-

trolName="chkEnableCaptcha" Suffix=":" / > </td> ’Создаем ячейку и вкладываем элемент управления «asp:CheckBox» <td> <asp:CheckBox ID="chkEnableCaptcha" runat="server" /> </td> </tr> <tr> ’Создаем ячейку и вкладываем элемент управления «dnn:Label» <td class="SubHead" > <dnn:Label ID="lblModerateEntries" runat="server" Con-

trolName="chkModerateEntries" Suffix=":" /> </td> ’Создаем ячейку и вкладываем элемент управления «asp:CheckBox» <td> <asp:CheckBox ID="chkModerateEntries" runat="server" /> </td> </tr> </table> Как видно, это простой код разметки внешнего вида настроек

модуля, включающий таблицу с элементами управления надписи (label) и установки флажка (checkbox). Данные настройки устанав-ливают следующие параметры модуля: позволить анонимным пользователям внести сообщения; включить CAPTCHA; моделиро-вать сообщения. Для реализации работы элементов управления и внесения настроек модуля в базу данных портала DNN необходи-мо прописать процедуры считывания и обновления настроек в файл отдельного кода элемента управления Settings.ascx.vb. Открываем в Visual Studio данный файл и пишем программный код логики.

’Импортируем пространства имен, необходимые для работы модуля Imports System.Web.UI Imports DotNetNuke Imports DotNetNuke.Services.Exceptions

133

’Создаем унаследованный касс «Settings» Public Class Settings Inherits DNNModule1SettingsBase ’Отмечаем блок кода #Region "Base Method Implementations" ’Создаем переопределяемую процедуру загрузки настроек модуля Public Overrides Sub LoadSettings() ’Создаем обработчик ошибок в процедуре Try ’Проверяем, если веб-страница отрисовывается в первый раз, то If (Page.IsPostBack = False) Then ’Проверяем, если значение поля «GBModule_sett_AllowAnon» в таблице

настроек для модуля в базе данных не пустое, то присваиваем элементу управ-ления «chkAllowAnon» значение поля.

If CType(ModuleSettings("GBModule_sett_AllowAnon"), String) <> ""Then chkAllowAnon.Checked = Boole-

an.Parse(ModuleSettings("GBModule_sett_AllowAnon").ToString()) End If ’Проверяем, если значение поля «GBModule_sett_EnableCaptcha» в таблице

настроек для модуля в базе данных не пустое, то присваиваем элементу управ-ления «chkEnableCaptcha» значение поля.

If CType(ModuleSettings("GBModule_sett_EnableCaptcha"), String) <> "" Then chkEnableCaptcha.Checked = Boole-

an.Parse(ModuleSettings("GBModule_sett_EnableCaptcha").ToString()) End If ’Проверяем, если значение поля «GBModule_sett_ModerateEntries» в таблице

настроек для модуля в базе данных не пустое, то присваиваем элементу управ-ления «chkModerateEntries» значение поля.

If CType(ModuleSettings("GBModule_sett_ModerateEntries"), String) <> "" Then

chkModerateEntries.Checked = Boolean.Parse(ModuleSettings("GBModule_sett_ModerateEntries").ToString())

End If End If ’В случае возникновения ошибок в модуле будет выдано сообщение Catch exc As Exception 'Module failed to load ProcessModuleLoadException(Me, exc) End Try End Sub ’Создаем общую процедуру обновления настроек модуля Public Overrides Sub UpdateSettings() ’Создаем обработчик ошибок Try ’Инициируем новый объект контроллера модуля Dim objModules As New Entities.Modules.ModuleController

134

’Обновляем свойство в поле таблицы "GBModule_sett_AllowAnon" objModules.UpdateModuleSetting(ModuleId, "GBModule_sett_AllowAnon",

chkAllowAnon.Checked.ToString()) ’Обновляем свойство в поле таблицы "GBModule_sett_EnableCaptcha" objModules.UpdateModuleSetting(ModuleId, "GBModule_sett_EnableCaptcha",

chkEnableCaptcha.Checked.ToString()) ’Обновляем свойство в поле таблицы "GBModule_sett_ModerateEntries" objModules.UpdateModuleSetting(ModuleId, "GBMod-

ule_sett_ModerateEntries", chkModerateEntries.Checked.ToString()) ’В случае возникновения ошибок в модуле будет выдано сообщение Catch exc As Exception ProcessModuleLoadException(Me, exc) End Try End Sub #End Region End Class

В данном коде реализованы две переопределяемые процедуры

для загрузки настроек модуля и их обновления. Настройки хранят-ся в специальной таблице базы данных, и за работу с ней отвечает программный класс контроллера модулей DNN – ModuleController. При загрузке происходит считывание информации из свойства ModuleSettings класса, и если это значение не пустое, то соответ-ствующему элементу управления, в нашем случае чекбоксу, при-сваивается значение из базы данных, предварительно преобразо-ванное в булевое значение. При открытии окна свойств модуля на сайте будет отражено ряд вкладок, последняя из которых носит имя нашего модуля, в которой отображаются средства управления настройками, в частности три чекбокса с установленными флажка-ми. При настройке данных свойств работы модуля после нажатия кнопки «Обновить» (Update) в работу включается процедура об-новления с функцией контроллера модуля UpdateModuleSetting, от-вечающая за сохранение или обновление, параметрами которой выступают: идентификационный номер модуля, имя параметра настройки в базе, параметр элемента управления, который будет записан в базу данных под указанным именем в процессе сохране-ния настроек. Как видно из кода, встроенные функции и свойства ModuleSettingsBase значительно облегчают реализацию подсисте-мы настроек разрабатываемого модуля, делают код удобным для работы и понимания.

Следующим шагом в программировании модуля гостевой книги будет создание дополнительного элемента ViewSettings.ascx к ос-

135

новным настройкам модуля, который должен связать два главных элемента управления модуля гостевой книги для отображения на странице сайта View.ascx и SignGuestbook.ascx при помощи вы-бора соответствующего модуля в выпадающем списке. В Visual Stu-dio кликаем правой кнопкой мыши по нашему проекту, выбираем в меню «Добавить – Новый пункт», далее кликаем Web Form User Control, прописываем имя нашего элемента управления ViewSet-tings.ascx. Пропишем код разметки, или элементов интерфейса, ко-торые будут располагаться на странице настроек.

’Объявляем, что данный файл является пользовательским элементом управления, будет использоваться язык программирования логики «Visual Basic.Net», будет включено автоматическое подключение событий для данного элемента к функциям обработки событий, указываем файл кода логики и наследование от класса «DNNModule1.ViewSettings». <%@ Control Language="vb" AutoEventWireup="false" CodeBehind="ViewSettings.ascx.vb" Inher-its="DotNetNuke.Modules.DNNModule1.ViewSettings"%> ’Регистрируем в элементе управления настроек дополнительный элемент управления “Label” <%@ Register TagName="Label" TagPrefix ="dnn" Src="~/controls/LabelControl.ascx" %> 'Создаем таблицу для расположения на странице элементов управления <table> ’Создаем строку таблицы <tr> ’Создаем ячейку и вкладываем элемент управления «dnn:Label» <td class="SubHead" width="100px"> <dnn:Label id="lblSignModule" runat ="server" controlname ="ddlSignModule" suffix=":"/> </td> ’Создаем ячейку и вкладываем элемент управления выпадающего списка «asp:DropDownList» <td> <asp:DropDownList ID="ddlSignModule" runat="server" CssClass="NormalTextbox"> </asp:DropDownList> </td> </tr>

</table>

В данном коде создается элемент управления с выпадающим спис-ком, в котором производится выбор прикрепляемого элемента управ-ления для вывода элемента управления Sign. HTML-элемент <table> создает ячейки для вложения ASP.Net элементов управления.

136

Код логики элемента управления в файле ViewSettings.ascx.vb по существу аналогичен коду в элементе управления Settings.ascx, за исключением некоторых функций. Пропишем код:

'Импортируем необходимые пространства имен Imports System.Web.UI Imports DotNetNuke Imports DotNetNuke.Entities.Modules 'Создаем общий наследуемый класс Public Class ViewSettings Inherits Entities.Modules.ModuleSettingsBase 'Создаем блок кода #Region "Base Method Implementations" 'Создаем переопределяемую процедуру загрузки настроечных параметров Public Overrides Sub LoadSettings() 'Инициируем контроллер модуля Dim oController As New ModuleController 'Создаем через объект словаря коллекцию ключей и значений модуля всех

установок модуля на страницах сайта Dim oModules As Dictionary(Of Integer, ModuleInfo) = oControl-

ler.GetTabModules(Me.TabId) 'Определяем данные для выпадающего списка на форме – источник данных,

заголовок модуля и ключ модуля ddlSignModule.DataSource = oModules.Values ddlSignModule.DataTextField = "ModuleTitle" ddlSignModule.DataValueField = "ModuleId" 'Загружаем данные в выпадающий список ddlSignModule.DataBind() 'Проверяем наличие настроек модуля в базе данных, если не пустое значе-

ние поля, то делаем его выбор в выпадающем списке If CType(ModuleSettings("GBModule_sett_signmodule"), String) <> "" Then 'Присваиваем значение настройки в выпадающем списке ddlSignModule.SelectedValue =

CType(ModuleSettings("GBModule_sett_signmodule"), String) End If End Sub 'Создаем общую процедуру для обновления настроек модуля Public Overrides Sub UpdateSettings() 'Инициируем контоллер модуля Dim oController As New ModuleController 'Обновляем поле в базе данных значением, выбранным в выпадающем списке oController.UpdateModuleSetting(Me.ModuleId, "GBModule_sett_signmodule",

ddlSignModule.SelectedValue) End Sub #End Region End Class

137

В данном коде для отображения списка модулей в перегружа-емой процедуре LoadSettings в элементе управления выпадаю-щего списка реализуется словарь с форматом данных пары «ключ/значение», в который загружается информация из контрол-лера модулей. Затем словарь oModules определяется как источник данных для элемента управления выпадающего списка, в котором выбирается нужный модуль на сайте.

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

’Объявляем, что данный файл является пользовательским элементом

управления, будет использоваться язык программирования логики «Visual Basic.Net», будет откючено автоматическое подключение событий для данно-го элемента к функциям обработки событий, должны быть указаны операто-ры для объявления переменных, указываем файл кода логики и наследование от класса «DNNModule1. ViewGB»

<%@ Control Language="vb" AutoEventWireup="false" CodeBehind="ViewGB.ascx.vb" Explicit = "True" Inherits="DotNetNuke.Modules.DNNModule1.ViewGB" %>

'Прописываем контейнерный элемент управления «Repeater» с обозначени-ем события привязки данных

<asp:Repeater ID="repEntry" runat="server" OnItemDataBound="repEntry_ItemDataBound">

'Обозначаем шаблон загаловока элемента управления «Repeater» и кладем туда элемент управления «Literal»

<HeaderTemplate> <asp:Literal ID="literalHeader" runat="server"></asp:Literal> </HeaderTemplate> 'Обозначаем тело и содержание элемента управления «Repeater» и кладем

туда элемент управления «Literal» <ItemTemplate> <asp:Literal ID="literalItem" runat="server"></asp:Literal> </ItemTemplate>

138

'Обозначаем шаблон альтернативного вида элемента управления, отобра-жаемый один раз для каждого второго элемента данных

<AlternatingItemTemplate> <asp:Literal ID="literalAlternateItem" runat="server"></asp:Literal> </AlternatingItemTemplate> 'Обозначаем шаблон нижнего колонтитула элемента управления гостевой

книги <FooterTemplate> <asp:Literal ID="literalFooter" runat="server"></asp:Literal> </FooterTemplate> </asp:Repeater> 'Обозначаем элемент управления метки для сообщения отсутствия запи-

сей в гостевой книге <asp:Label id="lbNotRec" runat="server" CssClass="normal" re-

sourcekey="lbNotRec"></asp:Label> В данной разметке используется элемент управления Repeater,

который может повторять блоки с одинаковыми колонтитулами, что необходимо для сохранения шаблона каждой записи гостевой книги. Вся дальнейшая логика работы элемента управления запро-граммирована в файле отдельного кода ViewGB.ascx.vb. Приведем код логики.

'Импортируем необходимые пространства имен Imports System.Web.UI Imports System.Collections.Generic Imports System.Reflection Imports DotNetNuke Imports DotNetNuke.Services.Exceptions Imports DotNetNuke.Services.Localization Imports DotNetNuke.Modules.DNNModule1.DNNModule1 'Создаем общий наследуемый класс Public Class ViewGB Inherits Entities.Modules.PortalModuleBase 'Создаем процедуру обработки события загрузки страницы Protected Sub Page_Load(ByVal sender As Object, ByVal e As

System.EventArgs) Handles MyBase.Load 'Создаем обработчик ошибок Try 'Проверяем условие загрузки веб-страницы в первый раз If Not IsPostBack Then 'Проверяем наличие параметров настроек в базе данных If CType(Settings("GBModule_sett_signmodule"), String) <> "" Then Инициируем объект контроллера модуля для работы с данными Dim obj_Controller As New GBController

139

'Создаем список объектов свойств, в котором будут храниться записи гостевой книги

Dim obj_Entries As List(Of GBEntryInfo) 'Создаем переменную для хранения идентификационного номера модуля Dim int_SinglModuleID As Integer =

Integer.Parse(Settings("GBModule_sett_signmodule")) 'Если модуль находится в режиме редактирования, то загружаем все запи-

си указанного модуля If IsEditable Then obj_Entries = obj_Controller.GetAll(int_SinglModuleID) Else 'Если модуль находится в режиме просмотра, то загружаем одобренные

записи гостевой книги obj_Entries = obj_Controller.GetApprovedRec(int_SinglModuleID) End If 'Если в книге есть записи, то присваиваем источник данных в ввиде списка

объектов элементу управления «Repeater» If obj_Entries.Count > 0 Then repEntry.DataSource = obj_Entries 'Производим загрузку данных в элемент управления «Repeater» repEntry.DataBind() 'Запрещаем отображение метки отсутствия записей lbNotRec.Visible = False Else 'При отсутствии записей в гостевой книге запрещаем отображение эле-

мента управления «Repeater» repEntry.Visible = False End If Else 'При отсутствии привязки модуля ввода данных к модулю отображения

записей запрещаем отображение элемента управления «Repeater» repEntry.Visible = False 'Выводим на веб-форму сообщение об отсутствии настроек модуля с уче-

том локализации сайта Dim massage As String = Localization.GetString("NotConfigured",

Me.LocalResourceFile) DotNetNuke.UI.Skins.Skin.AddModuleMessage(Me, massage,

UI.Skins.Controls.ModuleMessage.ModuleMessageType.YellowWarning) End If End If 'Выводим сообщение при возникновении ошибки в процедуре Catch exc As Exception ProcessModuleLoadException(Me, exc) End Try End Sub

140

'Создаем процедуру обработки события загрузки данных каждой записи гостевой книги в элемент управления «Repeater»

Protected Sub repEntry_ItemDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.RepeaterItemEventArgs) Handles re-pEntry.ItemDataBound

'Обрабатываем событие вставки данных в загаловок строки элемента управления «Repeater»

If e.Item.ItemType = ListItemType.Header Then 'Создаем переменную как объект элемента управления «Literal» и присваи-

ваем ему заголовок в элементе управления «Repeater» Dim literalHeader As Literal = CType(e.Item.FindControl("literalHeader"),

Literal) 'Переносим в заголовок локализованный текст шаблона заголовка гостевой

книги literalHeader.Text = Localization.GetString("HeaderTemplate",

Me.LocalResourceFile) 'Обрабатываем событие вставки данных в нижний колонтитул элемента

управления «Repeater» ElseIf e.Item.ItemType = ListItemType.Footer Then Dim literalFooter As Literal = CType(e.Item.FindControl("literalFooter"),

Literal) literalFooter.Text = Localization.GetString("FooterTemplate",

Me.LocalResourceFile) 'Обрабатываем событие вставки данных в тело элемента управления «Re-

peater» ElseIf e.Item.ItemType = ListItemType.Item Then Dim literalItem As Literal = CType(e.Item.FindControl("literalItem"), Literal) 'Создаем объект для загрузки данных гостевой книги в элемент управления

«Repeater» посредством созданного ранее класса «GBEntryInfo» Dim obj_DataItem As GBEntryInfo = CType(e.Item.DataItem, GBEntryInfo) 'Создаем объект шаблона для локализации надписей столбцов гостевой

книги в элементе управления «Repeater» Dim obj_Template As String = Localization.GetString("ItemTemplate",

Me.LocalResourceFile) 'Вызываем процедуру «LoadEntryInfo» загрузки записей гостевой книги

в тело элемента управления «Repeater», передаем ей необходимые параметры LoadEntryInfo(literalItem, obj_DataItem, obj_Template) 'Обрабатываем событие вставки данных в каждую вторую строку эле-

мента управления «Repeater» ElseIf e.Item.ItemType = ListItemType.AlternatingItem Then Dim literalitem As Literal = CType(e.Item.FindControl("literalAlternateItem"),

Literal) 'Создаем объект для загрузки данных гостевой книги в элемент управления

«Repeater» посредством созданного ранее класса «GBEntryInfo» Dim obj_DataItem As GBEntryInfo = CType(e.Item.DataItem, GBEntryInfo)

141

Dim obj_Template As String = Localization.GetString("AlternateItemTemplate", Me.LocalResourceFile)

'Вызываем процедуру «LoadEntryInfo» загрузки каждой второй записей гостевой книги в тело элемента управления «Repeater», передаем ей необходи-мые параметры

LoadEntryInfo(literalitem, obj_DataItem, obj_Template) End If End Sub 'Создаем процедуру загрузки записей гостевой книги в элемент управления

«Repeater» с приемом параметров элемента управления Literal, класса свойств-данных гостевой книги, строковой переменной, содержащей локали-зованный текст

Private Sub LoadEntryInfo(ByVal literalitem As Literal, ByVal obj_info As GBEntryInfo, ByVal template As String)

'Создаем объект построителя строк с параметром строковой переменной локализованного текста

Dim obj_Display As New StringBuilder(template) 'Производим замену в локализованном шаблоне записей на стандартные

токены шаблона оформления DNN для настройки внешнего вида записей гос-тевой книги

obj_Display.Replace("[NAME]", obj_info.name) obj_Display.Replace("[WEBSITE]", obj_info.website) obj_Display.Replace("[COMMENT]", obj_info.comment) obj_Display.Replace("[DATE]", obj_info.datarec.ToString()) 'Если модуль находится в режиме редактирования, то создаем кнопки ре-

дактирования и удаления записей гостевой книги в виде гиперссылок If IsEditable Then Dim deleteurl As String = String.Format("<a href='{0}'>Delete</a>",

EditUrl("EntryId", obj_info.entryid.ToString(), "Edit", "delete=1")) obj_Display.Replace("[DELETE]", deleteurl) Dim approveUrl As String = "" 'Если запись гостевой книги не одобрена для публикации, создаем кнопку

одобрения записи модератором сайта If Not obj_info.approved Then approveUrl = String.Format("<a href='{0}'>Approve</a>", EditUrl("EntryId",

obj_info.entryid.ToString(), "Edit", "approve=1")) End If 'Производим замену ссылки одобрения записи на стандартный токен obj_Display.Replace("[APPROVE]", approveUrl) 'Если модуль находится не в режиме редактирования, то деактивируем

кнопки удаления и одобрения записи в гостевой книге Else obj_Display.Replace("[DELETE]", "") obj_Display.Replace("[APPROVE]", "") End If

142

'Отображаем отформатированный текст в элементе управления "Repeater" literalitem.Text = obj_Display.ToString() End Sub End Class Приведенный код состоит из нескольких процедур обработки

событий. Первоначально при загрузке станицы с модулем гостевой книги производится проверка на готовность страницы к просмотру в первый раз, если да, то проверяется наличие свойства настроек модуля. Если значение свойства внесено в базу данных, то в пере-менную передается значение свойства уникального ключа записей гостевой книги и инициализируется два созданных ранее класса свойств и методов работы с данными модуля. Если модуль нахо-дится в режиме редактирования и в объекте obj_Entries присут-ствуют записи, то свойству DataSource элемента управления Repeater присваивается источник данных obj_Entries. Данный объ-ект через систему абстрагирования и гидрирования получает все данные из базы данных при помощи методов класса GBController. Если режим редактирования в модуле не выбран, то в объект свойств возвращаются только одобренные записи. При отсутствии параметров настроек модуля в базе в модуль возвращается, ис-пользуя классы DNN для работы с локализацией и шаблоном оформления, текст NotConfigured.

При загрузке данных в элемент управления происходит обра-ботка события связывания с данными по каждому внутреннему элементу RepeaterItem, т.е. у каждой записи гостевой книги форми-руется локализованные верхний и нижний колонтитулы плюс сама запись. При загрузке самой отдельной записи гостевой книги ис-пользуется пользовательская функция LoadEntryInfo без возврата значения, т.е. обычная процедура, которая производит статиче-скую замену текста на стандартные ключевые элементы – токены – шаблона оформления DNN, перечисленные в табл. 4.

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

После создания необходимого файла ресурсов ViewGB.ascx.resx для данного элемента управления нужно создать и написать код для элементов управления Edit.ascx и SignGuestbook.ascx, необходи-

143

мые для перехода в режим редактирования записей гостевой книги и собственно ввода данных пользователем сайта в книгу. Элемент управления Edit.ascx не имеет пользовательского интерфейса, по-этому перейдем к рассмотрению программного кода его работы.

Таблица 4

Ключевые элементы шаблона оформления (токены), применяемые в модуле гостевой книги

Ключевой элемент шаблона

Описание

[NAME] Выводит полное имя пользователя, оставившего запись в гостевой книге

[WEBSITE] Адрес сайта, на котором был добавлен комментарий в гостевой книге

[COMMENT] Собственно комментарии, оставленные пользователем [DATE] Обеспечивает дату и время создания записи в книге [APPROVE] Отображает ссылку для одобрения записи в книге администратором,

если запись еще не одобрена [DELETE] Отображение ссылки для удаления записи только для администра-

торов

'Импортируем в модуль необходимые пространства имен Imports DotNetNuke Imports DotNetNuke.Common Imports DotNetNuke.Entities.Modules Imports DotNetNuke.Services.Exceptions Imports DotNetNuke.Services.Localization Imports DotNetNuke.Modules.DNNModule1.DNNModule1 'Создаем разделяемый класс Edit Partial Class Edit Inherits DNNModule1ModuleBase Private entryid As Integer 'Создаем процедуру обработки события загрузки страницы Protected Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs)

Handles Me.Load 'Создаем обработчик ошибок Try 'Проверяем первоначальную загрузку страницы If Page.IsPostBack = False Then 'Проверяем наличие значения id записи в HTML строке запроса If Not (Request.QueryString("Entryid") Is Nothing) Then 'Преобразуем параметр строки запроса в число entryid = Int32.Parse(Request.QueryString("Entryid"))

144

'Создаем логическую переменную и присваиваем ей нулевое значение Dim approved As Boolean = False 'Проверяем наличие значения параметра "approved" в HTML строке

запроса If Not (Request.QueryString("approved") Is Nothing) Then 'Присваиваем значение переменной approved = True End If 'Создаем объект пользовательского класса конроллера для работы с дан-

ными Dim obj_Conrtoller As New GBController 'Проверяем наличие логического «да» в переменной «approved» If (approved) Then 'Посредством метода объекта заносим в базу данных параметр одобрения

записи гостевой книги obj_Conrtoller.ApproveGBrec(Me.ModuleId, entryid) End If 'При отсутствии в записи в HTML-строке запроса значения id записи про-

изводим удаление записи гостевой книги obj_Conrtoller.DeleteGBrec(Me.ModuleId, entryid) End If 'Обновляем информацию о модуле в кэше портала ModuleController.SynchronizeModule(Me.ModuleId) End If 'Если страница ожидает возврат данных с сервера, то производим переза-

грузку веб-страницы Response.Redirect(NavigateURL(Me.TabId)) 'При возникновении ошибки в процедуре выводим сообщение Catch exc As Exception Exceptions.ProcessModuleLoadException(Me, exc) 'Производим перезагрузку веб-страницы Response.Redirect(NavigateURL(Me.TabId)) End Try End Sub End Class

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

145

информацию модуля в кэш-памяти портала после выполненных действий одобрения записи или удаления данных в гостевой книге.

В завершение программирования модуля необходимо создать элемент управления ввода данных записей пользователем в книгу. Аналогично предыдущим элементам управления в наш проект Vis-ual Studio DNNModule1 добавим пользовательский элемент веб-формы Web Form User Control – SignGB.ascx. Разметка интерфейса пользователя проста, состоит из меток, тактовых полей и ссылок, включенных в ячейки таблицы, которая вложена в asp-панель. Приведем разметку:

'Объявляем, что данный файл является пользовательским элементом

управления, будет использоваться язык программирования логики «Visual Basic.Net», будет отключено автоматическое подключение событий для дан-ного элемента к функциям обработки событий, указываем файл кода логики и наследование от класса «DNNModule1.SignGB»

%@ Control Language="vb" AutoEventWireup="false" CodeBehind= "SignGB.ascx.vb" Inherits="DotNetNuke.Modules.DNNModule1.SignGB" %>

'Регистрируем элемент управления метки DNN <%@ Register TagPrefix="dnn" TagName="Label"

Src="~/controls/LabelControl.ascx" %> 'Создаем панель для вкладывания таблицы с элементами управления <asp:Panel ID="pnlSignGuestbook" runat="server" > 'Создаем HTML таблицу <table> 'Создаем строку в HTML-таблице <tr> 'Создаем ячейку в таблице, вставляем в нее элемент управления метки <td class="SubHead" width="200" > <dnn:Label id="lblName" runat="server" ControlName="txtName" Suffix=":" /> </td> <td> 'Создаем текстовое поле для имени пользователя <asp:TextBox ID="txtName" runat="server" MaxLength="255"

CssClass="NormalTextbox" ValidationGroup="Guestbook" /> </td > </tr> <tr> <td class="SubHead" > 'Создаем элемент управления метки веб-сайта <dnn:Label ID="lblWebsite" runat="server" ControlName="txtWebsite"

Suffix=":" /> </td > <td >

146

'Создаем текстовое поле для обозначения веб-сайта <asp:TextBox ID="txtWebsite" runat="server" MaxLength="255"

CssClass="NormalTextbox" ValidationGroup="Guestbook" /> </td> </tr> <tr> <td class="SubHead"> 'Создаем надпись для поля ввода записи гостевой книги (комментария) <dnn:Label ID="lblComment" runat="server" ControlName="txtComment"

Suffix=":" /> </td> <td> 'Создаем текстовое поле для ввода комментария <asp:TextBox ID="txtComment" runat="server" TextMode="MultiLine"

CssClass="NormalTextbox" ValidationGroup="Guestbook" width="200px" Height="50px" />

</td> </tr> <tr> <td colspan="2"> & nbsp; </td > </tr > <tr> <td colspan="2"> 'Создаем кнопку в виде гиперссылки для вставки пользователем введенной

записи в гостевую книгу <asp:LinkButton ID="btnSign" runat="server" CssClass="CommandButton"

ValidationGroup="Guestbook" resourcekey="btnSign" onclick="btnSign_Click" /> </td> </tr> </table> 'Создаем управляемую панель как контейнер для элемента управления метки </asp:Panel> <asp:Panel ID="pnlCannotSign" runat="server"> 'Создаем метку для отображения записи об отсутствии настроенных

параметров <asp:Label ID="lblCannotSign" runat="server" CssClass="Normal"

resourcekey="lblCannotSign" /> </asp:Panel>

B контроллах формы прописан атрибут ValidationGroup=

"Guestbook", который обеспечивает правильное отображение тек-стовых полей, если на странице будут применяться различные средства проверки правильности ввода данных в поля в соответ-

147

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

'Импортируем в модуль необходимые пространства имен Imports DotNetNuke Imports DotNetNuke.Common Imports DotNetNuke.Entities.Modules Imports DotNetNuke.Services.Exceptions Imports DotNetNuke.Services.Localization Imports DotNetNuke.Modules.DNNModule1.DNNModule1 'Создаем класс, наследуемый от базового класса модулей DNN Partial Class SignGB Inherits Entities.Modules.PortalModuleBase 'Создаем процедуру обработки события загрузки страницы Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)

Handles Me.Load 'Проверяем, загружается ли веб-страница в первый раз If Page.IsPostBack = False Then 'Проверяем настройки модуля на разрешение добавления записей в госте-

вую книгу неавторизованными пользователями сайта If CType(Settings("GBModule_sett_AllowAnon"), String) <> "" Then 'Если настройки есть, то создаем переменную для хранения логического

значения (да/нет) Dim allowanon As Boolean 'Присваиваем созданной переменной значение настроек модуля allowanon = Boolean.Parse(CType(Settings("GBModule_sett_AllowAnon"),

String)) 'Проверяем, если на сайте гость и анонимному пользователю запрещен

доступ к вводу записи гостевой книги, то скрываем панель с элементами управления ввода записи в модуле

If UserId = -1 AndAlso Not allowanon Then pnlSignGuestbook.Visible = False Else 'Иначе скрываем панель с элементами управления при зарегистрированных

пользователях сайта pnlCannotSign.Visible = False End If Else 'При отсутствии настроек модуля скрываем все панели с элементами

управления и выводим сообщение предупреждения на странице pnlCannotSign.Visible = False pnlSignGuestbook.Visible = False Dim str_message As String = Localization.GetString("NoConfigured",

Me.LocalResourceFile)

148

DotNetNuke.UI.Skins.Skin.AddModuleMessage(Me, str_message, UI.Skins.Controls.ModuleMessage.ModuleMessageType.YellowWarning)

End If End If End Sub 'Создаем процедуру обработки события нажатия кнопки пользователем

для ввода на сайт записи в гостевую книгу Protected Sub Lnk_Sign_click(ByVal sender As Object, ByVal e As EventArgs)

Handles Lnk_Sign.Click 'Проверяем, успешно ли завершилась проверка страницы If Page.IsValid Then 'Создаем объект контроллера работы с данными Dim obj_controller As New GBController 'Создаем объект для ввода значений с полей элементов управления модуля Dim obj_info As New GBEntryInfo 'Присваиваем свойству id записи значение -1 obj_info.entryid = -1

'Присваиваем свойству id модуля obj_info.moduleid = Me.ModuleId 'Присваиваем свойству текущую дату и время obj_info.datarec = System.DateTime.Now 'Присваиваем свойству введенный пользователем сайта комментарий

в гостевую книгу, преобразовав его в формат HTML obj_info.comment = Server.HtmlEncode(txtComment.Text) 'Присваиваем свойству имя пользователя сайта, преобразовав его в фор-

мат HTML obj_info.name = Server.HtmlEncode(txtName.Text) 'Присваиваем свойству имя сайта, преобразовав его в формат HTML obj_info.website = Server.HtmlEncode(txtWebsite.Text) 'Присваиваем свойству одобрения записи значение параметра, находящееся

в базе данных, которое указываем, модерировать записи или нет obj_info.approved = Not Boolean.Parse(CType(Settings("GBModule_sett_

ModerateEntries"), String)) 'Производим вставку введенной пользователем записи в базу данных obj_controller.InsertGBRec(obj_info) 'Создаем переменную для вывода локализованного сообщения на странице Dim str_message As String = "" 'Проверяем, нужно ли модерировать введенную запись, если нет, то выво-

дим сообщение, что запись успешно добавлена в книгу If obj_info.approved Then str_message = Localization.GetString("success", Me.LocalResourceFile) ModuleController.SynchronizeModule(Me.Module) Else 'При необходимости модерирования выводим сообщение о том, что запись

успешно отправлена модератору для утверждения публикации на сайте

149

oMessage = Localization.GetString("SuccessModerated", Me.LocalResourceFile) ModuleController.SynchronizeModule(Me.Module) End If DotNetNuke.UI.Skins.Skin.AddModuleMessage(Me, str_message, UI.Skins.

Controls.ModuleMessage.ModuleMessageType.GreenSuccess) End If End Sub End Class В коде при загрузке страницы проверятся, ожидает ли страница

обратной передачи с сервера. Если нет, то проверяются настройки для добавления записей в гостевую книгу неавторизованными пользователями. В случае, если разрешения на ввод анонимными пользователями нет и пользователь не авторизован, то блокируется отображение формы ввода записей и выводится сообщение о невозможности внесения информации в книгу. Если в базе не найдено конфигурационных параметров, то форма полностью блокируется и выводится сообщения об отсутствии конфигураций. После внесения информации в текстовые поля и нажатия на ги-перссылку Lnk_Sign все данные полей переносятся в свойства ини-циализированного класса GBEntryInfo, который через переменную obj_info передается параметром в метод InsertGBRec объекта (класса) GBEnryInfo, далее производящий вставку информации в базу дан-ных SQlServer через систему абстрагирования.

Итак, мы завершили программирование модуля гостевой книги для нашего интернет-магазина. Так как в нашем проекте добавлено еще два элемента управления веб-формы – SignGB.ascx и ViewSet-tings.ascx, – то их необходимо прописать в файле манифеста .dnn, для того чтобы инсталлятор портала распознал данные элементы в процессе установки модуля. В проекте Visual Studio открываем xml-файл DNNModule1.dnn и добавляем еще два раздела с тегами <moduleControl> </ moduleControl > аналогично уже существующим разделам в файле, меняя только названия элементов управоения и их тип, т.е. просмотр (View) или редактирование (Edit). Так как мы добавили в проект еще несколько файлов ресурсов .resx, необходи-мо в файл манифеста внести секции для инсталлятора DNN следу-ющего формата:

<file> <path>app_localresources</path> <name>SignGB.ascx.resx</name> </file>

150

<file> <path> app_localresources </path>

<name>ViewSettings.ascx.resx</name> </file> <file> <name>SignGB.ascx</name> </file> <file> <name>ViewGB.ascx</name> </file>

Затем делается сборка решения в режиме Debug и Relise и

сформированный инсталляционный пакет DNNModule1_00.00.01_ Install.zip, находящийся в папке Install текущего проекта Visual Stu-dio устанавливается через мастер установки расширений портала.

После добавления модуля на страницу появятся следующие формы в режиме ввода записи гостевой книги и редактирования (рис. 52–54).

Рис. 52. Форма ввода данных в гостевую книгу

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

151

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

• Обязательное применение программных классов платформы DNN, например, таких как Entities.Modules.PortalModuleBase, ModuleSettingsBase, Seirvices.Exceptions, Services.Localization.

Рис. 53. Отображение введенных данных в модуль гостевой книги

Рис. 54. Форма в режиме редактирования записей гостевой книги

• Разграничение элементов управления модуля по функциональ-ности, обеспечивающих просмотр контента (View.ascx), настройку работы модуля (Settings.ascx), редактирование контента (Edit.ascx).

• Реализация программного абстрагирования доступа к дан-ным модуля посредством пользовательских классов DataProvid-er, SqlDataProvider, [название модуля]Info, [название моду-

152

ля]Controller. В нашем примере модуля последние классы назы-ваются GBInfo, GBController.

• Реализация скрипта для создания таблиц и хранимых проце-дур в СУБД и скрипта удаления этих объектов из базы в процессе деинсталляции модуля.

• Применение и поддержка префиксов для объектов базы дан-ных [ObjectQualifier] и [DatabaseOwner].

• Безошибочная инсталляции и деинсталляция модуля на узле DNN.

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

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

• Поддержка фреймворка DNN локализации контента модуля. • Поддержка программных интерфейсов IUpgradeable, IPortable

и ISearchable на уровне кода модуля. • Поддержка модулем стандартных CSS-стилей (Head, SubHead,

Normal, NormalRed и т.д.), которые являются ключевыми для рабо-ты модуля с различными вложенными шаблонами портала.

• Модуль должен содержать конечное пользовательское лицен-зионное соглашение.

Контрольные вопросы к главе 2

1. Перечислите нововведения, которые появлялись в каждой версии системы управления контентом CMS DNN с момента реализации.

2. Какое программное окружение на уровне сервера необходимо для запуска CMS DNN?

3. Из каких подуровней состоит уровень системы управления контен-том DotNetNuke, что они содержат?

4. Из каких ключевых моделей выстраивается внутренняя архитекту-ра DNN?

5. В чем заключается принц модели провайдеров в архитектуре DNN?

6. Перечислите компоненты модели провайдера данных DNN. 7. Что представляют собой пользовательские объекты прикладной

логики в архитектуре DNN? 8. Как работает гидратор данных для объектов кода в архитектуре

DNN?

9. Из каких компонентов состоит уровень представления DNN? Объ-ясните последовательность их загрузки в момент запроса страницы веб-представительства.

10. В чем заключается особенность работы слоя доступа данных DNN? Какова роль абстрактного базового класса Data Provider при рабо-те с данными?

11. Как работает система аутентификации и авторизации в многопор-тальной среде DNN?

12. Какими административными правами владеют учетные записи DNN admin и host с позиции управления веб-порталом?

13. Назовите функциональные модули администратора сайта DNN. 14. Из каких разделов и пунктов состоит модуль DNN «Настройки

сайта» (Site Settings)? 15. Какие модули CMS DNN применяются для реализации функцио-

нальностей веб-представительства компании? 16. Опишите функциональную принадлежность модулей интернет-

магазина CMS DNN. 17. Каковы специфические настройки витрины в модуле интернет-

маганизина CMS DNN? 18. Из каких файлов состоит шаблон оформления CMS DNN? Пере-

числите типичные шаги по созданию шаблона оформления. 19. Опишите алгоритм создания веб-страницы в CMS DNN. 20. Какую программную среду необходимо настроить для разработки

модулей под CMS DNN? 21. Как создать проект шаблона модуля CMS DNN для его дальней-

шей разработки в Visual Studio?

154

Заключение

Разработка полноценного веб-представительства компании с возможностями удовлетворения требований пользовательской аудитории интернета и клиентов продуктов данной компании ста-ла многогранной и сложной задачей. Для решения этой задачи необходимо применять научный подход к построению сайтов и других интернет-ресурсов компании, реализовывать данные ре-сурсы на современных, хорошо зарекомендованных, обкатанных временем и перспективных технологических платформах сайто-строения. Более того, с развитием веб-пространства технологиче-ские платформы стали фундаментом для развития систем управ-ления веб-контентом, которые за последние 10–15 лет значитель-но прогрессировали и увеличились в количестве. Системы управ-ления веб-контентом превратились в отдельный сегмент отрасли программного обеспечения в IT-индустрии, которые приобрели большую популярность, так как дают возможность относительно простого запуска сайтов в интернете, их эксплуатации в сочетании с большой функциональностью администрирования и разработки. В данном учебном пособии рассмотрена лучшая CMS для создания веб-представительства компании с открытым исходным кодом, по-строенная в программной экосистеме Microsoft – DNN, до ребрен-динга компании разработчика носившая название DotNetNuke. Среди ASP.Net систем управления контентом она занимает первое место по количеству сайтов, компаний-клиентов почти во всех от-раслях экономики, числу предоставляемых дополнительных моду-лей расширений и разработчиков данных расширений. Это достиг-нуто продуманным подходом к архитектуре построения DNN, кото-рую мы подробно разобрали. Данная архитектура совмещает в себе лучшие практики разработки в ASP.Net и обеспечения безопасно-сти, работу на разных системах управления базами данных, воз-можность создания дизайна сайтов средствами, не связанными с продуктами Microsoft, на обычном HTML. Система DNN обеспечи-вает многопортальность на одной инсталляции базового про-граммного обеспечения, имеет хорошие стандарты, вышедшие из лучших практик по объектно-ориентированному программиро-ванию модулей расширений, хорошо документирована, имеет зна-

155

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

При наличии таких преимуществ DNN постоянно развивается, внедряя механизмы для привлечения все большего числа разра-ботчиков. Например, opensource-версия DNN Platform была перене-сена с веб-ресурса CodePlex на Github, который реализует сотруд-ничество программистов для работы над одним проектом, управ-ление программным кодом и его обзор. В свет выпущена обзорная версия DNN 8 Community Technology Preview (CTP6), в которой реа-лизована возможность разработки модулей расширения на базе паттерна ASP.Net MVC с поддержкой всех новшеств HTML 5. Эти но-вовведения становятся дополнительной опцией к существующей поддержке разработки модулей на основе паттерна ASP.Net Web-Forms (User Cotnrol) и скриптов Razor. С выходом этой новой вер-сии DNN 8 становится единственной Asp.Net CMS, которая предла-гает разработчикам выбор всех доступных способов создания и программирования модулей.

Развивается и сама базовая технология ASP.Net, вышла новая бета-версия ASP.Net 5, созданная разработчиками с нуля. Самое су-щественное новшество данной версии – это кросс-платформенная среда CLR, что вообще не входило в стратегическую линию разви-тия продуктов Microsoft. Эта среда выполнения позволит разраба-тывать и запускать .Net-приложения на Mac- и Linux-устройствах. Но также новая версия обеспечивает полную среду выполнения (Full .Net CLR) и основную, ядровую CLR (Core CLR), оптимизиро-ванную для облачных сервисов.

Поскольку ASP.Net является базовой платформой для DNN, можно предположить, что и новые версии CMS будут в той или иной степени отражать преимущества нововведений ASP.Net и наступит момент, когда мы увидим версию CMS DNN с возможно-стями работы на серверах под операционными системами Linux, FreeBSD, Mac OC.

Следует отметить, что учебное пособие в силу ограничений по объему не может охватить всех аспектов работы с DNN для созда-ния веб-представительства компании. Важно разобрать такие те-мы, как работа с AJAX в DNN, так как при работе с данной техноло-гией есть свои правила и своя программная модель; освоить при-менение технологий поддержки JQuery, различных средств аутен-тификации, работу с Silverlight, расширенными средствами созда-

ния шаблонов оформления; подробно изучить программную мо-дель классов API DNN, работу с Razor. В большинстве перечислен-ных выше аспектов информацию можно найти в печатных издани-ях по программированию в DNN, на различных веб-сайтах, форумах. С практической точки зрения стоит рассмотреть возможности вер-сий DNN 7 Professional, Enterprise, EVOQ Content и Engage, а также построение высоконагруженных отказоустойчивых решений на DNN и применение веб-ферм. Все это автор рекомендует для дальнейшего изучения инструментальных средств создания веб-представительств компаний.

157

Библиографический список 1. Выбор системы управления контентом интернет-ресурса

// Проект «ИТ-безопасность». 2016 г. URL: http://itzashita.ru/nasha-veb-masterskaya/vybor-sistemy-upravleniya-kontentom.html (дата об-ращения: 06.08.2014).

2. Вышла официальная версия Composite C1 5.2 // Orckestra CMS / Composite C1 по-русски. URL: http://compositec1.blogspot.ru/ 2016/09/composite-c1-cms-v5.2-released.html (дата обращения: 15.09.2016).

3. Интернет-рынок РФ вырастет в 2013 г. на четверть, до 1,05 млрд руб // Союз издалетей «ГИПП». URL: http://www.гипп.рф/ opennews.php?id=47225&type=0 (дата обращения: 20.02.2013).

4. Интернет и подростки. Безопасность детей в интернете // Интернет в России и мире. URL: http://www.bizhit.ru/index/ internet_i_podrostki/0-342 (дата обращения: 10.16.2016).

5. Кобелев О.А. Электронная коммерция: учеб. пособие. М.: Дашков и К°, 2006. 684 c.

6. Котляров И.Д. Веб-представительство компании: Сущность и методы создания // Информационные ресурсы России. 2012. № 3. С. 24–27.

7. Кириченко А.А. Разработка электронного портала. (Созда-ние WEB-представительства. Контент-инжениринг): учеб. пособие. М.: Московский государственный университет экономики, стати-стики и информатики, 2005. 106 с.

8. Магдануров Г.И., Юнев В.А. ASP.Net MVC Framework. СПб.: БХВ-Петербург, 2010. 320 c.

9. Российская интернет-экономика в 2013 году выросла на 25 процентов // Сетевое издание «Городской информационный канал». М., 2012–2016. URL: http://www.m24.ru/articles/27401 (дата обращения: 18.02.2013).

10. Рунет превращается в локомотив экономики – растет по 40% в год // Электронное периодическое издание «MK.ru». URL:

158

http://www.mk.ru/economics/article/2013/10/10/929049-runet-prevraschaetsya-v-lokomotiv-ekonomiki-rastet-po-40-v-god.html (дата обращения: 20.06.2014).

11. Рейтинг CMS // CMS Magazine аналитический портал рынка веб-разработок. URL: http://ratings.cmsmagazine.ru/cms_analytics (дата обращения: 12.12.2013).

12. Что двигает рынок eCommerce: тенденции и цифры // Ин-тернет-продажи 2.0. Электронная коммерция в России. URL: http://www.internetsales.ru/chto-dvigaet-rynok-ecommerce-tendentsii-i-tsifry (дата обращения: 19.06.2014).

13. Экспозито Д. Microsoft ASP.Net 2.0 Базовый курс. Мастер-класс. М: Русская редакция; СПб.: Питер, 2007. 688 c.

14. Экспозито Д. Программирование с использованием Mi-crosoft ASP.Net 4. СПб.: Питер, 2013. 808 с.

15. A CMS Equally Loved by Marketing and IT // DNN Corp.(DotNetNuke). Copyright 2016 by DNN Corp. URL: http:// www.dnnsoftware.com (дата обращения: 03.03.2013).

16. Award winning CMS built for the Cloud // Orckestra CMS and Cloud. URL: https://cms.orckestra.com (дата обращения: 25.06.2014).

17. Cross patform, open source.Net framework // Mono Project. Legal Notices. URL: http://www.mono-project.com (дата обращения: 05.08.2014).

18. Company // Kentico. URL: http://www.kentico.com/Company (дата обращения: 16.05.2014).

19. DotNetNuke Oracle Data Provider // SourceForge. Copyright 2016 Slashdot Media. URL: http://dnnodp.sourceforge.net (дата обра-щения: 14.05.2014).

20. DNN SMS Platform 07.01.02 // CodePlex Project Hosting for Open Source Software. URL: http://dotnetnuke.codeplex.com/releases/ view/112531 (дата обращения: 16.05.2014).

21. DNN Costumers are Leading Brands from Around the Globe // DNN Corp.(DotNetNuke). URL: http://www.dnnsoftware.com/About/ Customers (дата обращения: 20.08.2014).

22. DNN Azure Accelerator // CodePlex Project Hosting for Open Source Software. URL: http://dnnazureaccelerator.codeplex.com (дата обращения: 16.05.2014).

23. DNN Platform 7.3 Administrator Manual. DNN Platform 7.3 SuperUser Manual // DNN Corp.(DotNetNuke). URL: http://www. dnnsoftware.com/ community/download/manuals (дата обращения: 05.05.2016).

24. Darren Neese. DotNetNuke Skinning Tutorial. OltonBirming-ham.: Packt Publishing, 2008. 156 р.

25. How to install DotNetNuke with MySQL // ASP Free is a Developer Shed Property. URL: http://www.aspfree. com/c/a/Database/ How-To-Install-DotNetNuke-with-MySQL (дата обращения: 14.05.2014).

26. Marketplace // KenticoDevnet. URL: http://devnet.kentico.com/ Marketplace.aspx (дата обращения: 16.05.2014).

27. Mitchel Sellers. Professional DotNetNuke Module Programming. Indianapolis: Wiley Publishing, Inc. 2009. 340 р.

28. Shaun Walker, Brian Scarbeau, Darrell Hardy. Professional Dot-NetNuke 5 Open Source Web Application Framework for Asp.NET. Indi-anapolis: Wiley Publishing, Inc., 2009. 603 р.

29. Umbraco and Mono: Can it be done? // Kevin M. Fitzgerald. Written on 07/07/2009. URL: http://kevinfitzgerald.net/articles/ umbraco-and-mono.htm (дата обращения: 17.05.2014).

Учебное издание

Игнатов Юрий Юрьевич

ПРОЕКТИРОВАНИЕ И РАЗРАБОТКА ВЕБ-ПРЕДСТАВИТЕЛЬСТВА ФИРМЫ

Учебное пособие для студентов, обучающихся по направлениям подготовки

38.03.05 Бизнес-информатика, 09.03.03 Прикладная информатика,

01.03.02 Прикладная математика и информатика

Редактор Л.В. Реброва Верстка А.А. Угланов

Подписано в печать 25.05.2017 г. Формат 60×84 1/16. Уч.-изд. л. 8,5. Усл. печ. л. 9,3.

Тираж 100 экз. Заказ 92.

ССЭИ РЭУ им. Г.В. Плеханова. 410003, г. Саратов, ул. Радищева, 89.