1

Я видел много сообщений (например, см. https://stackoverflow.com/a/7363860/1378356), в которых указано, что пользовательские элементы управления ASP.NET (.ascx) не предназначены для использования в разных проектах/сборках. Скорее, правильным способом было бы создать сервер/пользовательский элемент управления.Как настроить библиотеку элементов управления для сайта DNN

Вопрос в том, как он был предназначен для создания модуля DNN? Модули DNN обычно имеют файл .ascx, который наследует от DotNetNuke.Entities.Modules.PortalModuleBase, который в конечном итоге наследуется от System.Web.UI.UserControl.

Это правильный способ создания модуля DNN, и если это так, я буду испытывать боли на этом пути?

ответ

0

Если вы начинаете с шаблонов модулей, созданных Крисом Хаммондом (Christoc.com), вы будете почти свободны от боли.

+0

Эти шаблоны могут сделать трюк, но можете ли вы уточнить: действительно ли DNN нарушает стандарт отсутствия ascx в другом проекте, и если да, то почему, или нет? – as9876

1

Если вы следуете «букве закона», которая изложена в связанном сообщении, это правильно. Однако в случае модуля DNN созданные вами элементы управления, ваши файлы .ascx потребляются вашим кодом и просто загружаются DNN.

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

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

(Хорошим примером того, что они говорят о сложности обновления, является элемент управления DNN TextEditor. Учитывая относительную ссылку на корневой каталог «~/Controls/TextEditor.ascx», вы должны обмануть VS, чтобы узнать, что подходящий тип для управления.)

Но все-таки, для решения на основе DNN да. .ascx - приемлемая практика.