整个网站部分作为 DotNetNuke 模块

发布于 2024-11-18 09:17:03 字数 665 浏览 2 评论 0原文

我需要将网站的整个部分(大约 10 个不同的页面)开发为 DotNetNuke 模块。该网站将使用 DNN 作为 CMS,编辑人员将在其中管理网站大部分内容的 HTML 内容(我将开发的部分除外)。

我已经对 DNN 模块开发进行了相当广泛的研究(甚至观看了 DNN Corp 的一些录制的网络研讨会)。不幸的是,我在网上能找到的大部分内容都是关于开发简单的、类似小部件的模块。此外,大部分内容都使用分步“如何使用 Visual Studio 来完成 x”的方法,而我则试图了解 DNN 的工作原理。所以看来我必须自己弄清楚......

此时我已经对 DNN 有了一定的熟悉,并且我看到了针对我的问题的几种不同的解决方案:

  1. 为我的自定义部分上的每个页面创建一个模块。我不太喜欢这个想法,特别是因为我有需要跨多个页面共享的代码。
  2. 开发一个内部包含多个用户控件(每个页面一个)的单个模块,并使用自定义模块设置让每个页面知道要显示哪个控件。
  3. 开发一个可用作库的“假”模块,并为每个页面添加附加模块。
  4. 开发库模块,然后将 Razor 主机模块和 Razor 脚本用于视图(我不需要/想要在我的应用程序上使用 WebForms)。

所以我决定向大家征求意见。哪条路是首选?也许以上都不是?我知道上面的所有四个选项应该给我我想要的结果,但我也不想太多地违背“DNN 方式”......

I need to develop a whole section of a website (around 10 different pages) as a DotNetNuke module. The site will be using DNN as the CMS, where editors will manage HTML content for most of the website (exception that section I'll be developing).

I've already made a rather extensive research on DNN Module Development (even watched some recorded Webinars by DNN Corp). Unfortunately, most of what I could find online is about developing simple, widget-like modules. Also, most of it uses a step-by-step "how to use visual studio to acomplish x" approach, while I was trying to understand how DNN works. So it seems I have to figure it out for myself...

At this point I'm already somewhat familiar with DNN, and I see several different solutions to my problem:

  1. Creating a module for every page on my custom section. I don't like this idea very much, specially because I have code that need to be shared across multiple pages.
  2. Developing a single module with several User Controls inside (one for each page), and use custom module settings to let each page know which control to display.
  3. Develop a "bogus" module that will work as a library, and additional modules for each page.
  4. Develop the library module, then use the Razor Host Module and Razor scripts for the views (I don't need/want WebForms on my app).

So I decided to ask you guys for advice. Which is the the preferred way to go? Maybe none of the above? I know all four options above should give me the result I want, but I also don't want to go against the "DNN way" too much...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

梦回旧景 2024-11-25 09:17:03

我根本不推荐#1(多个模块)或#3(也是多个模块),尽管#2(带有决定视图的模块级别设置的单个模块)绝对是 DNN 模块开发人员广泛使用的可靠选项,听起来你更喜欢#4(Razor)而不是#2,因为你喜欢它的开发风格。

因此,我建议采用 Razor 方法,尽管您似乎很好地理解了该方法,但我想为后代详细说明:

  • 所有可重用业务逻辑
  • 构建一个库(程序集/DLL)来封装 使用该逻辑并在页面上呈现数据的每个页面的 Razor 视图
  • 将 Razor Host 模块放在您需要的每个页面上,并将其指向正确的视图,

这应该会很好地工作。

I wouldn't recommend #1 (multiple modules) or #3 (also multiple modules) at all, and though #2 (single module w/ module level setting that determines view) is definitely a solid option used widely by DNN module developers, it sounds like you'd prefer #4 (Razor) over #2 because you like the development style.

So - I'd recommend going with the Razor approach, which though it seems like you understand the approach just fine, I wanted to elaborate on for posterity:

  • Build a library (assembly/DLL) to encapsulate all of your reusable business logic
  • Build out Razor views for each page that make use of that logic and render your data on the page
  • Drop the Razor Host module on each page that you need it and point it to the correct view

That should work out quite well.

失与倦" 2024-11-25 09:17:03

我假设您正在考虑以“网站项目”风格开发您的软件。我建议您查看“Web 应用程序项目”的处理方式。

如果您在库中有共享功能,请随意构建一个程序集并将其放入 bin 文件夹中,从那里,DNN 将拾取它并在 http 上下文中运行,这太棒了!

在一个项目中构建模块,并将不同的模块打包到 DNN 清单中。

希望我说的不是你所理解的。


添加了另一个答案,它本身就是一个帖子。

I'm assuming you're looking at developing your software in the "Web Site Project" style. I'll like to recommend that you look at the "Web Application Project" style of doing things.

If you have shared functionality in a library, feel free to build an assembly and drop it in the bin folder, from there, it will be picked up by DNN and it will run in the http context, which is great!

Build your module in one project and package the different modules in your DNN manifest.

Hope i'm not talking about what you understand.


Added another answer, it's a post in itself.

陌伤浅笑 2024-11-25 09:17:03

模块——这是一个我们大家都很少使用的术语。

更清晰的定义

  • 包 = Zip 文件(不是模块)
  • 清单 = .DNN 文件

清单允许您将模块(视图/编辑/设置组)用户控件定义为单个安装包。

在 DNN 3.0 清单中,如果您仍然采用这种格式,您会注意到基本的单个安装包的结构如下(简要地)

<dotnetnuke version="3.0" type="Module">
  <folders>
    <folder>
      <name>Side bar Navigation</name>
      <modules>
        <module>
          <friendlyname></friendlyname>
          <cachetime>0</cachetime>
          <controls>
            <control>
              <title>View</title>
              <src>DesktopModules/Module/View.ascx</src>
              <type>View</type>
            </control>
            <control>
              <key>Settings</key>
              <title>Settings</title>
              <src>DesktopModules/Module/Settings.ascx</src>
              <type>Edit</type>
            </control>
          </controls>
        </module>
      </modules>
      <files>
          ...
      </files>
    </folder>
</folders>
</dotnetnuke>

因此上面定义了安装包中的单个模块。

在博客的上下文中,您将有 2 个模块

  1. 博客显示模块(显示选定的博客或仅显示整个博客)
  2. 侧边栏导航模块(帮助您
    快速显示您的博客

您可以做的是将清单中的博客显示模块打包在 的副本中,然后将侧边栏导航模块打包在另一个副本 结构的副本。

例如,这个项目有7个模块;侧边栏导航,自定义搜索模块,blah blah blah

<dotnetnuke version="3.0" type="Module">
  <folders>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
  </folders>
</dotnetnuke>
  1. 1 个安装包(这意味着 1 个 Web 应用程序项目)
  2. 7 个模块
  3. 一个程序集放置在 bin 中/
  4. 所有代码都是共享的,然后您可以从其他库引用继承进一步发展。

它们有不同的视图、名称、友好名称,但都共享一个共同的<文件夹名称>

关键在包装中。

Modules - That's a term that's very loosely used by all of us.

Clearer Definitions

  • Package = Zip file (Not Module)
  • Manifest = .DNN file

The manifest allows you to define Modules(group of View/Edit/Settings) user controls as a single installation package.

In the DNN 3.0 manifest, if you're still in this format, you'll notice that a basic single installation package is structured like this (briefly)

<dotnetnuke version="3.0" type="Module">
  <folders>
    <folder>
      <name>Side bar Navigation</name>
      <modules>
        <module>
          <friendlyname></friendlyname>
          <cachetime>0</cachetime>
          <controls>
            <control>
              <title>View</title>
              <src>DesktopModules/Module/View.ascx</src>
              <type>View</type>
            </control>
            <control>
              <key>Settings</key>
              <title>Settings</title>
              <src>DesktopModules/Module/Settings.ascx</src>
              <type>Edit</type>
            </control>
          </controls>
        </module>
      </modules>
      <files>
          ...
      </files>
    </folder>
</folders>
</dotnetnuke>

So that above defines a Single Module in an Installation Package.

In the context of a blog, you would have 2 modules

  1. Blog Display Module (displays a selected blog or just the whole lot)
  2. Sidebar Navigation Module (Helps you
    to display quickly the blogs you've
    written for an any period of time)

What you can do is to package the Blog Display Module in the manifest in a copy of <folder></folder> and then the Sidebar Navigation Module in another copy of the <folder></folder> structure.

For example, this project has 7 modules; Side bar navigation, custom search module, blah blah blah

<dotnetnuke version="3.0" type="Module">
  <folders>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
    <folder>...</folder>
  </folders>
</dotnetnuke>
  1. 1 Installation Package (Which means 1 Web App Project)
  2. 7 Modules
  3. One assembly to place in the bin/
  4. All code is shared and you can then inherit from other library references to develop further.

They have different views, names, friendlynames but all share one common <foldername>

The KEY is in the Packaging.

野却迷人 2024-11-25 09:17:03
   <folder>
      <name>BlogDisplay</name>
      <friendlyname>Blog Display</friendlyname>
      <foldername>WebLog</foldername>
      <modulename></modulename>'

   '<folder>
      <name>BlogSidebar</name>
      <friendlyname>Sidebar Navigator</friendlyname>
      <foldername>WebLog</foldername>
      <modulename></modulename>

它会看起来像这样!这就是文件夹名称所在的位置。它定义了您的模块将安装到 DesktopModules 中的位置。

在DNN 5书中,仍然使用Web Site Project的开发方式,但是当你参与核心模块的开发时,你会发现项目是Web App Project的开发方式,这是更好的,因为所有的您的代码隐藏在程序集中,并且不作为源代码公开在网络上。

你绝对走在正确的道路上。

   <folder>
      <name>BlogDisplay</name>
      <friendlyname>Blog Display</friendlyname>
      <foldername>WebLog</foldername>
      <modulename></modulename>'

   '<folder>
      <name>BlogSidebar</name>
      <friendlyname>Sidebar Navigator</friendlyname>
      <foldername>WebLog</foldername>
      <modulename></modulename>

It'll look something like this! that's where foldername is. It defines where in DesktopModules your module will be installed to.

In DNN 5 books, the Web Site Project method of development is still in use but when you're participating in development on the Core Modules, you'll find that the projects are in Web App Project development style, which is better, because all your code-behind is in an assembly and not exposed as source code on the web.

You're definitely on the right path.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文