整个网站部分作为 DotNetNuke 模块

Question

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...

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

   <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.