I have a fairly large ASP MVC application. Instead of having many controllers all in the controller directory I would rather create some hierarchy. So I might have something like
~\Controllers\Security\
~\Controllers\Maintenance\
~\Controllers\Reports\
I would also like to be able to do similar with Views
~\Views\Security\Users\
~\Views\Security\Roles\
~\Views\Maintenance\Customer\
~\Views\Maintenance\Product\
Is this easily done?
I think you're looking for something like what the "master" says in this post:
http://haacked.com/archive/0001/01/01/areas-in-aspnetmvc.aspx
Basically you have to create a ViewEngine to specify where to look for the views. It's a fairly simple code, just don't forget to register it in the global.asax! As for the controller part you'll have to register new routes also in the global.asax.
The concept you're searching for is called "areas", as outlined by Phil Haack here:
http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx
I would think you'd need to write your own RouteHandler, which shouldn't be too tough.
A quick google search turned up: This blog post detailing it
Have you considered to switch to Features Folder. I've tried it (with little modifications) and it works pretty good.
Described in this post
http://timgthomas.com/2013/10/feature-folders-in-asp-net-mvc/
Code examples are in Jimmiy Bogard's repo
https://github.com/jbogard/presentations/tree/master/putyourcontrollersonadietv2
What you really want here is for your Views folder hierarchy to match the namespace hierarchy of your controllers. You can write a custom ViewEngine to do this fairly easily - see my ControllerPathViewEngine project on GitHub for details.
I've included a snippet of the ControllerPathRazorViewEngine class to outline how it works. By intercepting the FindView / FindPartialView methods and replacing the controller name with a folder path (based on controller namespace and name), we can get it to load views from nested folders within the main Views folder.
public class ControllerPathRazorViewEngine : RazorViewEngine
{
//... constructors etc.
public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
{
return FindUsingControllerPath(controllerContext, () => base.FindView(controllerContext, viewName, masterName, useCache));
}
public override ViewEngineResult FindPartialView(ControllerContext controllerContext, string partialViewName, bool useCache)
{
return FindUsingControllerPath(controllerContext, () => base.FindPartialView(controllerContext, partialViewName, useCache));
}
private ViewEngineResult FindUsingControllerPath(ControllerContext controllerContext, Func<ViewEngineResult> func)
{
string controllerName = controllerContext.RouteData.GetRequiredString("controller");
string controllerPath = controllerPathResolver.GetPath(controllerContext.Controller.GetType());
controllerContext.RouteData.Values["controller"] = controllerPath;
var result = func();
controllerContext.RouteData.Values["controller"] = controllerName;
return result;
}
}
Related
In a default install of a MVC3 website tabs are created in the top left. I would like to hide/show these tabs based on whether the current user would have access to the index ViewResult. The allowed roles to the ViewResult are defined by attributes. Is there any way of getting the list of roles for a ViewResult?
If you are asking (sorry, wasn't clear exactly to me) about conditional showing of HTML elements based on roles, you could do something like this:
#if (User.IsInRole("Administrators"))
{
#Html.ActionLink("Do Some Action", "DoAction", "SomeController")
}
If that isn't what you're asking, let me know.
Follow-up based on your comment:
Your question interests me and I did a little poking around and found that Vivien Chevallier has an interesting idea here which essentially lets you write something like so:
#Html.ActionLinkAuthorized("The Privilege Zone", "ThePrivilegeZone", "Home", true)
in your View and then this check the controller action and either renders a link or doesn't.
In his controller example, you've got an action like this:
[Authorize(Roles = "Administrator")]
public ActionResult ThePrivilegeZone()
{
return View();
}
(I guess the key point here is that your View doesn't know squat about "Administrators" and relies upon the extension code to do the heavy lifting here:
public static MvcHtmlString ActionLinkAuthorized(
this HtmlHelper htmlHelper,
string linkText, string actionName, string controllerName,
RouteValueDictionary routeValues,
IDictionary<string, object> htmlAttributes, bool showActionLinkAsDisabled)
{
if (htmlHelper.ActionAuthorized(actionName, controllerName))
{
return htmlHelper.ActionLink(
linkText,
actionName, controllerName, routeValues, htmlAttributes);
}
else
{
if (showActionLinkAsDisabled)
{
TagBuilder tagBuilder = new TagBuilder("span");
tagBuilder.InnerHtml = linkText;
return MvcHtmlString.Create(tagBuilder.ToString());
}
else
{
return MvcHtmlString.Empty;
}
}
}
Rather than cut/paste all of that code here, you can take a look at it and see the example application he's got for that. I think what's particularly interesting to this approach is that the view could display that PrivilegeZone link but knows only that something else will determine whether that's the case. So, assuming that you got new requirements to only allow folks who were "Administrators" or "Owners" to have access to the link, you could modify the controller action accordingly and not touch the view code. Interesting idea, at least to me.
I am working on a plugin system for Asp.net MVC 2. I have a dll containing controllers and views as embedded resources.
I scan the plugin dlls for controller using StructureMap and I then can pull them out and instantiate them when requested. This works fine. I then have a VirtualPathProvider which I adapted from this post
public class AssemblyResourceProvider : VirtualPathProvider
{
protected virtual string WidgetDirectory
{
get
{
return "~/bin";
}
}
private bool IsAppResourcePath(string virtualPath)
{
var checkPath = VirtualPathUtility.ToAppRelative(virtualPath);
return checkPath.StartsWith(WidgetDirectory, StringComparison.InvariantCultureIgnoreCase);
}
public override bool FileExists(string virtualPath)
{
return (IsAppResourcePath(virtualPath) || base.FileExists(virtualPath));
}
public override VirtualFile GetFile(string virtualPath)
{
return IsAppResourcePath(virtualPath) ? new AssemblyResourceVirtualFile(virtualPath) : base.GetFile(virtualPath);
}
public override CacheDependency GetCacheDependency(string virtualPath, IEnumerable virtualPathDependencies,
DateTime utcStart)
{
return IsAppResourcePath(virtualPath) ? null : base.GetCacheDependency(virtualPath, virtualPathDependencies, utcStart);
}
}
internal class AssemblyResourceVirtualFile : VirtualFile
{
private readonly string path;
public AssemblyResourceVirtualFile(string virtualPath)
: base(virtualPath)
{
path = VirtualPathUtility.ToAppRelative(virtualPath);
}
public override Stream Open()
{
var parts = path.Split('/');
var resourceName = Path.GetFileName(path);
var apath = HttpContext.Current.Server.MapPath(Path.GetDirectoryName(path));
var assembly = Assembly.LoadFile(apath);
return assembly != null ? assembly.GetManifestResourceStream(assembly.GetManifestResourceNames().SingleOrDefault(s => string.Compare(s, resourceName, true) == 0)) : null;
}
}
The VPP seems to be working fine also. The view is found and is pulled out into a stream. I then receive a parse error Could not load type 'System.Web.Mvc.ViewUserControl<dynamic>'. which I can't find mentioned in any previous example of pluggable views. Why would my view not compile at this stage?
Thanks for any help,
Ian
EDIT:
Getting closer to an answer but not quite clear why things aren't compiling. Based on the comments I checked the versions and everything is in V2, I believe dynamic was brought in at V2 so this is fine. I don't even have V3 installed so it can't be that. I have however got the view to render, if I remove the <dynamic> altogether.
So a VPP works but only if the view is not strongly typed or dynamic
This makes sense for the strongly typed scenario as the type is in the dynamically loaded dll so the viewengine will not be aware of it, even though the dll is in the bin. Is there a way to load types at app start? Considering having a go with MEF instead of my bespoke Structuremap solution. What do you think?
The settings that allow parsing of strongly typed views are in ~/Views/Web.Config. When the view engine is using a virtual path provider, it is not in the views folder so doesn't load those settings.
If you copy everything in the pages node of Views/Web.Config to the root Web.Config, strongly typed views will be parsed correctly.
Try to add content of Views/Web.config directly to your main web.config under specific location, e.g. for handling virtual paths like ~/page/xxx. See more details here: http://blog.sergkazakov.com/2011/01/aspnet-strongly-typed-view-and-virtual.html
Is there a way to load types at app start?
Yes, you may use BuildManager.AddReferencedAssembly(assembly), where assembly is the one, containing the requested type. So, once you use MEF, the last should be easy, but beware, everything should be done before Application_Start, so you may wish to use PreApplicationStartMethodAttribute.
I am writing a VirtualPathProvider to dynamically load my MVC views, which are located in a different directory. I successfully intercept the call before MVC (in FileExists), but in my VirtualPathProvider, I get the raw, pre-routed url like:
~/Apps/Administration/Account/LogOn
Personally, I know that MVC will look for
~/Apps/Administration/Views/Account/LogOn.aspx
and that I should be reading the file contents from
D:\SomeOtherNonWebRootDirectory\Apps\Administration\Views\Account\LogOn.aspx
but I'd rather not hard code the logic to "add the directory named Views and add aspx to the end".
Where is this logic stored and how can I get it into my virtual path provider?
Thanks. Sorry if I'm not being clear.
Edited
You need to make a class that inherits WebFormViewEngine and sets the ViewLocationFormats property (inherited from VirtualPathProviderViewEngine).
The default values can be found in the MVC source code:
public WebFormViewEngine() {
MasterLocationFormats = new[] {
"~/Views/{1}/{0}.master",
"~/Views/Shared/{0}.master"
};
AreaMasterLocationFormats = new[] {
"~/Areas/{2}/Views/{1}/{0}.master",
"~/Areas/{2}/Views/Shared/{0}.master",
};
ViewLocationFormats = new[] {
"~/Views/{1}/{0}.aspx",
"~/Views/{1}/{0}.ascx",
"~/Views/Shared/{0}.aspx",
"~/Views/Shared/{0}.ascx"
};
AreaViewLocationFormats = new[] {
"~/Areas/{2}/Views/{1}/{0}.aspx",
"~/Areas/{2}/Views/{1}/{0}.ascx",
"~/Areas/{2}/Views/Shared/{0}.aspx",
"~/Areas/{2}/Views/Shared/{0}.ascx",
};
PartialViewLocationFormats = ViewLocationFormats;
AreaPartialViewLocationFormats = AreaViewLocationFormats;
}
You should then clear the ViewEngines.Engines collection and add your ViewEngine instance to it.
As SLaks mentioned above, you need to create a Custom View Engine and add your view-finding logic in the FindView method.
public class CustomViewEngine : VirtualPathProviderViewEngine
{
public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
{
//Set view path
string viewPath = GetCurrentViewPath();
//Set master path (if need be)
string masterPath = GetCurrentMasterPath();
return base.FindView(controllerContext, viewPath, masterPath, useCache);
}
}
In the Application_Start, you can register your View Engine like this:
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new CustomViewEngine());
The answer was that MVC was not finding my controller properly. If MVC does in fact find your controller properly, there should be two requests processed by the VirtualPathProvider:
An initial request with the acutal url requested (ie. http://.../Account/LogOn).
A subsequent FileExists check for http://.../Views/Account/LogOn.aspx, after the request in 1. returns false calling FileExists. This actually retuns the aspx content.
I have a number of permissions, and based on a set of conditions these permission determine if a user can see certain features. I have written a helper function for this as the logic in the view became quite extensive.
Essentially I'm looking for a function the same as Html.ActionLink that I can access from a class file (Ideally if I can access the Helper that would be great) So I can do somthing like so,
public static string GetAdminLinks()
{
if(PermCheck)
{
return(Html.ActionLink(...));
}
}
Any sugestions?
in controller:
Url.Action("Index", "Home", null, Request.Url.Scheme);
It largely depends on how your permission check is implemented (and of which information it needs to determine the user's permissions). Anyhow, I'd implement it as an extension to the HtmlHelper class.
Somewhere in your App_Code:
using System.Web.Mvc.Html;
public static class HtmlHelperExtensions {
public static string SecureActionLink(this HtmlHelper htmlHelper, string action, string controller){
if(PermCheck)
return htmlHelper.ActionLink(action, controller);
else
return string.Empty;
}
//add other ActionLink overrides if you like...
}
Then you'll be able to call the extension method from anywhere in your ViewPages without any code behind.
I'm writing a helper method for ASP.NET MVC and I need to call Url.Content to get an appropriate URL for the context. However, in order to create a new UrlHelper() I need to get the current RequestContext (System.Web.Routing.RequestContext to be precise) and I'm not sure how to grab it. Anyone know?
If the current IHttpHandler is MvcHandler, you can use
((MvcHandler)HttpContext.Current.Handler).RequestContext
Noticed this was still unanswered. As of MVC 1.0 you can do:
public static string NewHelperMethod(this HtmlHelper helper)
{
UrlHelper url = new UrlHelper(helper.ViewContext.RequestContext);
You may have found an answer elsewhere, but here goes;
In a controller action, you can get to the current RequestContext like so:
public ActionResult SomeAction(){
var helper = new UrlHelper(this.ControllerContext.RequestContext);
...
}
As mentioned above, just extend the HtmlHelper and the context is exposed in that way. For example:
public static string ExtensionMethodName(this HtmlHelper html,object o)
{
html.ViewContext.HttpContext.Request.Uri ... etc
}
Don't create a new one. Just extend the existing UrlHelper, just like you'd extend HtmlHelper:
public static string IdLink(this UrlHelper helper, Guid id)
{ //...
If you must use both HtmlHelper and UrlHelper, pass one of them as a regular (non-"this") argument.