I'd like to create a common assembly that I can use in several MVC projects (MVC 4 preferred). This assembly has to provide editor templates for primitive types. For example, a date picker. How can I do this?
I know of two ways to achieve similar goals, but I don't like those. One way is to forget about MVC's templating system and provide custom HtmlHelper extensions, like #Html.MyOwnDatePickerFor(x=>x.Field). I know of some UI frameworks that do this. I don't like it because it is not transparent (#Html.EditorFor() won't pick it up automatically) and it feels weird to have an editor template system in MVC and not use it. The other way is the actual MVC template system, by creating partial views named like EditorTemplates/datatype.cshtml (or .ascx), but it doesn't work because they have to be in the MVC project, I don't know how I can share these between multiple projects.
Any suggestions?
We have a few classes that provide the equivalent of editorfor but surrounded by different HTML. We have one for #Html.CMSEditorFor(m => m.Name) that uses the same HTML as our content management system and one for #Html.BootstrapEditorFor(m => m.Name) that churns out HTML in a nice Bootstrap compatible way.
I can't claim any credit for the idea though it comes directly from here.
ASP.NET MVC 3 Custom HTML Helpers- Best Practices/Uses
You're looking for RazorGenerator. It's made by the Razor team to allow you to compile Razor views just for this purpose: reusing the views by including the assembly in other projects.
Related
Here is what I want to achieve, I want to separate AREAs of ASP.NET MVC as pure single DLL.
Blog.DLL
Forums.DLL
FAQ.DLL
Each of them are individual ASP.NET MVC Area, with its own default CSHTML or ASPX pages. Installing, migrating and maintaining lots of pages including resources, javascripts and so on are real pain for long run. As most of these will hardly change.
My final website will be like this.
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
Without adding any thing, just dropping Blog.dll, my application should support /blog and all its pages. If I want to customize something, than I can add area, and add only cshtml pages..
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Areas
\Blog
\Views
\Shared
\BlogLayout.cshtml <-- this will override the look
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
This will help in reusing ASP.NET Area Plugins, by simply dropping the dll in bin folder. However web.config may require some changes, but most likely we will save configure values in database and only thing needed will be "Entity Framework connection string" in web.config.
My challenges (Questions)
Is it possible? It sure looks to me, but will there be any reflection/permission issues?
How do I include cshtml/aspx views within one DLL? Probably compiled versions? I have seen couple of text template based View Engines on codeplex but I am little confused on how to actually use them.
And how do I get ViewEngine to first check if physical directory file exists or not and then look into cshtml/aspx within the dll itself as resource file?
You may take a look at the following article which illustrates how a custom VirtualPathProvider could be used in order to retrieve Razor views that are embedded into separate assemblies as resources.
Maybe worth looking at portable areas from mvccontrib. I haven't used them since MVC 2, but found the following SO question by someone having some problems using them with MVC 3, with some possible solutions: ASP.NET MVC 3, Razor Views, and Portable Areas
MvcCodeRouting supports what you want, plus many other cool stuff. Check out this post about ASP.NET MVC Plugins.
Is it possible to distribute an EditorTemplate control ASCX along with a type in a library project and have it be used by MVC3 when the type is rendered with the EditorFor() method?
Where I work we have a lot of DateTime, Gender and a few more custom fields which have a specific but concsistent way of (HTML) input and a corresponding backing ViewModel type for them (i.e. DateTimeViewModel with separate month, day, year field etc.) and they are in a shared library project.
However we still have to copy the EditorTemplates for these types to each project which is not very DRY.
So is there a way to bundle such EditorTemplate along with the library project and make sure that it's used when the corresponding ViewModel is used without having to copy all EditorTemplate to every projects?
You need a custom VirtualPathProvider to achieve this but nothing out of the box. Here's a blog post you may take a look at.
Disclaimer: Custom VirtualPathProviders don't work with precompiled web applications. So if you intend to precompile your web application before shipping don't use virtual path providers.
Because of this limitation personally I use custom NuGet packages that allow the developers to pull all the necessary templates to their corresponding locations.
You could create your own VS Template, Export it and distribute it to all of your developers I think.
Write Templates for VS2010
You can register your own VirutalPathProvider implementation:
HostingEnvironment.RegisterVirtualPathProvider(new YourViewProvider());
Then you will be able to get your files from basically anywhere (for example from embedded resource).
Hope this helps.
I think this is not currently possible. ASP.NET MVC editor templates should be defined in a partial view file. There is no way to define them in code only.
I have an ASP.NET MVC 3 website and I'm looking for a way to package up a set of views and controllers into an external DLL and hopefully use MEF (Dependency Injection) to load the correct controllers and views.
Does anyone know if something like this is possible and any good links to tutorials on the subject?
Precompiled Razor for Shared Views and Mono
Compile your asp.net mvc Razor views into a seperate dll
A combination of those two will probably get the best result in your case - My precompilation code handles some things the single file generator doesn't, but Chris has more use of out of box code at runtime, which is probably better if you only need to run in a standard mvc3 setup.
I have also used aspx files set up as embedded resources ( Views in separate assemblies in ASP.NET MVC ), but Razor is quite a bit easier to work with in compiled form.
I have just started playing with the ASP.Net MVC framework, and today I created a simple UserControl that uses some CSS. Since the CSS was declared in a separate file and included in the View that called the UserControl, and not in the UserControl itself, Visual Studio could not find any of the CSS classes used in the UserControl. This got me thinking about what would be the most appropriate way of dealing with CSS in UserControls.
Declaring the CSS in the View that is using the UserControl gives more flexibility if the same control is used in different contexts and needs to be able to adapt to the style of the calling View.
Having the UserControl supply its own CSS would lead to a more clear separation, and the Views would not need to know anything about the HTML/CSS generated by the UserControl, but at the cost of a fixed look of the control.
Since I am totally new to the framework, I'm guessing people have already come to some good conclusions about this.
So, would you have the UserControl handle its own CSS, should it depend on the CSS declared in the calling View, or is there another, better solution?
If you look at a skinable toolkit like Yahoo UI it documents the classes used by each control and then provides a single skin file for the entire toolkit. By swapping out the single skin file you can change looks for your entire site.
I would assume that 99.9% of the time you would want to custom skin your controls and not have them come predefined with a look and feel.
As an example here are the CSS defines for Yahoo's TabView control
It should always be in your global CSS really. If you pass this on to a designer, you dont want to have to explain which control defines x style, etc.
A quick point... it's ok for your Views to be aware of HTML... that's what they are for. What I would recommend (if you want to be ubber cool), is to add a parameter to your "MVC UserControl" that specifies the class name. Example:
<%= MyHelperClass.Marquee("This text will scroll!!!", "important-text") %>
I'm of course pretending that "important-text" is the class name that I want to add to my control.
I am assuming that when you say "UserControl", you're referring to an example like in that link above.
I have been using ASP.net MVC for a new website.
I have found a minor nagging issue with having views with the same name but are in different folders i.e. Views/Home/Index.aspx and Views/Account/Index.aspx
The codebehind files act as if they are partial classes when there is a definition for the same event or function (i.e. PageLoad event). I have avoided this issue by explicitly providing a Namespace to the codebehind file (using the Folder name) and updating the reference in the markup page.
But like i said, this is annoying. Is there something i'm not doing correctly? or is this just a bug in beta software?
No, this is not a bug in the beta software. It has nothing to do with MVC specifically or ASP.NET in general. Essentially, your problem boils down to you wanting to have two distinct classes with the same name. The only way to do this is to put them in different namespaces.