DotNetNuke и индивидуальная разработка - PullRequest
1 голос
/ 07 сентября 2011

Мы рассматриваем возможность покупки DotNetNuke (или Sitefinity) в очень короткие сроки, и у меня есть вопрос, на который у меня не получается найти быстрый ответ.( У меня есть отдельный, но похожий пост с Sitefinity в качестве фокуса, если вы можете ответить на этот вопрос лучше или дополнительно. )

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

Нашей пользовательской разработкой является c # ASPX с Site Master и вложенными страницами Master Site.Этим пользовательским приложениям не принадлежит собственный верхний уровень на нашем веб-сайте, но они являются частью ветви, обычно на один или два уровня ниже (например, http: www.contoso.com/branch/app/default.aspx).

  • Как DotNetNuke обычно настраивается в смешанном режиме CMS / Custom?Например, установлен ли DotNetNuke в верхней части веб-сайта или «там, где это необходимо» внизу веб-сайта.
  • Как это связано при смешивании CMS и пользовательских веб-приложений?
  • Позволяет ли интерфейс CMS добавлять эти пользовательские приложения или вы просто заходите на веб-сервер и добавляете их в структуру?
  • Судя по прочтению других сообщений, мы можем создавать свои собственныепользовательские модули c # и редакторы CMS «вставляют» модули на страницах.Может ли кто-нибудь подтвердить это для меня?

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

Ответы [ 2 ]

4 голосов
/ 08 сентября 2011

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

Можно добавить страницы ASPX в правильном месте в DNN. Обработчик UrlRewrite будет первоначально просматривать все такие запросы, и, предполагая, что существующие страницы и дружественные обработчики URL-адресов не думают, что они «владеют» страницей .aspx, DNN прекратит обработку запроса и передаст его вашей странице. Не существует конкретного способа «зарегистрировать» эти страницы в DNN. Я бы вообще не рекомендовал такой подход, но он работает и может иметь смысл в определенных ситуациях.

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

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

3 голосов
/ 08 сентября 2011

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

<location path="." inheritInChildApplications="false">
    <system.web>
    ...
    </system.web>
</location>

Сохранение наследования между web.config приложения и DNN web.config является хрупким.Изменения в DNN web.config могут привести к сбою приложения в виртуальном каталоге.В дополнение к удалению каждого http-модуля и обработчика, вам нужно как минимум добавить каталоги DNN App_Code в конфигурацию приложения.

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

См. Также

Как отключить наследование web.config для дочерних приложений в подпапках в ASP.NET?

Как остановить наследование web.config

Избегать наследования web.config в дочернем веб-приложении с использованием inheritInChildApplications

...