Сообщество русскоговорящих пользователей
CMS DotNetNuke


Создание модуля

Создание нового модуля в DotNetNuke

автор: codexomega

создано: 25/07/2009

последнее обновление: 14/08/2009

редактировал: codexomega

 

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

В данной статье, мы рассмотрим создание нового модуля для CMS(Content Management System) DotNetNuke.

 

Перед тем как начать

Убедимся в том , что у нас есть все необходимые инструменты.

Список того, что нам нужно:

 

  • Visual Studio
  • DotNetNuke StarterKit
  • SQLServer
  • Notepad++


 

 

Шаг 1 - Создание проекта

Важно уяснить для себя, что если у нас уже есть готовый сайт, мы не будем открывать его в Visual Studio, дабы ничего не сломать и не испортить.

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

 

1.    Отркываем Visual Studio. File->New->Project
2.    Выбираем язык программирования – C#/VB
3.    Web->DotNetNuke Compiled Module

 

Проект создан. Теперь надо его настроить под наш сайт. В SolutionExplorer, кликнуть правой кнокой мыши по проекту, выбрать свойства проекта. Заполнить по собственному усмотрению поля: Assembly name и Target Framework.

 

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

 

Default namespace: Название нашего модуля.

 

Шаг 2 - Работа с проектом

Новый проект создался с уже готовыми контролями - файлами с расширением [ascx] в корневой папке, и классами в папке Components.

 

Мы не будем пока трогать контроли, и начнем с настройки классов.

 

Классы модуля

 

·         DataProvider: абстрактный класс или интерфейс. Начать нужно именно с него. Здесь содержаться определения методов используемых в управлении модулем.

 

·         SqlDataProvider: сами методы управления модулем с полным кодом.

 

 

·         VideoLinkerController: класс посредник (оператор), через который будет происходить обращение страниц сайта к методам управления модуля.

 

·         VideoLinkerInfo: сам объект отождествляющийся с главным элементом модуля. Содержит конструктор и свойства.

 

 

Наглядный пример:

 

Мы строим модуль для управления статьями. Нашим главным объектом является СТАТЬЯ. Свойства статьи: заголовок, содержание, автор, дата создания, тема.

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

 

 

После того как отредактировали все 4 класса, переходим к базе данных.

 

 

Создание скрипта SQL

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

Всё это надо создать, потом сгенерировать скрипт SQL, для создания этих вещей автоматически, при установке модуля.

 

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

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

 

 

Когда всё будет готово, SQLServer сам вам создаст скрипт любого объекта. Кликните правой кнопкой мыши по объекту, затем выберите Script as ,  и готово.

 

Заметьте, что в корневой папке модуля, создано 2 файла для скриптов SQL:

 

  • 01.00.00.SqlDataProvider: создание модуля

 

  • Uninstall.SqlDataProvider: избавление от модуля

 

 

Надо начать с файла: 01.00.00.SqlDataProvider.

 

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

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

 

SQLServer создаст скрипты по такому шаблону:

 

IF  EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[COMS_CodexStar_VideoLinker_CreateVideoLink]') AND type in (N'P', N'PC'))

DROP PROCEDURE [dbo].[COMS_CodexStar_VideoLinker_CreateVideoLink]

 

 

Замените их на такой:

 

 

if exists (select * from dbo.sysobjects where id =

          object_id(N’{databaseOwner}

          [{objectQualifier}CodexStar_VideoLinker_CreateVideoLink]’)

          and OBJECTPROPERTY(id, N’IsProcedure’) = 1)

     drop procedure

       {databaseOwner}

       [{objectQualifier}CodexStar_VideoLinker_CreateVideoLink]

GO

 


В примере выше, используется префикс для объектов: COMS.

Вам надо заменить префиксы и [dbo] на параметры в фигурных скобках. Они будут заменены при установке модуля, на нужные.

 

 

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

 

Всё это воткните в тот-же файл - 01.00.00.SqlDataProvider.

 

Следующий шаг намного легче.

Скопируйте все срипты удаления из файла 01.00.00.SqlDataProvider, и наклейте их в файл Uninstall.SqlDataProvider.

 

 

Переходим дальше.

 

Контроли

 

Контролями, называются файлы с раширением [ascx]. Это наши основные страницы модуля с графическим интерфейсом(GUID).

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


Рессурсы

 

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

 

  • Label
  • TextBox
  • DropDownList
  • Итд

 

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

 

Что произойдет, если текст который мы вставили в Label, - на русском языке, но кто-то из другой страны скачал и установил наш модуль, скажем на английском сайте?

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

 

При создании проекта, в корневой папке, была создана папка под названием: App_LocalResources. В ней находятся файлы с расширением: [ascx.resx] , с названиями соответствующими контролям модуля [ascx].

 


Пример.

 

В модуле есть страница, - анкета для введения данных.

Для простоты понимания, приведем следующий код.

 

<dnn:Label ID="lblVideoTitle" runat="server" />

<asp:TextBox ID="txtVideoTitle" runat="server" />

<asp:LinkButton ID="cmdCreate" OnClick="cmdCreate_Click"            runat="server" resourcekey="cmdCreate.Text" />

 

Мы имеем три элемента:

 

  • Label: описание поля для ввода/отображения данных

 

  • TextBox: поле для ввода/отображения данных

 

  • LinkButton: кнопа для записи данных.

 

Если вы посмотрите на код приведенный выше, то заметите что у кнопки и лэйбла чего-то не хватает. Правильно, свойства [Text].

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

Весь статический текст мы помещаем в рессурсный файл нашего контроля, вот таким образом:

 

В колонке Name, - [controlID].[controlProperty].

 

В колонке Value, - Статический текст.

 

Контроли DNN  и классический ASP.NET.

В чем различие?

 

В примере выше, лэйбл lblVideoTitle - это лэйбл DNN,  а кнопка cmdCreate - контроль ASP.NET.

В обоих случаях отсутствует свойство - TEXT.

Но у кнопки есть свойство - resourcekey - [ID].[Property].

Дело в том, что контроли DNN приучены самостоятельно находить свойство TEXT присущее им в файле ascx.resx, тогда как контроли ASP.NET этого делать не умеют. Поэтому надо им подсказать как называется их свойство, и где его искать.

Ничего страшного не произойдет, если вы прикрутите resourcekey к контролю типа DNN. Это ему не помешает.

Так что возьмите на заметку, всегда прикручивать resourcekey, особенно в случае с контрольями ASP.NET.

Какие контроли вы используете?

Если на ваших страницах вы используете стандартные контроли asp, то можете пропустить этот параграф и идти дальше.

Если же не смогли удержаться от нюковских контролей, таких как <dnn:Label /> или <dnn:TextEditor />,  ну и вызываете их где-нибудь в коде, например: txtNukeTextEditor.Text = "елки палки!", то ваш модуль просто не скомпилируется, и выдаст ошибку о том, что не понимает что это за контроль такой.

Что делать в этом случае? Запомните, что модуль должен быть скомпилирован прежде чем мы перенесем его файл DLL в папку BIN нашего тестового сайта.

 

Итак, мы находимся в проекте нашего модуля, который открыт в VisualStudio.  Правой кнопкой мыши, кликаем по проекту и заходим в его свойства > WEB.

 

 

 

Выберите Use IIS Web Server, и поставьте галочку в override application root url.

В Project Url, пропишите путь к папке DesktopModules, в которой должен храниться модуль, на тестовом сайте.

А Root Url - это корнавая папка тест-сайта.

 

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

 

 

Заметка: после того как вытащите DLL, и вставите его в BIN сайта, зайдите в IIS, и удалите виртуальную папку DesktopModules, в корневой папке сайта.

 

 

 

Manifest

Наряду с остальными файлами, в корневой папке нашего проекта был создан файл(Манифест), с расширением [dnn].

 

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

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

 

Внимание!

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

 

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

 

<component type="File">

          <files>

            <basePath>bin</basePath>

           <file>

              <name>Google.GData.Client.dll</name>

            </file>

            <file>

              <name>Google.GData.Extensions.dll</name>

            </file>

            <file>

              <name>Google.GData.Health.dll</name>

            </file>

            <file>

              <name>Google.GData.Spreadsheets.dll</name>

            </file>

          </files>

        </component>

 

 

Сборка готового модуля

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

Совет.

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

 

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

 

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

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

 

 

Заходим на сайт под именем администратора системы.

 

Далее, идем сюда: host/module definitions

 

 

Жмем на:

 

Import Module Definitions

 

Помните Манифест, который мы создавали раннее?

 

 

Выбираем его в списке Manifest, и кликаем на Import Manifest.

 


Если всё прошло успешно, то увидите сообщение с подтверждением.

 

Возвращаемся на страницу : host/module definitions.

 

Теперь, на ряду с другими модулями в списке, можно полюбоваться на свой модуль. Но это еще не всё.

Осталась база данных. Помните огромный скрипт с созданием таблиц, процедур и прочего? Теперь он нам пригодится.

 

 

Переходим сюда: host/SQL

 

Выбираем наш файл со скриптом, и чтобы загрузить его, кликаем на Load. Затем, что очень важно: поставить галочку на Run as Script.

 

Жмем на Execute.

 

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

Поэтому ошибку в скрипте можно поправить, подредактировав файл со скриптом, после чего повторить этап с запуском скрипта SQL.

 

Совет для исправления скрипта

Создайте резервную копию скрипта SQL и отложите его в сторону.

Теперь возьмите рабочий скрипт, который будете запускать и сотрите всё кроме первой части - удаление объектов.

Запустите скрипт на сайте. Если ошибок нет, добавьте в рабочий скрипт часть создание таблиц из резервной копии.

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

 

 

 Упаковка

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

 

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

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

Скомпилируйте проект с модулем. Теперь возьмите обновленный DLL из папки BIN, и скиньте в папку BIN тестового сайта.

Скомпилируйте тестовый сайт, проверьте работу модуля еще раз.

 

 

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

 

Подключаемся с сайту где установлен наш модуль. Идем сюда:

 

Host > Module Definitions

 

В списке модулей, выбираем наш модуль. Заходим в его свойства, нажав на EDIT.

Проверяем и дополняем, если нужно, информацию о модуле которая высвечивается.

Внизу на странице, есть кнопка Create Package. Жмем на нее.

Вам предложат на следующем  этапе использовать существующий манифест, или пересмотреть его. Если у вас с манифестом всё в порядке, и он не нуждается в исправлении, то выбирайте существующий (existing) и кликайте NEXT.

 

Далее, переименуйте архив готового модуля, если вам не нравится то, что вам предлагается и жмите NEXT.

Всё. Пакет готов. Зайдите в корневую папку сайта, и найдите ZIP в папке Install\Module.

Этот пакет можно теперь испол ьзовать для автоматической установки модуля стандартными средствами DNN, прямо на сайте.

 

 Послесловие, или задолбали эти ошибки!

Вернемся в прошлое - этап тестирования модуля, перед упаковкой.

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

Страница обновляется... Абвгд... ёклмн.

 

Error: VideoLinker is currently unavailable.

DotNetNuke.Services.Exceptions.ModuleLoadException: Could not load type 'CodexStar.Modules.VideoLinker.ViewVideoLinker'....

Красиво, не правда ли?

 

Что делать в таком случае?

 

Открываем проект тестового сайта в Visual Studio, и компилируем, затем смотрим на ошибки.

 

Если ошибки ваши, например опечатка или ошибка в коде, то вас можно поздравить, исправьте, перекомпилируйте и все дела.

 

А что если всё исправно, но вы не понимаете смысл ошибки, например столкнулись с этим:

 

Error    1    Could not load type 'CodexStar.Modules.VideoLinker.ManageAttributes'.    C:\Server\TestSite\DotNetNuke\Website\DesktopModules\VideoLinker\ManageAttributes.ascx    1 

 

Загляните в Solution Explorer, вероятно, у вас еще и файлы дизайнера оторвались от контролей (XYZ.ascx.designer.cs)?

Да, не повезло...

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

Дальше, открываем контроль (ascx) и смотрим на его заголовок.

К каждому контролю прикреплен класс (ascx.cs/vb), взависимости от языка, на котором написан модуль.

Проблема может быть в том, что контроль просто не может найти свой класс.

 

Заголовок контроля такой:

 

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="ManageAttributes.ascx.cs"
    Inherits="CodexStar.Modules.VideoLinker.ManageAttributes" %>


Видите CodeBehind?

Замените его на CodeFile.

Контроль прозреет.

 

 

Компилируем проект снова.

Что за ....

 

Error    29    The type or namespace name 'VideoLinkerController' could not be found (are you missing a using directive or an assembly reference?)    C:\Server\TestSite\DotNetNuke\Website\DesktopModules\VideoLinker\VideoDetail.ascx.cs    35   

 

Это говорит о том что класс контроля тоже ослеп, и не видит классы управления модулем.

Что делать в этом случае?

Помните проект, не сайт, а пустой проект в котором мы создавали наш модуль?

Откройте его в Visual Studio, скомпилируйте, и закройте.

Теперь откройте Windows Explorer, зайдите в папку BIN только что скомпилированного проекта, и вытащите оттуда файл DLL с названием вашего модуля.

Этот DLL вставьте в папку BIN вашего тест-сайта. В Visual Studio, кликните правой кнопкой мыши по проекту сайта, и нажмите - Add reference.

Выберите DLL из папки BIN.

Перекомпилируйте сайт.

Теперь всё должно работать.

 

 

 

 

 

 

 

 

 

 
OpenedBorderBoxed Small width layoutMedium width layoutMaximum width layout Small textMedium textMaximum text