What is the best process to extend the Razor view-engine to add additional keywords?
I'm not a fan of the dynamic ViewBag property, so for all of my pages I define both a strongly-typed ViewModel POCO, but also a strongly-typed ViewData object:
public abstract class BaseViewData<TModel,TController> : ViewDataDictionary<TModel>
(TController is specified to optionally allow strongly-typed callbacks to the parent Controller)
This is so I can have compile-time verified members, like String PageTitle (in a site-wide base class) and per-page members - it works in tandem with the ViewModel: the BaseViewData-subclass contains one-way data, and the ViewModel-class contains two-way data. This works great when you tweak the MSBuild system to precompile your views into the output assembly - no more .aspx or .cshtml files!
In ASP.NET MVC (using the WebForms view-engine) I have my own base ViewPage subclass:
public class ViewPage2<TViewModel,TViewData> : ViewPage<TModel> where TViewData : ViewDataDictionary<TModel> {
private TViewData _data;
public new TViewData ViewData {
get {
if( _data == null ) {
_data = (TViewData)base.ViewData;
}
return _data;
}
}
}
I recently brought this over to Razor, easily done:
public abstract class WebViewPage2<TViewModel,TViewData> : WebViewPage<TModel> where TData : ViewDataDictionary<TModel> {
// same ViewData property code as above
}
In the .cshtml files you can manually specify the base-class with the #inherits razor keyword - which requires the fully-qualified concrete generic type name - but alternatively you can omit #inherits and instead specify the #model keyword, which Razor will pass as the TModel argument to WebViewPage<TModel>.
As my base-class adds a second generic type argument, I'd rather not have to type out this ins my .cshtml files:
#inherits MyNamespace.WebViewPage2<MyOtherNameSpace.Views.FooViewModel,MyOtherNameSpace.Views.FooViewData>
...but instead do this:
Web.config
<system.web.webPages.razor>
<pages pageBaseType="MyNamespace.WebViewPage2">
...
MyPage.cshtml
#model FooViewModel
#data FooViewData
But this would require extending the Razor View-engine somehow - but this is non-obvious as it requires extending the Razor parser itself so it recognises #data TViewData and passes it as the second type argument.
You can implement an inheriting ViewClass like this (be careful with the namespace, it must not be changed):
namespace System.Web.Mvc {
public abstract class WebViewPage<TViewModel, TModel> : WebViewPage<TModel> where TViewModel : class {
private TViewModel _viewModel;
public TViewModel ViewModel {
get {
if (_viewModel == null) {
throw new InvalidOperationException("No ViewModel defined for this View.");
}
return _viewModel;
}
set { _viewModel = value; }
}
public override void InitHelpers() {
base.InitHelpers();
if (this.ViewBag.ViewModel == null) {
// No ViewModel defined => set null.
}
else if (!(this.ViewBag.ViewModel is TViewModel)) {
throw new InvalidOperationException(string.Format("The specified ViewModel value is of type '{0}' and must be of type '{1}'.", this.ViewBag.ViewModel.GetType(), typeof(TViewModel)));
} else {
_viewModel = this.ViewBag.ViewModel;
}
}
}
}
Then you dont have to change the web.config or anything else and can instantiate the view like this:
#model ViewModelType, (Input?)ModelType
The typed ViewModel (Type would by ViewModelType) is then available in the view via #ViewModel.
The Model of type (Input)ModelType is still available via #Model like it always was.
Related
I am wondering if its possible to take an existing partial view's logic and reuse it for dynamic email generation, within a preprocessor template?
When looking through the T4ToolKit's intellisense options for
<## import namespace="System.Web.Mvc" #>
Mvc's namespace does not appear, is it possible to include the namespace and call
Html.RenderPartial("viewName", this.Model)
from within a preprocessor template?
i.e.
<## template language="C#" #>
This is a header
<#= Html.RenderPartial("<%PATH%>/MyPartialRazerView", this.Model) #>
This is a Footer
<#+
public MyType Model { get; set; }
#>
so I may programmatically access my template, reuse a view's display logic and build, say an email on the fly (I know the Email line is nonsense, just short hand for simplicity)
var template = MyTemplate(){ Model = MyViewModel };
Email.Send(emailAddress, title, template.TransformText(), null) etc..
TIA
This can be done for sure, but you need to use a different extension methods than RenderPartial, because these write directly to the response. I tried Partial extension methods, which return the MvcHtmlString which works fine in the template. This is my test T4 runtime template, RuntimeTextTemplate1.tt:
<## template language="C#" #>
<## import namespace="System.Web.Mvc.Html" #>
LogOnPartial:
<#= Html.Partial("_LogOnPartial") #>
Then you also need to jump some ASP.NET MVC hoops to get the actual HtmlHelper instance into your template.
I created a partial class, to add the Html property to the template and instantiate the HtmlHelper and to provide a constructor:
public partial class RuntimeTextTemplate1
{
public HtmlHelper Html
{
get;
private set;
}
public RuntimeTextTemplate1(ViewContext viewContext, IViewDataContainer viewDataContainer)
{
Html = new HtmlHelper(viewContext, viewDataContainer);
}
}
A HtmlHelper needs a ViewContext and IViewDataContainer to be created and those in turn have another dependencies. I provided what is needed from the controller using some dummy classes:
public class HomeController : Controller
{
public ActionResult TemplateTest()
{
var viewContext = new ViewContext(ControllerContext, new DummyView(), ViewData, TempData, TextWriter.Null);
var template = new RuntimeTextTemplate1(viewContext, new ControllerViewDataContainer(this));
return Content(template.TransformText());
}
}
public class DummyView : IView
{
public void Render(ViewContext viewContext, TextWriter writer)
{
// Do nothing
}
}
public class ControllerViewDataContainer : IViewDataContainer
{
private Controller controller;
public ViewDataDictionary ViewData
{
get { return controller.ViewData; }
set { }
}
public ControllerViewDataContainer(Controller controller)
{
this.controller = controller;
}
}
And I successfully get the template output out of it.
So while this can be done, it depends on your specific situation, how exactly you need to use it, how your view is parametrized, and how you can assemble the required classes together to get to the HtmlHelper instance.
In the end, you may find that making the template the primary source of the required output, and using this in your views and outside them is easier than the other way around.
Just wondering what the actual difference between the ViewData that is bound to the MVC view and the ViewData that is bound to the #Html helper object?
I have written a page and they don't seem to refer to the same thing. Is ViewData used anywhere else in the application as another dictionary hidden under the same name?
SHORT ANSWER:
The HtmlHelper's ViewData is based on the view's data. So it has same values upon entering view code (for example, Razor or ASPX page). But you can change these ViewDatas separately.
It is used same way in AjaxHelper.
RepeaterItem has it's own ViewData, which is based on the item.
I have not found any use of different ViewData anywhere.
UPDATE:
ViewData and #Html.ViewData are different only when you use a strongly typed view. If you use a not strongly typed view, both they are equal as reference. So I think this was done to wrap the ViewData into strongly typed ViewDataDictionary<>.
SOME INVESTIGATIONS:
I have taken a look at the decompiled sources and here is what I found.
Let's see, what is #Html.ViewData:
namespace System.Web.Mvc
{
public class HtmlHelper<TModel> : HtmlHelper
{
private ViewDataDictionary<TModel> _viewData;
public ViewDataDictionary<TModel> ViewData
{
get
{
return this._viewData;
}
}
public HtmlHelper(ViewContext viewContext, IViewDataContainer viewDataContainer)
: this(viewContext, viewDataContainer, RouteTable.Routes)
{
}
public HtmlHelper(ViewContext viewContext, IViewDataContainer viewDataContainer, RouteCollection routeCollection)
: base(viewContext, viewDataContainer, routeCollection)
{
this._viewData = new ViewDataDictionary<TModel>(viewDataContainer.ViewData);
}
}
}
As we see, the ViewData is instantiated from some viewDataContainer in HtmlHelper constructor.
Let's try to see, how is this connected with the page:
namespace System.Web.Mvc {
public abstract class WebViewPage<TModel> : WebViewPage {
// some code
public override void InitHelpers() {
base.InitHelpers();
// ...
Html = new HtmlHelper<TModel>(ViewContext, this);
}
// some more code
}
}
So the current page is the viewDataContainer.
So, we see, that a new instance of a ViewData dictionary is instantiated for HtmlHelper based on the dictionary, which is stored in View. The only option, which could make the two be kinda same, if they used same Disctionary internally. Let's check that.
Here is ViewData constructor:
public ViewDataDictionary(ViewDataDictionary dictionary)
{
if (dictionary == null) {
throw new ArgumentNullException("dictionary");
}
foreach (var entry in dictionary) {
_innerDictionary.Add(entry.Key, entry.Value);
}
foreach (var entry in dictionary.ModelState) {
ModelState.Add(entry.Key, entry.Value);
}
Model = dictionary.Model;
TemplateInfo = dictionary.TemplateInfo;
// PERF: Don't unnecessarily instantiate the model metadata
_modelMetadata = dictionary._modelMetadata;
}
As we can see, entries a just copied, but a different underlying _innerDictionary is used.
I am using ASP.NET MVC 3 and Autofac for my dependency injection. I am using AutoMapper for my mapping.
I have an IMapper class that I use for all my model view mappings. So any any of my mapping classes can implement this interface. In the controller below the constructor receives an IMapper instance, and in my User controller it might receive a different instance, maybe userMapper. Getting back to the code below, I have a class called NewsMapper and it implements IMapper. How do I setup dependency injection so that this controller must receive an instance of NewsMapper? Please bear in mind that I might have another mapper called UserMapper.
I have the following controller:
public class NewsController
{
private INewsService newsService;
private IMapper newsMapper;
public NewsController(INewsService newsService, IMapper newsMapper)
{
if (newsService == null)
{
throw new ArgumentNullException("newsService");
}
if (newsMapper == null)
{
throw new ArgumentNullException("newsMapper");
}
this.newsService = newsService;
this.newsMapper = newsMapper;
}
}
I have the following configuration in my global.asax.cs:
var builder = new ContainerBuilder();
builder.RegisterControllers(Assembly.GetExecutingAssembly());
builder.RegisterType<NewsService>().As<INewsService>();
builder.RegisterType<NewsRepository>().As<INewsRepository>();
UPDATED:
My IMapper interface:
public interface IMapper
{
object Map(object source, Type sourceType, Type destinationType);
}
My NewsMapper class:
public class NewsMapper : IMapper
{
static NewsMapper()
{
Mapper.CreateMap<News, NewsViewModel>();
Mapper.CreateMap<NewsViewModel, News>();
}
public object Map(object source, Type sourceType, Type destinationType)
{
return Mapper.Map(source, sourceType, destinationType);
}
}
My controller action method where I do the mappings:
[HttpPost]
public ActionResult Create(NewsViewModel newsViewModel)
{
// Check model state
if (!ModelState.IsValid)
{
return View("Create", newsViewModel);
}
// Do mapping
var news = (News)newsMapper.Map(newsViewModel, typeof(NewsViewModel), typeof(News));
// Add to database via news service
// Redirect to list view
return RedirectToAction("List", "News");
}
The problem here is the broadness of the IMapper contract. It is too general - the NewsController wants to map something like News to NewsViewModel but IMapper just says "maps something to something."
Instead, have a look at creating a generic variant such as IMapper<TFrom,TTo>. Then, you can set up container so that the NewsController receives an IMapper<News,NewsModel> which is unambiguous and should uniquely match the NewsMapper component (however you decide to set that up.)
Edit
For examples/variants on the generic mapper theme see:
http://consultingblogs.emc.com/owainwragg/archive/2010/12/15/automapper-profiles.aspx
http://lucisferre.net/2009/12/31/graphite-update-the-automapfilter-for-model-e280933e-viewmodel-mapping/
Specifying a default Unity type mapping for a generic interface and class pair
I edited my whole question, so do not wonder :)
Well, I want to have an ActionResult that takes domain model data and some additional parameters, i.e page index and page size for paging a list. It decide itself if it returns a PartialViewResult or a ViewResult depending on the kind of web request (ajax request or not).
The reffered data shall be mapped automatically by using an IMappingService, which is responsible for transforming any domain model data into a view model.
The MappingService uses AutoMapper for simplicity.
MappingActionResult:
public abstract class MappingActionResult : ActionResult
{
public static IMappingService MappingService;
}
BaseHybridViewResult:
public abstract class BaseHybridViewResult : MappingActionResult
{
public const string defaultViewName = "Grid";
public string ViewNameForAjaxRequest { get; set; }
public object ViewModel { get; set; }
public override void ExecuteResult(ControllerContext context)
{
if (context == null) throw new ArgumentNullException("context");
var usePartial = ShouldUsePartial(context);
ActionResult res = GetInnerViewResult(usePartial);
res.ExecuteResult(context);
}
private ActionResult GetInnerViewResult(bool usePartial)
{
ViewDataDictionary viewDataDictionary = new ViewDataDictionary(ViewModel);
if (String.IsNullOrEmpty(ViewNameForAjaxRequest))
{
ViewNameForAjaxRequest = defaultViewName;
}
if (usePartial)
{
return new PartialViewResult { ViewData = viewDataDictionary, ViewName = ViewNameForAjaxRequest };
}
return new ViewResult { ViewData = viewDataDictionary };
}
private static bool ShouldUsePartial(ControllerContext context)
{
return context.HttpContext.Request.IsAjaxRequest();
}
}
AutoMappedHybridViewResult:
public class AutoMappedHybridViewResult<TSourceElement, TDestinationElement> : BaseHybridViewResult
{
public AutoMappedHybridViewResult(PagedList<TSourceElement> pagedList)
{
ViewModel = MappingService.MapToViewModelPagedList<TSourceElement, TDestinationElement>(pagedList);
}
public AutoMappedHybridViewResult(PagedList<TSourceElement> pagedList, string viewNameForAjaxRequest)
{
ViewNameForAjaxRequest = viewNameForAjaxRequest;
ViewModel = MappingService.MapToViewModelPagedList<TSourceElement, TDestinationElement>(pagedList);
}
public AutoMappedHybridViewResult(TSourceElement model)
{
ViewModel = MappingService.Map<TSourceElement, TDestinationElement>(model);
}
public AutoMappedHybridViewResult(TSourceElement model, string viewNameForAjaxRequest)
{
ViewNameForAjaxRequest = viewNameForAjaxRequest;
ViewModel = MappingService.Map<TSourceElement, TDestinationElement>(model);
}
}
Usage in controller:
public ActionResult Index(int page = 1)
{
return new AutoMappedHybridViewResult<TeamEmployee, TeamEmployeeForm>(_teamEmployeeRepository.GetPagedEmployees(page, PageSize));
}
So as you can see the IMappingService is hidden. The controller should not know anything about the IMappingService interface, when AutoMappedHybridViewResult is used.
Is the MappingActionResult with the static IMappingServer appropriate or am I violating the DI principle?
I think a better design is to have a ViewResultFactory that depends on IMappingService, then you can inject that into your controller. Then you call it like so:
public class MyController : Controller
{
IViewResultFactory _viewResultFactory;
ITeamEmployeeRepository _teamEmployeeRepository;
public MyController(IViewResultFactory viewResultFactory)
{
_viewResultFactory = viewResultFactory;
}
public ActionResult MyAction(int page, int pageSize)
{
return
_viewResultFactory.GetResult<TeamEmployee, TeamEmployeeForm>(
_teamEmployeeRepository.GetPagedEmployees(page, pageSize));
}
}
The implementation would like this (you would need to create overloads for each of your HybridViewResult constructors):
public HybridViewResult<TSourceElement, TDestinationElement> GetResult<TSourceElement, TDestinationElement>(PagedList<TSourceElement> pagedList)
{
return new HybridViewResult<TSourceElement, TDestinationElement>(_mappingService, pagedList);
}
That way you hide the implementation from your controllers, and you don't have to depend on the container.
There are a few different points that you could inject IMappingService. http://codeclimber.net.nz/archive/2009/04/08/13-asp.net-mvc-extensibility-points-you-have-to-know.aspx is a good site for help in picking the appropriate extensibility points for .NET MVC.
If you want to stick with having this functionality be a derived ActionResult, then I think you could put the dependency in the ActionInvoker if you want to, but the Controller makes more sense to me. If you don't want the IMappingService in the Controller, you could always wrap it in a HybridViewResultFactory, and access that object in the Controller. In that case your shortcut methods would look like:
public HybridViewResult<TSourceElement, TDestinationElement> AutoMappedHybridView<TSourceElement,TDestinationElement>(PagedList<TSourceElement> pagedList, string viewNameForAjaxRequest)
{
HybridViewResultFactory.Create<TSourceElement, TDestinationElement>(pagedList, viewNameForAjaxRequest);
}
etc.
I'm not sure why you need to use an ActionResult, but if there is no reason that makes it explicitly necessary, you could create a HybridViewModel class and a HybridViewModelBinder class that is injected with the mapping service dependency.
I am assuming you want to use constructor injection, but if you have the StructureMap dependency in your UI assembly, you could access a static dependency resolver class (like Clowers said).
This question would be easier to give a definite answer to if I understood why you using an ActionResult.
It seems like you are using the action result to handle two functionalities that do not necessarily go together all the time, and that could be used separately. Also, there is not a clear indication that it needs to be in an ActionResult.
Presumably, you could (a) leverage the Automapper functionality for results other than html (ViewResult) output, and (b) you could leverage the functionality of auto-detecting ajax requests without needing to automap the model.
It seems to me like the automapping of the view model could be used to inject the view model into the controller action directly, thus removing the controller's dependency on the IMappingService. What you would need is a ModelBinder class to be injected with your IMappingService (the implementation of which I assume contains a repository or datastore type dependency).
Here is a good article explaining how to leverage model binders: http://odetocode.com/blogs/scott/archive/2009/04/27/6-tips-for-asp-net-mvc-model-binding.aspx.
Then you can overwrite the DefaultModelBinder in the classes that need to be Automapped as follows:
public ActionResult DoItLikeThis([AutoMap(typeof(MyDomainModelClass))]MyViewModelClass viewModel){
//controller action logic
}
Now, regarding the HybridViewResult, I would suggest that you handle this with an Action Filter instead. So, you could just use ActionResult or ViewResultBase as the Result type of your action method and decorate it with an action filter, i.e.:
[AutoSelectViewResult]
public ViewResultBase AndDoThisLikeSo(){
//controller action logic
}
I think overall this will be a much better solution than coupling these two functionalities to an ActionResult.
Setup:
CustomViewEngine
CustomController Base
CustomViewPage Base (in this base, a new property is added "MyCustomProperty")
Problem:
When a view is strongly typed such as: <# Page Inherits="CustomViewPage<MyCustomObject" MyCustomProperty="Hello">, I get a compiler "Parser" error stating that MyCustomProperty is not a public property of System.Web.Mvc.ViewPage
I have done numerous trial and errors (see below) to see whats causing this error and have come to the following conclusions:
The error only occurs when I declare "MyCustomProperty" or any other property in the #Page directive of the view.
The error will always display "System.Web.Mvc.ViewPage" rather than the declared inherits=".." class.
Update: Looks like Technitium found another way to do this that looks much easier, at least on newer versions of ASP.NET MVC. (copied his comment below)
I'm not sure if this is new in ASP.NET MVC 3, but when I swapped the
Inherits attribute from referencing the generic in C# syntax to CLR
syntax, the standard ViewPageParserFilter parsed generics correctly --
no CustomViewTypeParserFilter required. Using Justin's examples, this
means swapping
<%# Page Language="C#" MyNewProperty="From #Page directive!"
Inherits="JG.ParserFilter.CustomViewPage<MvcApplication1.Models.FooModel>
to
<%# Page Language="C#" MyNewProperty="From #Page directive!"`
Inherits="JG.ParserFilter.CustomViewPage`1[MvcApplication1.Models.FooModel]>
Original answer below:
OK, I solved this. Was a fascinating exercise, and the solution is non-trivial but not too hard once you get it working the first time.
Here's the underlying issue: the ASP.NET page parser does not support generics as a page type.
The way ASP.NET MVC worked around this was by fooling the underlying page parser into thinking that the page is not generic. They did this by building a custom PageParserFilter and a custom FileLevelPageControlBuilder. The parser filter looks for a generic type, and if it finds one, swaps it out for the non-generic ViewPage type so that the ASP.NET parser doesn't choke. Then, much later in the page compilation lifecycle, their custom page builder class swaps the generic type back in.
This works because the generic ViewPage type derives from the non-generic ViewPage, and all the interesting properties that are set in a #Page directive exist on the (non-generic) base class. So what's really happening when properties are set in the #Page directive is that those property names are being validated against the non-generic ViewPage base class.
Anyway, this works great in most cases, but not in yours because they hardcode ViewPage as the non-generic base type in their page filter implementation and don't provide an easy way to change it. This is why you kept seeing ViewPage in your error message, since the error happens in between when ASP.NET swaps in the ViewPage placeholder and when it swaps back the generic ViewPage right before compilation.
The fix is to create your own version of the following:
page parser filter - this is almost an exact copy of ViewTypeParserFilter.cs in the MVC source, with the only difference being that it refers to your custom ViewPage and page builder types instead of MVC's
page builder - this is identical to ViewPageControlBuilder.cs in the MVC source, but it puts the class in your own namespace as opposed to theirs.
Derive your custom viewpage class directly from System.Web.Mvc.ViewPage (the non-generic version). Stick any custom properties on this new non-generic class.
derive a generic class from #3, copying the code from the ASP.NET MVC source's implementation of ViewPage.
repeat #2, #3, and #4 for user controls (#Control) if you also need custom properties on user control directives too.
Then you need to change the web.config in your views directory (not the main app's web.config) to use these new types instead of MVC's default ones.
I've enclosed some code samples illustrating how this works. Many thanks to Phil Haack's article to help me understand this, although I had to do a lot of poking around the MVC and ASP.NET source code too to really understand it.
First, I'll start with the web.config changes needed in your web.config:
<pages
validateRequest="false"
pageParserFilterType="JG.ParserFilter.CustomViewTypeParserFilter"
pageBaseType="JG.ParserFilter.CustomViewPage"
userControlBaseType="JG.ParserFilter.CustomViewUserControl">
Now, here's the page parser filter (#1 above):
namespace JG.ParserFilter {
using System;
using System.Collections;
using System.Web.UI;
using System.Web.Mvc;
internal class CustomViewTypeParserFilter : PageParserFilter
{
private string _viewBaseType;
private DirectiveType _directiveType = DirectiveType.Unknown;
private bool _viewTypeControlAdded;
public override void PreprocessDirective(string directiveName, IDictionary attributes) {
base.PreprocessDirective(directiveName, attributes);
string defaultBaseType = null;
// If we recognize the directive, keep track of what it was. If we don't recognize
// the directive then just stop.
switch (directiveName) {
case "page":
_directiveType = DirectiveType.Page;
defaultBaseType = typeof(JG.ParserFilter.CustomViewPage).FullName; // JG: inject custom types here
break;
case "control":
_directiveType = DirectiveType.UserControl;
defaultBaseType = typeof(JG.ParserFilter.CustomViewUserControl).FullName; // JG: inject custom types here
break;
case "master":
_directiveType = DirectiveType.Master;
defaultBaseType = typeof(System.Web.Mvc.ViewMasterPage).FullName;
break;
}
if (_directiveType == DirectiveType.Unknown) {
// If we're processing an unknown directive (e.g. a register directive), stop processing
return;
}
// Look for an inherit attribute
string inherits = (string)attributes["inherits"];
if (!String.IsNullOrEmpty(inherits)) {
// If it doesn't look like a generic type, don't do anything special,
// and let the parser do its normal processing
if (IsGenericTypeString(inherits)) {
// Remove the inherits attribute so the parser doesn't blow up
attributes["inherits"] = defaultBaseType;
// Remember the full type string so we can later give it to the ControlBuilder
_viewBaseType = inherits;
}
}
}
private static bool IsGenericTypeString(string typeName) {
// Detect C# and VB generic syntax
// REVIEW: what about other languages?
return typeName.IndexOfAny(new char[] { '<', '(' }) >= 0;
}
public override void ParseComplete(ControlBuilder rootBuilder) {
base.ParseComplete(rootBuilder);
// If it's our page ControlBuilder, give it the base type string
CustomViewPageControlBuilder pageBuilder = rootBuilder as JG.ParserFilter.CustomViewPageControlBuilder; // JG: inject custom types here
if (pageBuilder != null) {
pageBuilder.PageBaseType = _viewBaseType;
}
CustomViewUserControlControlBuilder userControlBuilder = rootBuilder as JG.ParserFilter.CustomViewUserControlControlBuilder; // JG: inject custom types here
if (userControlBuilder != null) {
userControlBuilder.UserControlBaseType = _viewBaseType;
}
}
public override bool ProcessCodeConstruct(CodeConstructType codeType, string code) {
if (codeType == CodeConstructType.ExpressionSnippet &&
!_viewTypeControlAdded &&
_viewBaseType != null &&
_directiveType == DirectiveType.Master) {
// If we're dealing with a master page that needs to have its base type set, do it here.
// It's done by adding the ViewType control, which has a builder that sets the base type.
// The code currently assumes that the file in question contains a code snippet, since
// that's the item we key off of in order to know when to add the ViewType control.
Hashtable attribs = new Hashtable();
attribs["typename"] = _viewBaseType;
AddControl(typeof(System.Web.Mvc.ViewType), attribs);
_viewTypeControlAdded = true;
}
return base.ProcessCodeConstruct(codeType, code);
}
// Everything else in this class is unrelated to our 'inherits' handling.
// Since PageParserFilter blocks everything by default, we need to unblock it
public override bool AllowCode {
get {
return true;
}
}
public override bool AllowBaseType(Type baseType) {
return true;
}
public override bool AllowControl(Type controlType, ControlBuilder builder) {
return true;
}
public override bool AllowVirtualReference(string referenceVirtualPath, VirtualReferenceType referenceType) {
return true;
}
public override bool AllowServerSideInclude(string includeVirtualPath) {
return true;
}
public override int NumberOfControlsAllowed {
get {
return -1;
}
}
public override int NumberOfDirectDependenciesAllowed {
get {
return -1;
}
}
public override int TotalNumberOfDependenciesAllowed {
get {
return -1;
}
}
private enum DirectiveType {
Unknown,
Page,
UserControl,
Master,
}
}
}
Here's the page builder class (#2 above):
namespace JG.ParserFilter {
using System.CodeDom;
using System.Web.UI;
internal sealed class CustomViewPageControlBuilder : FileLevelPageControlBuilder {
public string PageBaseType {
get;
set;
}
public override void ProcessGeneratedCode(
CodeCompileUnit codeCompileUnit,
CodeTypeDeclaration baseType,
CodeTypeDeclaration derivedType,
CodeMemberMethod buildMethod,
CodeMemberMethod dataBindingMethod) {
// If we find got a base class string, use it
if (PageBaseType != null) {
derivedType.BaseTypes[0] = new CodeTypeReference(PageBaseType);
}
}
}
}
And here's the custom view page classes: the non-generic base (#3 above) and the generic derived class (#4 above):
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Diagnostics.CodeAnalysis;
using System.Web.Mvc;
namespace JG.ParserFilter
{
[FileLevelControlBuilder(typeof(JG.ParserFilter.CustomViewPageControlBuilder))]
public class CustomViewPage : System.Web.Mvc.ViewPage //, IAttributeAccessor
{
public string MyNewProperty { get; set; }
}
[FileLevelControlBuilder(typeof(JG.ParserFilter.CustomViewPageControlBuilder))]
public class CustomViewPage<TModel> : CustomViewPage
where TModel : class
{
// code copied from source of ViewPage<T>
private ViewDataDictionary<TModel> _viewData;
public new AjaxHelper<TModel> Ajax
{
get;
set;
}
public new HtmlHelper<TModel> Html
{
get;
set;
}
public new TModel Model
{
get
{
return ViewData.Model;
}
}
[SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
public new ViewDataDictionary<TModel> ViewData
{
get
{
if (_viewData == null)
{
SetViewData(new ViewDataDictionary<TModel>());
}
return _viewData;
}
set
{
SetViewData(value);
}
}
public override void InitHelpers()
{
base.InitHelpers();
Ajax = new AjaxHelper<TModel>(ViewContext, this);
Html = new HtmlHelper<TModel>(ViewContext, this);
}
protected override void SetViewData(ViewDataDictionary viewData)
{
_viewData = new ViewDataDictionary<TModel>(viewData);
base.SetViewData(_viewData);
}
}
}
And here are the corresponding classes for user controls (#5 above) :
namespace JG.ParserFilter
{
using System.Diagnostics.CodeAnalysis;
using System.Web.Mvc;
using System.Web.UI;
[FileLevelControlBuilder(typeof(JG.ParserFilter.CustomViewUserControlControlBuilder))]
public class CustomViewUserControl : System.Web.Mvc.ViewUserControl
{
public string MyNewProperty { get; set; }
}
public class CustomViewUserControl<TModel> : CustomViewUserControl where TModel : class
{
private AjaxHelper<TModel> _ajaxHelper;
private HtmlHelper<TModel> _htmlHelper;
private ViewDataDictionary<TModel> _viewData;
public new AjaxHelper<TModel> Ajax {
get {
if (_ajaxHelper == null) {
_ajaxHelper = new AjaxHelper<TModel>(ViewContext, this);
}
return _ajaxHelper;
}
}
public new HtmlHelper<TModel> Html {
get {
if (_htmlHelper == null) {
_htmlHelper = new HtmlHelper<TModel>(ViewContext, this);
}
return _htmlHelper;
}
}
public new TModel Model {
get {
return ViewData.Model;
}
}
[SuppressMessage("Microsoft.Usage", "CA2227:CollectionPropertiesShouldBeReadOnly")]
public new ViewDataDictionary<TModel> ViewData {
get {
EnsureViewData();
return _viewData;
}
set {
SetViewData(value);
}
}
protected override void SetViewData(ViewDataDictionary viewData) {
_viewData = new ViewDataDictionary<TModel>(viewData);
base.SetViewData(_viewData);
}
}
}
namespace JG.ParserFilter {
using System.CodeDom;
using System.Web.UI;
internal sealed class CustomViewUserControlControlBuilder : FileLevelUserControlBuilder {
internal string UserControlBaseType {
get;
set;
}
public override void ProcessGeneratedCode(
CodeCompileUnit codeCompileUnit,
CodeTypeDeclaration baseType,
CodeTypeDeclaration derivedType,
CodeMemberMethod buildMethod,
CodeMemberMethod dataBindingMethod) {
// If we find got a base class string, use it
if (UserControlBaseType != null) {
derivedType.BaseTypes[0] = new CodeTypeReference(UserControlBaseType);
}
}
}
}
Finally, here's a sample View which shows this in action:
<%# Page Language="C#" MyNewProperty="From #Page directive!" Inherits="JG.ParserFilter.CustomViewPage<MvcApplication1.Models.FooModel>" %>
<%=Model.SomeString %>
<br /><br />this.MyNewPrroperty = <%=MyNewProperty%>
</asp:Content>