Trying to create a MVC User Control in the Release Candidate and I can't see to make one with a codebehind file. The same is true for MVC View pages.
Creating Views in the Beta would produce codebehinds...am I missing something?
Code behind kind of defeats the purpose of the MVC Framework. Functionality should be kept separate from the view, the MVC team felt that code behind pages went against this ideology and therefore removed them.
Your can create a custom helper method to create your control. Also I'm not sure if MVC has view components (Monorail/Castle) but that could be an option as well.
From ScottGu's Blog post:
*Views without Code-Behind Files
Based on feedback we’ve changed view-templates to not have a code-behind file by default. This change helps reinforce the purpose of views in a MVC application (which are intended to be purely about rendering and to not contain any non-rendering related code), and for most people eliminates unused files in the project.
The RC build now adds C# and VB syntax support for inheriting view templates from base classes that use generics. For example, below we are using this with the Edit.aspx view template – whose “inherits” attribute derives from the ViewPage type:
One nice benefit of not using a code-behind file is that you'll now get immediate intellisense within view template files when you add them to the project. With previous builds you had to do a build/compile immediately after creating a view in order to get code intellisense within it. The RC makes the workflow of adding and immediately editing a view compile-free and much more seamless.
Important: If you are upgrading a ASP.NET MVC project that was created with an earlier build make sure to follow the steps in the release notes – the web.config file under the \Views directory needs to be updated with some settings in order for the above generics based syntax to work.*
I answered this question here:
How to add a Code-behind page to a Partial View
Seems this wasn't particularly tricky, and is quite do-able
This answer worked for a Partial 'ViewUserControl' but the same should apply
Ok.
First: Add a Class file with the convention of .cs (i.e. view.ascx.cs)
Second: Add "using System.Web.Mvc;" to the class
Third: Change the Class to Inherit from "ViewUserControl<>"
Fourth: Add the following to the View's header:
CodeBehind="View.ascx.cs" Inherits="Project.Views.Shared.View"
Fifthly: Copy the files out of the solution and drag back in to reassociate the two together
Note: For this to work with a Normal MVC View you just need to inherit the class from "ViewPage"
The whole idea for ASP.Net-mvc was to get rid of the codebehind files...thats why asp web controls didnt matter that most didn't work.But with the changes of getting rid of the code behind comes with a different programming style..The idea is codebehind files are EVIL:
http://stevesmithblog.com/blog/codebehind-files-in-asp-net-mvc-are-evil/
the whole idea is to make sure people remember they are using asp.Net-mvc and not asp.et web pages. take alook at this link ,it explains it a little better:
http://blog.lozanotek.com/archive/2008/10/20/Visual_Studio_Templates_for_MVC_Views_without_Codebehind_Files.aspx
I think this tutorial is what you are asking.. but not really sure what you want..
Related
I have an old Umbraco web application which was upgraded to v6 earlier this year.
It uses .NET ascx user controls and your standard .master pages as you'd expect.
I now need to create a brand new page which is essentially a booking form for an event.
I'd like to create it using MVC, as I do everything with MVC nowadays. I don't really want to duplicate the page layout / the frame. Is it possible to embed an MVC partial view inside the old master templates?
You can create the form in a .cshtml file and then add it as an Umbraco Macro. But the form couldn't use the MVC approach, it would have to be basic inline razor plus conditional statements. Which is fine but limiting. You could of course have the form posting to a controller action too but this get's a little tricky as it takes the form processing out of the page's event cycle.
Otherwise you are asking if you can reference an action in a masterpage, so no not really. I say "not really" because of course you can but it's unnatural and would make the project a nightmare for anyone to undestand of they were to pick it up. There is an article here as to how you might do it tho': http://www.hanselman.com/blog/MixingRazorViewsAndWebFormsMasterPagesWithASPNETMVC3.aspx
Also, there is also the Umbraco MvcBridge package. This was something a lot of devs used prior to being able to build directly in MVC. Essentially you can set up Macros to point to actions etc. but still within the webforms mode.
It's a great half-way house but I'm not sure abut the compatibility with v6.
I've inherited an MVC3 project that has a large number of ASPX views that I would like to convert to Razor. This question => Aspx to Razor syntax converter? is similar to mine, and it helped me find a bunch of options for converting the views themselves, but I'm unclear on the steps I need to take in addition to converting the views.
The first known limitation of Telerik's razor-converter is "The tool only works with views and does not deal with the project structure and master pages". This tool claims to be able to convert master pages as well, but it doesn't look like anybody beyond the developer has ever used it.
I think these are the steps I need to take:
Use a utility to convert the views
Convert the master pages manually (how do I do this?)
Modify the project structure (what needs to be modified?)
Delete the ASPX files
Test the application (any specific gotchas I should look out for?)
Are these the right steps? Can you help me with my questions on steps 2 and 3?
I have only tried this on one solution and the actual conversion did a fairly good job. I downloaded the Telerik converter project, compiled it, and then converted my projects using these command lines:
aspx2razor C:\Development\MyProject\MyWebProject\*.ascx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.aspx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.master C:\Development\MyProject\MyWebProject -r
I only needed to go back to add an #include for a namespace here and there, and to add a few parenthesis to force the Razor view engine to recognize my inline code properly. This was also a fairly simple solution, so YMMV. But even if it converted 80-90% of your views successfully, it's that much less manual work which you would have to perform yourself. From here, you could also create a _ViewStart.cshtml file and make a few minor adjustments to take advantage of Razor-specific layout features. (Check out Scott Gu's post on it here: http://weblogs.asp.net/scottgu/archive/2010/10/22/asp-net-mvc-3-layouts.aspx)
The big issue I had was trying to reconcile the file changes with source control. Since the classic MVC view engine uses .aspx, .ascx, and .master extensions, I had to manually add the .cshtml files to my MVC web project and source control then remove the old versions. It wasn't difficult, just time-consuming.
In addition, you may need to add all of the necessary web.config entries to support the Razor view engine as well if your project was created using MVC 1 or 2. Projects created with MVC 3 should already have these entries in place, even if it was not originally created as a Razor site.
is there any way to re-build a strongly typed view when the model class has new fields added?
At present I have not modified the initial generated view so deleting and re-creating is not a problem.
When I start to customize it to my liking I will lose all changes and I was wondering if there was a good way to manage this?
Thanks
ASP.NET MVC offers two types of scaffolding, each with its own advantages:
The first kind of scaffolding is design-time scaffolding, which is done through the Add View dialog and T4 templates. The advantage of this is that the code is entirely generated and you can completely customize it. The disadvantage is that if you change your model you have to regenerate your view (by deleting it and adding back a new one).
The second kind of scaffolding is runtime scaffolding, which is done through the Html.EditorFor() and Html.DisplayFor() methods in your view. The advantage of this is that if your model changes then the scaffolding will be automatically generated at runtime. The disadvantage is that you cannot directly customize the rendering. You can, however, give this scaffolding many hints using DataAnnotations attributes such as [DisplayText], [UIHint], and so forth, so it is quite flexible - but it is not nearly as flexible as being able to 100% customize the rendering.
To customize the rendering of runtime scaffolding (editor templates and display templates) you can find more info on Brad Wilson's blog series.
You can manually add code to your view to reflect any changes in the model.
Default scafolding is there just to give you something.
One thing you might want to look at is t4 templates using wich mvc tooling generates your default views. google for it there are examples of how you can copy those to your project and modify to have mvc generate views you want instead of default ones.
Is it possible to change around the folder organization to the following and still have MVC work.
P1
Controllers
Models
Views
P2
Controllers
Models
Views
etc..
This looks a lot like the new feature area's which is available in MVC 2 though it is currently in preview and will be release with VS 2010.
If you want to do it yourself without using areas then check out this article on view engines
as said before, the Areas feature is what you are looking for.
If you are using vs2010, then although you have MVC2, you don't have the tools for creating the areas - these are only available on vs 2008, when you install the MVC2 rc
to make it happen follow the instructions at the following link: http://msdn.microsoft.com/en-us/library/ee671793%28VS.100%29.aspx
as you can see the menu options are missing so:
download the example project from there.
build the directory structure at your solution according to the example
change the AreaRegistration.cs to match your area name
add AreaRegistration.RegisterAllAreas(); at the RegisterRoutes function at the global.asax, right after the IgnoreRoute
NOTE: the namespaces shuold contain .Areas.
for More explanations search at stackoverflow for asp-net-mvc-2-beta-single-project-area-registration-getting-http-404 (since this is the first time i post an answer - SO doesn't let me append more then 1 link, go fugure..)
Hope this helps
Should be doable, I think the default folder structure is just a suggestion. I've seen before in some documentation that larger projects would likely be split up differently, possibly even among multiple assemblies.
The only thing I would think would cause some trouble would be the views. Since controller actions are mapped to them only by file name. I know there's some way to change them, but I have not had to do so yet.
You can create your own viewengine to solve the paths. That sounds like a very strange idea, but the ViewEngine class is actually responsible for 2 things: locating a view and rendering a view to the httpresponse. The thing you have to change is the locating part, you can just inherit the default aspxviewengine and change the view locating part.
I am trying to create a .Net Library with few Controllers, and i want to reuse them in Multiple web projects.
I'm half way through, But problem i'm getting is , Whenever i add the library to the new web project , i need to copy all corresponding view files separately to the new project. Whenever i update the library, i need to repeat the steps again.
Is there any way , i can embed View files inside dll as resource , and pass it to "View()" function as an embedded resource.
What i want to achieve is , I want to put controller and corresponding views inside single dll file, so that i can easily distribute/manage the library as a single dll file
( Oneway i already found , is creating custom view class with IView Interface and Render the output directly by writing to HTML Output Writer, But i prefer to use the View file.)
Phil Haack just posted a blog post a few days ago that would probably help you; He's using a database to store the views and ruby to process them, but I would think you could take his prototype and make it work for views stored in a separate assembly fairly easily.
Just a quick glance through the code and I think the magic sauce is going to be implementing VirtualPathProviderViewEngine (See the "RubyViewEngine" class for example) and inserting your ViewEngine into ViewEngines.Engines Collection (see Global.asax.cs).
You can probably use a VirtualPathProvider for this.
The WebFormView type eventually calls BuildManager.CreateInstanceFromVirtualPath. There is not an overload or other function in BuildManager to take input from a stream instead of from a virtual path. Therefore, if you do not want to implement IView yourself, you will need to actually unpack the files to disk so that they can be compiled by BuildManager. You could still distribute your DLL as a single file, but the aspx files need to be produced in order for BuildManager to compile them. See BuildManager help for details.
Check out the ASP.NET MVC View Engine using VB.NET XML Literals project on CodePlex http://vbmvc.codeplex.com
It is a custom view engine originally conceived of by Dmitry Robsman, who is a PUM for ASP.NET at Microsoft. Each view is a VB.NET class and the Namespace (instead of file path) is used to connect Views to Controllers. It's fairly straight forward to copy the content of your ASPX view files into the XML literals in these VB classes. And as classes, they are compiled into the assembly without any extra effort.
If your controllers are C#, then most likely you'd end up with 2 DLLs, but Scott Hanselman has a blog post on getting C# and VB to live together in the same assembly. http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx
Take a gander over to codeplex and have a look at the Managed Extensibility Framework
Once your done there...
See what Maarten Balliauw has to say about ASP.NET MVC and the Managed Extensibility Framework (MEF)