Some of my posts are really reactions to search queries that have previously landed on my blog.  If they did a search that got to my blog, but I know they didn't find what they were looking for, chances are they (or someone else) will do the same again.  And, if I HAVE the information they are looking for, it makes sense to just add the information, even if it's what I would consider well-known or common sense information. (common sense for software developers, that is)

One general search query I see again and again is something like "What is Action<T> for?" or "What is Func<T>?"

These are framework-provided, generic delegate types.  If you'll recall, delegates can be thought of as type-safe function pointers.  A delegate type really just captures a signature as "callable" object.  Leveraging generics to define delegate types that can capture common signatures is goodness, since they are very flexible and can be used by anyone.  This also aids in interop between different components, since a general signature is far more interopable than custom delegate types.

In v2.0, several functional-looking APIs were added that took delegates as arguments (think List<T>), so instead of adding a special delegate type for each API, several "generic" delegates were added to capture the "essence" of a signature such as Action<T> which takes T and does some action (returning void), Predicate<T> which takes T and returns bool (presumably doing some test against T), Comparer<T> which compares 2 T's, etc.

In v3.5, even more generalized functional patterns were introduced (used heavily in Linq).  And we added a bunch more Action<> "overloads" for functions returning void, and added Func<> "overloads" for functions with a return value.  (I use overload loosely since these are classes and not methods) These patterns dropped the semantic "meaning" of the delegate, and just went straight to the idea of capturing a signature.

These framework-provided delegates are useful for using in your own code rather than creating your own.  Whether you leverage the Linq-centric, super-generic Action/Func pattern, or opt to consume the more meaningful v2.0 Predicate, Comparer, etc. is up to you.

The CTP for the MVC framework includes support for master-page, page, and user-control based views.  I thought it might be interesting to enable .ashx-based views for things like RSS generation via System.Xml.Linq, or other more "raw" view output.

As it turns out, this is fairly trivial.  The place we need to extend is the IViewFactory returned by Controller.ViewFactory.  This is the component that is responsible for creating the view when a call to RenderView is made.

The default view factory is the WebFormViewFactory, which knows how to generate views based on .master, .aspx, and .ascx views.  Since we want to add support for .ashx, we'll use WebFormViewFactory as a starting place.  We'll inherit from WebFormViewFactory and override CreateView to supply our extra .ashx lookup.

          using System; using System.Globalization; using System.IO; using System.Web; using System.Web.Compilation; using System.Web.Mvc; publicclass SpecialViewFactory
: WebFormViewFactory { staticreadonlystring[]
ViewLocationFormats = newstring[]
{ "~/Views/{1}/{0}.ashx", "~/Views/Shared/{0}.ashx"
}; ControllerContext _ControllerContext; #region IViewFactory Members protectedoverride IView
CreateView(ControllerContext controllerContext, string viewName, string masterName, object viewData)
{ _ControllerContext = controllerContext; //check to
see if there is an ashx that matches here.objectvalue = null;
controllerContext.RouteData.Values.TryGetValue("controller", outvalue); string controllerName
= valueasstring; if (controllerName
== null) { thrownew InvalidOperationException("No
route data value available for controller."); } Type viewType = null; foreach (var
loc in ViewLocationFormats) { var path = string.Format(CultureInfo.InvariantCulture,
loc, viewName, controllerName); viewType = GetCompiledType(path); if (viewType
!= null) break;
} if (viewType == null)
{ returnbase.CreateView(controllerContext,
viewName, masterName, viewData); } if (!typeof(IView).IsAssignableFrom(viewType))
{ //TODO: better exceptionthrownew InvalidOperationException("Type
not a view"); } var view = (IView)Activator.CreateInstance(viewType); var viewHandler
= view as ViewHandler; if (viewHandler
!= null) viewHandler.ViewData = viewData; _ControllerContext
= null; return view;
} private Type GetCompiledType(string path)
{ Type compiledType = null; try { if (File.Exists(_ControllerContext.HttpContext.Request.MapPath(path)))
{ compiledType = BuildManager.GetCompiledType(path); } } catch (HttpCompileException)
{ throw; } catch (HttpParseException)
{ throw; } catch (HttpException)
{ } return compiledType; } #endregion } 

GetCompiledType had to be replicated as it isn't exposed in the base class.  Note, I added a File.Exists check before I attempt to get the compiled type from the BuildManager. This was really to avoid having to deal with a bunch of first chance exceptions in the debug, although it seems likely that avoiding the exception is a good thing.  It wouldn't catch handlers that are mapped in the app dynamically or via web.config.

As you can see, I also added a ViewHandler class that my handlers can inherit from that gives them the same goodies that the other views get, but I'll leave that as an exercise for the reader to implement.

So, now the only thing remaining is to inject our special view factory into the pipeline instead of the default.  A simple way to do this is to set the ViewFactory property in the constructor of any controller that needs .ashx support. Now, you can create .ashx files and use them as views!

Next time, I'll show you how to add support for routing controller actions based on data not in the URL.