Portable Areas from MvcContrib provide a great way to build modular and composite applications on top of MVC. In short, portable areas provide a way to distribute MVC binary components as simple .NET assemblies where the aspx/ascx files are actually compiled into the assembly as embedded resources. I’ve blogged about Portable Areas in the past including this post here which talks about embedding resources and you can read more of an intro to Portable Areas here.

As great as Portable Areas are, the question that seems to come up the most is: what about MasterPages? MasterPages seems to be the one thing that doesn’t work elegantly with portable areas because you specify the MasterPage in the @Page directive and it won’t use the same mechanism of the view engine so you can’t just embed them as resources. This means that you end up referencing a MasterPage that exists in the host application but not in your portable area. If you name the ContentPlaceHolderId’s correctly, it will work – but it all seems a little fragile.

Ultimately, what I want is to be able to build a portable area as a module which has no knowledge of the host application. I want to be able to invoke the module by a full route on the user’s browser and it gets invoked and “automatically appears” inside the application’s visual chrome just like a MasterPage. So how could we accomplish this with portable areas? With this question in mind, I looked around at what other people are doing to address similar problems. Specifically, I immediately looked at how the Orchard team is handling this and I found it very compelling. Basically Orchard has its own custom layout/theme framework (utilizing a custom view engine) that allows you to build your module without any regard to the host. You simply decorate your controller with the [Themed] attribute and it will render with the outer chrome around it:

   1:  [Themed]

   2:  public class HomeController : Controller

Here is the slide from the Orchard talk at this year MIX conference which shows how it conceptually works:

It’s pretty cool stuff.  So I figure, it must not be too difficult to incorporate this into the portable areas view engine as an optional piece of functionality. In fact, I’ll even simplify it a little – rather than have 1) Document.aspx, 2) Layout.ascx, and 3) <view>.ascx (as shown in the picture above); I’ll just have the outer page be “Chrome.aspx” and then the specific view in question. The Chrome.aspx not only takes the place of the MasterPage, but now since we’re no longer constrained by the MasterPage infrastructure, we have the choice of the Chrome.aspx living in the host or inside the portable areas as another embedded resource!

Disclaimer: credit where credit is due – much of the code from this post is me re-purposing the Orchard code to suit my needs.

To avoid confusion with Orchard, I’m going to refer to my implementation (which will be based on theirs) as a Chrome rather than a Theme. The first step I’ll take is to create a ChromedAttribute which adds a flag to the current HttpContext to indicate that the controller designated Chromed like this:

   1:  [Chromed]

   2:  public class HomeController : Controller

The attribute itself is an MVC ActionFilter attribute:

   1:  public class ChromedAttribute : ActionFilterAttribute

   2:  {

   3:      public override void OnActionExecuting(ActionExecutingContext filterContext)

   4:      {

   5:          var chromedAttribute = GetChromedAttribute(filterContext.ActionDescriptor);

   6:          if (chromedAttribute != null)

   7:          {

   8:              filterContext.HttpContext.Items[typeof(ChromedAttribute)] = null;

   9:          }

  10:      }

  11:   

  12:      public static bool IsApplied(RequestContext context)

  13:      {

  14:          return context.HttpContext.Items.Contains(typeof(ChromedAttribute));

  15:      }

  16:   

  17:      private static ChromedAttribute GetChromedAttribute(ActionDescriptor descriptor)

  18:      {

  19:          return descriptor.GetCustomAttributes(typeof(ChromedAttribute), true)

  20:              .Concat(descriptor.ControllerDescriptor.GetCustomAttributes(typeof(ChromedAttribute), true))

  21:              .OfType<ChromedAttribute>()

  22:              .FirstOrDefault();

  23:      }

  24:  }

With that in place, we only have to override the FindView() method of the custom view engine with these 6 lines of code:

   1:  public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)

   2:  {

   3:      if (ChromedAttribute.IsApplied(controllerContext.RequestContext))

   4:      {

   5:          var bodyView = ViewEngines.Engines.FindPartialView(controllerContext, viewName);

   6:          var documentView = ViewEngines.Engines.FindPartialView(controllerContext, "Chrome");

   7:          var chromeView = new ChromeView(bodyView, documentView);

   8:          return new ViewEngineResult(chromeView, this);

   9:      }

  10:   

  11:      // Just execute normally without applying Chromed View Engine

  12:      return base.FindView(controllerContext, viewName, masterName, useCache);

  13:  }

If the view engine finds the [Chromed] attribute, it will invoke it’s own process – otherwise, it’ll just defer to the normal web forms view engine (with masterpages). The ChromeView’s primary job is to independently set the BodyContent on the view context so that it can be rendered at the appropriate place:

   1:  public class ChromeView : IView

   2:  {

   3:      private ViewEngineResult bodyView;

   4:      private ViewEngineResult documentView;

   5:   

   6:      public ChromeView(ViewEngineResult bodyView, ViewEngineResult documentView)

   7:      {

   8:          this.bodyView = bodyView;

   9:          this.documentView = documentView;

  10:      }

  11:   

  12:      public void Render(ViewContext viewContext, System.IO.TextWriter writer)

  13:      {

  14:          ChromeViewContext chromeViewContext = ChromeViewContext.From(viewContext);

  15:   

  16:          // First render the Body view to the BodyContent

  17:          using (var bodyViewWriter = new StringWriter())

  18:          {

  19:              var bodyViewContext = new ViewContext(viewContext, bodyView.View, viewContext.ViewData, viewContext.TempData, bodyViewWriter);

  20:              this.bodyView.View.Render(bodyViewContext, bodyViewWriter);

  21:              chromeViewContext.BodyContent = bodyViewWriter.ToString();

  22:          }

  23:          // Now render the Document view

  24:          this.documentView.View.Render(viewContext, writer);

  25:      }

  26:  }

The ChromeViewContext (code excluded here) mainly just has a string property for the “BodyContent” – but it also makes sure to put itself in the HttpContext so it’s available. Finally, we created a little extension method so the module’s view can be rendered in the appropriate place:

   1:  public static void RenderBody(this HtmlHelper htmlHelper)

   2:  {

   3:      ChromeViewContext chromeViewContext = ChromeViewContext.From(htmlHelper.ViewContext);

   4:      htmlHelper.ViewContext.Writer.Write(chromeViewContext.BodyContent);

   5:  }

At this point, the other thing left is to decide how we want to implement the Chrome.aspx page. One approach is the copy/paste the HTML from the typical Site.Master and change the main content placeholder to use the HTML helper above – this way, there are no MasterPages anywhere. Alternatively, we could even have Chrome.aspx utilize the MasterPage if we wanted (e.g., in the case where some pages are Chromed and some pages want to use traditional MasterPage):

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

   2:  <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">

   3:      <% Html.RenderBody(); %>

   4:  </asp:Content>

At this point, it’s all academic. I can create a controller like this:

   1:  [Chromed]

   2:  public class WidgetController : Controller

   3:  {

   4:      public ActionResult Index()

   5:      {

   6:          return View();

   7:      }

   8:  }

Then I’ll just create Index.ascx (a partial view) and put in the text “Inside my widget”. Now when I run the app, I can request the full route (notice the controller name of “widget” in the address bar below) and the HTML from my Index.ascx will just appear where it is supposed to.

This means no more warnings for missing MasterPages and no more need for your module to have knowledge of the host’s MasterPage placeholders. You have the option of using the Chrome.aspx in the host or providing your own while embedding it as an embedded resource itself.

I’m curious to know what people think of this approach. The code above was done with my own local copy of MvcContrib so it’s not currently something you can download. At this point, these are just my initial thoughts – just incorporating some ideas for Orchard into non-Orchard apps to enable building modular/composite apps more easily. Additionally, on the flip side, I still believe that Portable Areas have potential as the module packaging story for Orchard itself.

What do you think?