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?
