In an earlier blog I introduced the idea of using ASP.NET MVC to develop DotNetNuke modules, and I walked through how you could create a simple ASP.NET MVC Module Application.  Now that I have demonstrated that it is feasible to use the MVC Framework in a WebForms Application, I will start to dig into how this was done.

But first, before we look at the code, lets review how the standard ASP.NET MVC Pipeline works. This is summarized effectively by Steve Sanderson, on his blog.

Figure 1 – ASP.NET MVC Pipeline

This diagram was based on an early Preview of the ASP.NET MVC Framework, but the basic process has not changed.  There are 4 stages in the standard ASP.NET MVC pipeline; Routing, Instantiate Controller, Locate and Execute Action, Instantiate and Render View.

Routing

In the routing step the Incoming Http Request is mapped to the MvcHandler and the MvcHandler’s ProcessRequest method is called, assuming of course that you have registered the handler in your web.config file (Listing 1).

<add name="MvcHttpHandler" preCondition="integratedMode" verb="*" path="*.mvc" 
type="System.Web.Mvc.MvcHttpHandler, System.Web.Mvc, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=31BF3856AD364E35"/>

Controller Instantiation

The ProcessRequest method (Listing 2) creates a ControllerFactory (line 8), which in term attempts to create a Controller (line 9), using the RouteData  which is part of the RequestContext.  Assuming that the ControllerFactory is able to create a Controller Instance, ProcessRequest will call the Execute method of the Controller (line 19), thus passing control to the Controller.

   1:  protected internal virtual void ProcessRequest(HttpContextBase httpContext) {

   2:      AddVersionHeader(httpContext);

   3:   

   4:      // Get the controller type

   5:      string controllerName = RequestContext.RouteData.GetRequiredString("controller");

   6:   

   7:      // Instantiate the controller and call Execute

   8:      IControllerFactory factory = ControllerBuilder.GetControllerFactory();

   9:      IController controller = factory.CreateController(RequestContext, controllerName);

  10:      if (controller == null) {

  11:          throw new InvalidOperationException(

  12:              String.Format(

  13:                  CultureInfo.CurrentUICulture,

  14:                  MvcResources.ControllerBuilder_FactoryReturnedNull,

  15:                  factory.GetType(),

  16:                  controllerName));

  17:      }

  18:      try {

  19:          controller.Execute(RequestContext);

  20:      }

  21:      finally {

  22:          factory.ReleaseController(controller);

  23:      }

  24:  }

Action Invoker

We have now successfully routed control to the appropriate Controller. 

The Execute method of the ControllerBase class calls the ExecuteCore (Listing 3) method of the Controller class.  This in turn calls the ActionInvoker (line 6), which again uses the RouteData to invoke the specific action on the Controller. 

   1:  protected override void ExecuteCore() {

   2:      TempData.Load(ControllerContext, TempDataProvider);

   3:   

   4:      try {

   5:          string actionName = RouteData.GetRequiredString("action");

   6:          if (!ActionInvoker.InvokeAction(ControllerContext, actionName)) {

   7:              HandleUnknownAction(actionName);

   8:          }

   9:      }

  10:      finally {

  11:          TempData.Save(ControllerContext, TempDataProvider);

  12:      }

  13:  }

An action maps to a method name in the Controller class.

   1:  public class HomeController : Controller

   2:  {

   3:      public ActionResult Index()

   4:      {

   5:          ViewData["Message"] = "Welcome to ASP.NET MVC!";

   6:   

   7:          return View();

   8:      }

   9:   

  10:      public ActionResult About()

  11:      {

  12:          return View();

  13:      }

  14:  }

For example in Listing 4 which shows the HomeController in the default ASP.NET MVC project – the Index and About methods represent the index and about actions of the HomeController. 

You would reach these methods using the routes “/home/index” and “/home/about”, although as the first route represents the default controller “home” and the default action “index”, the null route would also reach the Index method.

Render View

Finally the ActionInvoker gets the returned ActionResult from the action method ands calls its ExecuteResult method.  If the ActionResult is a ViewResult (Listing 5) this in turn will render the View (line 17).

   1:  public override void ExecuteResult(ControllerContext context) {

   2:      if (context == null) {

   3:          throw new ArgumentNullException("context");

   4:      }

   5:      if (String.IsNullOrEmpty(ViewName)) {

   6:          ViewName = context.RouteData.GetRequiredString("action");

   7:      }

   8:   

   9:      ViewEngineResult result = null;

  10:   

  11:      if (View == null) {

  12:          result = FindView(context);

  13:          View = result.View;

  14:      }

  15:   

  16:      ViewContext viewContext = new ViewContext(context, View, ViewData, TempData);

  17:      View.Render(viewContext, context.HttpContext.Response.Output);

  18:   

  19:      if (result != null) {

  20:          result.ViewEngine.ReleaseView(context, View);

  21:      }

  22:  }

Plugging in to the ASP.NET MVC Pipeline

So, given that DotNetNuke is a WebForms Application how do we plug in to this Pipeline with the least possible impact .  What I mean by this is that we don’t want to have to rewrite the MVC Framework in order to get everything to work.  We want to be able to use all of the extensibility points that the Framework enables, with a minimum amount of effort.

In the next part of this series I will describe how we achieve this goal.

Last week, Shaun posted a blog in which he discussed whether DotNetNuke (DNN) should be rewritten in ASP.NET MVC.  This blog created quite a stir, both within the DotNetNuke Community and within the ASP.NET Community as a whole. 

In a comment that I added to Shaun’s post I suggested that the debate should not be over whether DNN should be rewritten in ASP.NET MVC (or any other framework that may come in the future), the discussion should be on “How can we enable developers to use the ASP.NET Technologies of their choice when developing extensions for DNN.”  After all, if we rewrite DNN in MVC we effectively lock out WebForm developers.

Thanks to an idea from my son Andrew (much of what I used in this work was from his Maverick project on codeplex) I have been able the create a Framework that sits on top of DotNetNuke (and System.Web.MVC) and allows modules to be created using the ASP.NET MVC Framework (DotNetNuke.Web.Mvc).

In this article I will review how – using this add-on layer we can go about creating a simple ASP.NET MVC module.  First, add an ASP.NET MVC Application to your Visual Studio solution. (See Figure 1 below)

Figure 1 – Add a new MVC Web Application in the Desktop Modules folder called MVC_Test

Note that the location of the project is in the DesktopModules folder of our test website.  This is exactly the same process we would use to add a WAP (Web Application Project) style module. Figure 2 below shows the Solution Explorer after adding this project.

Figure 2 – The new Project in Solution Explorer

Before we go any further – we should prove to ourselves that this is a valid ASP.NET MVC Web Application, by selecting the Default.aspx file, and selecting View in Browser from the Context menu (see Figure 3 below)

Figure 3 – Browsing to the site demonstrates that this is a valid ASP.NET MVC Application

So now we have an MVC Application, how do we make it run as a Module in our DotNetNuke website?  First we need to add a new class to our project – MVC_TestApplication.cs (see Figure 4).

Figure 4 – Add a new class MVC_TestApplication to the root of the Application

And we need to add references to our DotNetNuke Library project and to the new DotNetNuke.Web.Mvc project (see Figure 5)

Figure 5 – Add references to the DotNetNuke Library and the new DotNetNuke.Web.Mvc project

When we have done that we need to open the new class we added and add some very simple code.

   1:  using System.Web.Routing;

   2:  using DotNetNuke.Web.Mvc;

   3:  using DotNetNuke.Web.Mvc.Routing;

   4:   

   5:  namespace MVC_Test

   6:  {

   7:      public class MVC_TestApplication : MvcModuleApplication 

   8:      {

   9:          protected override string FolderPath 

  10:          {

  11:              get { return "MVC_Test"; }

  12:          }

  13:   

  14:          protected override void Init() 

  15:          {

  16:              base.Init();

  17:              RegisterRoutes(Routes);

  18:          }

  19:   

  20:          private static void RegisterRoutes(RouteCollection routes) 

  21:          {

  22:              routes.RegisterDefaultRoute("MVC_Test.Controllers");

  23:          }

  24:      }

  25:  }

The most important thing to note is that this class inherits from MvcModuleApplication, a new base class in the new DotNetNuke.Web.Mvc project.  The Init method allows us to register any routes that our MVC Module Application will need and the FolderPath property tells the DotNetNuke.Web.Mvc project where our Views are located.  Finally we need to make a very small change to the default View (Listing 2).

   1:  <%@ Page Language="C#" MasterPageFile="../Shared/Site.Master" 
                              Inherits="System.Web.Mvc.ViewPage" %>

   2:   

   3:  <asp:Content ID="indexTitle" ContentPlaceHolderID="TitleContent" runat="server">

   4:      Home Page

   5:  </asp:Content>

   6:   

   7:  <asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">

   8:      <h2><%= Html.Encode(ViewData["Message"]) %></h2>

   9:      <p>

  10:          To learn more about ASP.NET MVC visit <a href=http://asp.net/mvc 

                               title="ASP.NET MVC Website">http://asp.net/mvc</a>.

  11:      </p>

  12:  </asp:Content>

If you blink you won’t see the change. 

The change is to the reference to the MasterPageFile – the value of the attribute is changed from “~/Views/Shared/Site.Master” to “../Views/Shared/Site.Master”.  The reference points to the same file – but the original reference assumes that the Views folder is at the root of the IIS Application – as a module it is actually at ~/DesktopModules/MVC_Test/Views”.  By making the reference relative it will work in both scenarios.

Next we need to create our Module Extension.  This is done in much the same way as we do today, the only difference being that when we register the Module Control we use the Namespace for the new class that we added – MVC_Test.MVC_TestApplication (See Figure 6 below).  Since version 5.0, DNN has allowed module controls to be server controls and ultimately our new MVC_TestApplication class inherits from Control.

Figure 6 – Add the MVC_TestApplication as the Source for the Default Module Control

Finally build our new MVC Module Application and copy the assembly from the bin folder of the project to the bin folder of the Website.

We are now ready to see if everything works.  Add a new Page and add the newly registered Module to the Page and “hey presto” we get a Module that looks like the MVC Application (See Figure 7 below)

Figure 7 – Add the Module to the Page

The really cool thing is that we can still browse to the site (as an MVC Application) by selecting the Default.aspx page, and selecting View in Browser from the context menu, as we did in Figure 3 above.

Conclusions

In summary I have demonstrated in this article, that using ASP.NET MVC for Module Development is a possibility.  There still are a number of issues to resolve however, including, but not limited to:

1. Handling routes other than the default route.
2. Do the Html Helpers in ASP.NET MVC still work? and if not how can we make them work?
3. As Webforms allows only one Form tag which is defined in the base page -Default.aspx -how do we handle Forms in an MVC Module.
4. Issues around the use of Master pages and styles, and DNN skinning – we can solve this by removing the dependency on Master pages which is not a requirement of ASP.NET MVC.

I don’t expect any of these to be show-stoppers, but much more work still needs to be done.  In future blogs, I will describe how what I describe in this article was done and report on my attempts to resolve the remaining issues.

From all the buzz and hype in the tech media, you would have thought that today was the second coming of the "Messiah”.  For those of you who have been out of the loop – or hiking in the Himalyas - Steve Jobs, CEO of Apple today announced the new Apple iPad device.

I must admit I was one of the sceptics.  Before today there have been a few failed attempts to establish “Tablet Devices” – can anyone say Apple Newton?  But I have to say that I think Apple has got it about right this time.  You can quibble over a missing feature here and a missing feature there, but the overall package – size, features, app support and most importantly price is in my opinion a winner.

Why? What makes it a winner? 

1. I love my iPod Touch and I would have bought an iPhone, when they became available in Canada had I not just upgraded my phone a few months before its release.
   Even if all this new device did was provide a larger screen and allowed me to watch video in HD it would be worth considering when I need to replace my iPod Touch.
2. I also own a Sony eReader device – I travel quite a bit and I love the concept of bringing a selection of books with me on this portable device – rather than the bulk of many paperbacks.  The new iBooks app and iBookStore means that it is now truly possible to have one device for audio/video and eBooks.
3. I like to read newspapers and magazines and I have not found an iPhone app that is satisfying – and while the eReader style of Newspaper/Magazine browsing is better, lack of color is a drawback. 
   The “New York Times” app looked really cool – like a real eNewspaper - and if my favorite newspapers did the same I would consider subscribing.
4. Email/Word etc – no smartphone  type device is truly satisfying for email or word documents – a larger screen provides a much better experience.  I currently travel with a 4lb Dell Notebook (an XPS 1330) mainly for the Email and Office App capabilities – this device with its Email and $10/app iWork apps will satisfy most of my needs in this area.
   If I need to do some development while travelling I would still need my notebook at a bare minimum, but for most trips this would suffice (especially with the keyboard dock).
5. Web browsing – as with email no smartphone is really satisfying as a web browser.
6. 10 hrs battery life – While people are complaining about this being much less than a kindle or an eReader – this is plenty for most uses as it can be plugged in overnight.
7. $499 for the same capabilities I have in my iPod – this won’t break the bank and is competitive with NetBook pricing.

That’s my quick review – Can haz plz?