I'm porting an application from WebForms to MVC.
I have a WebForms UserControl that is used throughout the site and which contains presentational and business logic, and in particular some 'initizliation' logic (in the Page_Load)
My understanding of MVC UerControls is that they have no dedicated controller and thus contain no logic, and the logic is added to the controller of the viewpage to which the UserControl is added.
Now, I don;t want to have to write the initialization logic in my ViewPage, as this UserControl appears on several pages, thus duplication of logic.
I don't think I can user a MasterPage, as the UserControl can be rendered either vertically to the left of the page or hozontally at the top of the page depending on what page it is. This would require 2 MasterPage's, and again duplication of logic.
Do I have any other options?
This is a good case to use the RenderAction html helper. Much better, grab the Microsoft MVC futures and use the RenderAction method. Basically it lets you call a controller action within a view, which is alot more like how UserControls work than RenderPartial.
Bleh, I guess I should do it properly and pass in a object via my controller's viewdata rather than hacky-slash it.
Related
I keep hearing ViewComponents replaced RenderAction in core. However the one big thing I see missing is the ability to handle forms. It would seem ViewComponents can't do this within the view component class where as RenderAction could handle this. I understand the details as to why technically this is the case however, I am using RenderAction in .NET as (what I would refer to as a real self contained component) but the migration to Core sort of scares me because RenderAction was replaced by ViewComponent yet doesn't give the same level of functionality.
I'm just curious on what my options are when I migrate to Core with RenderAction where my "components" are handling form gets/posts. Is there any real conversion for this for Core? The only option I see is to change my component view where it specifies what controller to use and have it be dynamic to get the calling controller name via:
HttpContext.Current.Request.RequestContext.RouteData.Values["controller"]
However, this now means in every place I use this "component" I need to alter the "parent" controller to have this action method and do inside it what my RenderAction component was which seems like a horrible idea.
I've been reading a lots of blogs on MVC provided here:
http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog.aspx
However, I am not being able to explain/convience myself/team:
When to use custom control vs. out of box site core controller?
When does the Out of Box Controller gets invoked?
Benifit of custom control vs. out of box controllers?
If we go with out of box, should we include all business logic on Views. Is this testable?
I also looked at below and still not certain:
https://bitbucket.org/demoniusrex/launch-sitecore-mvc-demo
Any help will be appreciated.
Whilst I broadly agree with Kevin Obee's statement I think it's worth reminding ourselves that controllers are being used in two distinct roles in Sitecore:
Page level controller (invoked by item route)
Component level controller (invoked by redering mechanism)
When to use: Custom controller / default Sitecore controller
Page level controller
Any route that matches an item path will by default use the Index action on the Sitecore.Mvc.Controllers.SitecoreController. This action will return a ViewResult based on the layout configuration of the item.
If you have a need for changing this behaviour (e.g. something that impacts the entire page) you can specify a custom controller and action on the item (or the Standard Values for the item). For the custom controller you can either roll your own or subclass the default controller.
Component level controller
For ViewRendering Sitecore renders the Razor views without the need for a specific controller (well I guess it's the page level controller that is in play - but just imagine that Sitecore provides a default controller that gets the model using the mvc.getModel pipeline and feeds it to the Razor view).
For ControllerRendering you provide a custom controller that can execute logic (see Kevin's answer) and provide a model for the view. There is no benefit from subclassing Sitecore.Mvc.Controllers.SitecoreController.
When are controllers invoked
Page level controller
The action on the page level controller is invoked by the routing engine.
Component level controller
The action on a ControllerRendering is invoked as the page view renders.
Benefit of using: Custom controller / default Sitecore controller
The benefit of a custom controller over the default Sitecore controller is that you are in control of the logic. The benefit of using the default Sitecore controller is that Sitecore provides the logic for you.
Should we include all business logic on Views
No. (See Kevin's answer)
My personal view is that the business logic should go in command and query classes that are invoked from the controller class. From these calls you can assemble a strongly typed view model which gets passed to a dumb razor view for rendering.
Ensure that any services that the controller relies on are passed into it via constructor injection using contracts (interfaces) instead of concrete classes and you should end up with solution that is unit testable.
I have looked all over for elegant solutions to this not so age-old question. How can I lock down form elements within an ASP.Net MVC View, without adding if...then logic all over the place?
Ideally the BaseController, either from OnAuthorization, or OnResultExecultion, would check the rendering form elements and hide/not render them based on role and scope.
Another approach I have considered is writing some sort of custom attributes, so as to stay consistent with how how we lock down ActionResults with [Authorize]. Is this even possible without passing a list of hidden objects to the view and putting if's all over?
Other background info: We will have a database that will tell us at execution time (based on user role/scope) what elements will be hidden. We are using MVC3 with Razor Viewengine. We're utilizing a BaseController where any of the Controller methods can be overridden.
Any help on this would be deeply appreciated!
You could use a number of different methods:
Send the user to a different view (display only view) based on the action filter, or a condition in the controller.
On a field basis, you could build the logic into the editor templates to read custom data-annotations based on role/permission.
You can build HTML helpers to handle the logic and render the appropriate partial view, css class, or text.
For more reading:
How much logic is allowed in ASP.NET
MVC views?
ASP.NET MVC 2 Templates, Part 1: Introduction (there are 5 parts, very informative and a good place to start developing your own editor templates)
What is the difference between viewstate and viewdata in mvc?
I was just going through the MVC framework & the exact question popped up in my head.. I understand the difference as below.
ASP.Net & MVC are two different worlds. But looking closely they are not. The concepts of web remains the same and it just the way to write the code. Ok letz compare them
ASP.Net
.aspx -- So this is the view which contains the html to be rendered in the browser
.aspx.cs -- as we know this is the code behind for doing all the manipulation of the html
So on top of that we have the BO with our properties and which is bound to the controls using databind.
So here comes the ViewState which remembers the data bound to the controls back and forth between the postback.
MVC
View - this holds all the HTML code which in turn is still a .aspx or ascx file
Controller - has the logic behind the HTML. Inside that you have the action methods for performing the specific actions.
So here instead of BO, you have the Models with the same properties which is given to the View to render itself in a different syntax instead of a databind.
Now ViewData is used to bind the anonymous data between the controller and the view.
Comparatively ViewData is more organized and easy to use but apart from that they serve a similar purpose but different in few ways. Like Viewstate is persistent between postbacks and ViewData is not as MVC is stateless.
Hope this explains to an extent
ViewState and ViewData can handle some complex objects.
ViewState is within page lifecycle while ViewData works in very different way. ViewData can be passed to the target view.
Please refer here for understanding of viewState:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
for viewData:
http://www.asp.net/mvc/tutorials/asp-net-mvc-views-overview-cs
hope that helps
View state is used only in ASP.net forms,controls and Page life cycle. View state is used by ASP.net framework to manage control states.
View Data is a dataset or Data which is passed to your View - to dipslay HTML data in MVC,
Viewstate is not used in MVC. Please refer above mentioned links for more details.
I make heavy use of View Components in some of the larger applications I've built in Monorail - What is the equivalent approach in ASP.Net MVC for a view component, that can support sections etc.?
Actually you have several options to create the equivalent of a ViewComponent in ASP.NET MVC, depending in the complexity of your component. I use these two approaches which are the more mvc-ish of the options I am aware of.
1:
The simplest thing is to create a ViewUserControl and display it using Html.RenderPartial with the helper. The ViewUserControl is a simple piece of markup with no backing controller (I think you can put a codebehind file if you want).
Optionally, you can pass a model object or the entire ViewData dictionary to the view when calling RenderPartial, like this:
<% Html.RenderPartial("TopBar", model); %>
"TopBar" is an ascx page. This works anywhere, in master pages and in normal views.
2:
If you want your component to have more complicated logic or to access datasources, IoC, etc, then you can use Html.RenderAction which is an extension method found in the Microsoft.Web.Mvc assembly. I am using this out of the mvccontrib distribution. It works like this, you need to create a normal controller with all the logic you need, then create some views and all of these things become your component, for example:
public class AboutComponentController : Controller {
public IRepository Repository{ get; set; }
public ActionResult Detail() {
var lastEvent = Repository.FindAll<Auditoria>().FirstOrDefault();
return View(lastEvent);
}
}
Notice how I have a reference to an IRepository which is going to be injected with IoC (Windsor in my case) and I can do anything a normal controller would do.
Now, in any page (master or normal) where you want to use your component, import Microsoft.Web.Mvc and call Html.RenderAction with the appropriate parameters. This will create a mini mvc pipeline that creates the controller, resolves the view, etc., just like a Monorail ViewComponent. I prefer to use the lambda based variation of the method, like this:
<% Html.RenderAction<AboutComponentController>(x => x.Detail("a message"));%>
Unfortunately, the only way to pass parameters is to use the method call itself, which in turn must be unique in the controller. Still needs some work to resemble a ViewComponent.
I don't use masterpages or layouts in the views of my components since they are composition elements themselves.
Remember that when using the Webforms view engine, you can have strongly typed views if you like to have intellisense when using the Model variable in code blocks.
The beauty of this is that you can mix view engines with these approaches, I usually create the components in nvelocity and display them in aspx pages, etc.
I now there can be issues with caching of the partial views but I haven't run into any so far. I am sure there are other options (like subcontrollers in mvccontrib) but this is usually enough for simple cases. Of course you can use normal ASP.net components in your aspx view pages but that would be cheating right? hehe. I hope it helps.
Phil Haack blogged about creating areas to group controllers into sub-folders/sections similar to MonoRails.