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.
Related
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.
In my _layout.cshtml page, I've got some elements that need to be hidden on some pages. I know the pages on which we won't display some parts. For a single page, I could just do this:
#if (ViewContext.RouteData.Values["action"].ToString() != "LogIn") {
<div> .... <div>
}
But that gets messy and long with multiple pages. Someplace, ideally not in the _Layout page, I could build a list of actions, and if the current action is any of them, set a boolean variable (ShowStuff) to false. Then just do this on _Layout:
#if (ShowStuff== true) {
<div> .... <div>
}
I'm just not sure where would be the best-practice way to examine that list of actions and set the boolean. Can the _Layout page have it's own model and controller like a normal view?
Similarly to MikeSW answer, I'd use an action filter, but I would populate ViewData with a specific ViewModel. When you want to display it simply DisplayFor the value, if it's populated the template is used by whatever type the model is, if it's null nothing is displayed. (examples below from memory, may not be exactly correct.)
public BlahModelAttribute : ActionFilterAttribute
{
protected override void OnActionExecuting(ActionExecutingContext filterContext)
{
BlahModel model = Db.GetModel();
filterContext.Controller.ViewData.Set(model);
}
}
ViewData extensions:
public static ViewDataExtensions
{
private static string GetName<T>()
: where T : class
{
return typeof(T).FullName;
}
public static void Set<T>(this ViewDataDictionary viewData, T value)
: where T : class
{
var name = GetName<T>();
viewData[name] = value;
}
public static T Get<T>(this ViewDataDictionary viewData)
: where T : class
{
var name = GetName<T>();
return viewData[name] as T;
}
}
In your view:
#{var blahModel = ViewData.Get<BlahModel>() }
#Html.DisplayFor(m => blahModel)
If devs would stop looking for the 'best way' for every problem they have, that would be great. No best way here, just opinionated solutions. Here's mine: You can create an action filter [ShowNav] and decorate any controller/action you need. That filter will put a boolean into HttpContext.Items . Create then a HtmlHelper which checks for the boolean. Then in _layout, if (Html.CanShowNavig()) { <nav> } . That's the easiest solution that comes to my mind.
I have various viewmodels that have properties that must be populated. For example, imagine a database table full of countries. I have a create user page, and one of the properties on the viewmodel is List<string> Countries.
Originally I populated this in a parameterless constructor, ie.
public CreateUserViewModel()
{
this.Countries = new CountryManager().GetCountries();
}
But I read this is a bad practice, and I should pass them in.
public CreateUserViewModel(IEnumerable<string> countries)
{
this.Countries = countries;
}
But in my post, this data is lost, and if validation fails it redirects to the view, but then the countries property is null.
I am wondering how I should be repopulating this value. Manually putting some code into the controller post method seems bad, eg.
[HttpPost]
public ActionResult CreateUser(CreateUserViewModel vm)
{
if (Model.IsValid)
{
new UserManager().CreateUser(vm);
}
else
{
vm.Countries = new CountryManager().GetCountries();
return View(vm);
}
}
I am struggling to google what is probably a very common question. Any ideas?
The rationale behind avoiding parameterless constructors is for inversion of control. The logic in this case would be that Countries is a dependency and by externalizing that dependency (so that it is inject into the class, instead), you make your class less brittle and more open to extension.
However, I would argue that doesn't apply actually in your scenario, because Countries is not really a dependency of your class, but rather of your view. The view model is there to serve the view and is somewhat closed and unextensible anyways as a result. In other words, do follow inversion of control for things like services, repositories, utility classes, etc., but for view models, it's not really necessary or important.
Anyways, here's how I handle this type of thing:
public class FooViewModel
{
...
// Countries is not initialize by a constructor
public IEnumerable<SelectListItem> Countries { get; set; }
}
Then in your controller:
public class FooController : Controller
{
internal void PopulateCountryChoices(FooViewModel model)
{
// fetch countries
model.Countries = countries.Select(m => new SelectListItem
{
Text = m.Name,
Value = m.Id.ToString()
});
}
public ActionResult Bar()
{
var model = new FooViewModel();
PopulateCountryChoices(model);
return View(model);
}
[HttpPost]
public ActionResult Bar(FooViewModel model)
{
if (ModelState.IsValid)
{
// save and redirect
}
PopulateCountryChoices(model);
return View(model);
}
}
Instead of populating this static data in model, We can populate Dropdownlist values in the view itself -
#Html.DropDownListFor(model => model.State,
new SelectList(Utils.GetCountries()),
"value",
"text",
2)
Where Utils is a Helper class which returns all the countries.
This way of populating all the static data (I mean all options of Dropdownlist or Listbox etc) will be taken over by the View, which makes model to be free from holding this data.
After years of working with WebForms I recently started the transition to MVC. I'm trying to create a plugable, lightweight content editing module but I've run into some problems.
The idea is simple: create a HtmlHelper named EditableSimpleHtml that can be used in a #using... { } syntax so that the following can be achieved in a razor view:
#using (Html.EditableSimpleHtml("MyKey"))
{
<h3>Test</h3>
<p>
1<br />
</p>
}
The value between the {...} is the default value for when no content can not be found in the data storage.
I've create a HtmlHelper. Below is a simplified version:
public static IDisposable EditableSimpleHtml(this HtmlHelper helper, string key)
{
// Get the content from the data storage using the key (I will not show the provider itself, its just a provider that will access a db)
var provider = ContentEditing.Provider;
string value = provider.GetValue(key);
if (value == null)
{
// No value found in the data storage for the supplied key, we have to use the default value from within the #using... { } statement
// Can I get that value here? I want to to store it initialy in the data storage
value = "..."; // How to get html from within the #using... { }?
}
return new ContentEditableHtmlString(helper, value);
}
public class ContentEditableHtmlString : IDisposable
{
private readonly HtmlHelper _helper;
public ContentEditableHtmlString(HtmlHelper helper, string value)
{
_helper = helper;
var builder = new TagBuilder("div");
var writer = _helper.ViewContext.Writer;
writer.Write(builder.ToString(TagRenderMode.StartTag));
writer.Write(value);
}
public void Dispose()
{
_helper.ViewContext.Writer.Write("</div>");
}
}
The problem is that I can't get the (default) content from within the #using... { } statement in the HtmlHelper, or at least I don't know how. I need it in case I want to store it to the database initially.
Second problem is that the value between the #using... { } statement will always be rendered. In the case when the content can be loaded from the data storage I want the default value to be replaced with the value from the data storage.
Is there a way to achieve this or did I start of on a completely wrong path?
You can not get the html within the #using{...} statement the way you are doing right now.
The closest thing you can do is use Templated Razor Delegates
public static HelperResult EditableSimpleHtml(this HtmlHelper helper, string key,
Func<string, HelperResult> template)
{
var templateResult = template(null);
//you have your value here that you can return directly
//or you can return HelperResult to write to the response directly
var templateResultHtml = templateResult.ToHtmlString();
return new HelperResult(writer =>
{
templateResult.WriteTo(writer);
});
}
And in your view:
#Html.EditableSimpleHtml("MyKey", #<text>
<h3>Test</h3>
<p>#DateTime.Now</p>
</text>)
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.