hgs yükleme
escort kars escort kibris
My Cart (0)  |  My Orders  |  My Downloads  |  My Auction  |  My Account  |  Help

Login |Register        Search

DNN 8 Module Development 1 - Introduction to MVC modules

                Print      Add To Favorite     Add To Watch List     Contact Author

Creator: host   6/7/2016 4:01:17 AM    Author: Charles Nurse   Source: http://www.dnnsoftware.com/community-blog/cid/155216/module-development-in-dnn-8-1-introduction-to-mvc-modules   Views: 2251    0    0  
Module develop DNN 8 Mvc

A new CTP for DNN 8 was released today.  This CTP contains updated support for building modules using the ASP.NET MVC Framework as well as new support for building HTML 5 based modules.  This adds to the existing support for building modules with ASP.NET WebForms (User Controls) and Razor scripts. 

With this extended support DNN 8 becomes the only .NET CMS that offers module developers a choice of all the available ways to build extensions.

In this new blog series I will describe these new features while building a module to manage Contacts.  This post is an introduction to developing MVC based modules.

A bit about routing

The first thing to note is that the approach we have taken is to embed the MVC application inside an ASP.NET Web Forms server control.  This is a similar approach to how we provided Razor support a few years ago, and is also the same approach we are using to support Single Page Application style modules using HTML 5, JavaScript and CSS. 

This doesn’t really affect how module developers code their MVC modules, except that it means that routing is done a little differently.  As an MVC module developer you don’t need to define any routes as DNN handles the routing (or URL Rewriting).  We will however still support Html and Url helpers that defined links using action names and controller names.  However, we will create urls that work within the DNN Url handling system.

Setting up your environment

In this introductory blog I will show how to set up Visual Studio (2015) to develop our first DNN MVC module.  As a pre-requisite you will need to install the CTP which you can get from codeplex. Alternatively you can get the latest code by cloning the feature/8.0.0 branch of the DNN.Platform Github repository (https://github.com/dnnsoftware/Dnn.Platform).

Open Visual Studio (in my case I am using Visual Studio 2015 RC) and create a solution for you MVC module.  Once you have created your solution, add a Web Application Project – select the Empty template (1) but check MVC (2) so that the MVC references are added to the empty project.

Figure 1 - Creating an MVC Project

Remove the files and folders added by the template – except the Controllers, Models and Views folders – and add an App_LocalResources folder (for our localization resources).  You should have something that looks like Figure 2.

Figure 2 – Empty MVC Project

I like setting up my projects so that I can deploy them to my site as well as package them for installation so in order to do that we need to add some extra files to the project.

The Module.build File

The first file to add is an MS Build file.  This MS Build file is shown in Figure 3 (don’t worry if you can’t read everything in the file – as noted above the source for this project is available on Github (https://github.com/cnurse/DnnConnect.Demo), so you can copy the file on Github for use in your project.

Figure 3 – The Module.build File

There are four important properties in this file some of which will need to be modified for your installation:

  1. The BuildScriptsPath points to the folder where supporting build scripts are stored.
  2. The WebsitePath must point to the root of your DNN 8.0 website
  3. The ModuleFolderName points to where your module will be deployed within the website – your module should be under the MVC folder within DesktopModules.  This is important as this will mean that the web.config file that lives in that folder will apply to your MVC module.  This web.config file allows the Razor Views to work just as they would in a stand-alone MVC Application with the change that the base WebViewPage is a DnnWebViewPage.
  4. The two Imports statements points to two MS Build files that are used to deply and/or package the module.  These files are copies of the files shipped with the DNN source and are located in the BuildScriptsPath folder.

To enable the build file to work you need to modify the module’s project file.  To do that, “Unload” the project and Edit the project as an XML file, and insert the Import element highlighted in Figure 4 at the bottom of the file.

Figure 4 – Adding the Import Statement to the Project File

The DNN Manifest file

Next we will need to add a DNN manifest file.  Figure 5 shows the DNN manifest file I have created for the ContactList project.

Figure 5– The DNN Manifest file

Note the following 4 points about this file:

  • There is a dependency node as MVC modules require a core DNN version of 8.0.0 or later
  • The folderName property supports two levels just like legacy module types (for this property the MVC folder is implied)
  • The controlSrc property uses the “fake” extension “.mvc” to identify that this control is an MVC control.  I will go into more detail about this in a future post.
  • The ResourceFile component and any File component needs to include the MVC folder in the basePath.

Most of the other files in the root of the project are self-explanatory.  In the next post in this series I will show how to build your first MVC View.

For more information

Rating People: 0   Average Rating:     

     DnnModule.com is built to provide DNN quality modules and DNN skins, some of them are free, some not. We wish these stuffs (free or not ) can be useful to you.

     Besides that, we also provide a full range of professional services, ranging from web site build, seo, system management, administration, support, senior consultancy and security services. We act as if your development project or network was ours, with care and respect. We are not satisfied until it works the way you want it to, and we don't silently ignore found issues as somebody else's problem.