how to render MVC views from SurfaceController? - umbraco

I have installed Umbraco 7 in MVC application. Have you achieved ever rendering MVC View from Surface Controller ? If it is possible to do how it can be done by passing model and passing a query string parameter to View ?

If I understand your question correctly, you need to use an approach called Route Hijacking, rather than surface controllers.
Simplified, the steps are:
Create a model matching a given Document Type.
Create a mapper to map an Umbraco IPublishedContent object to the model.
Create a controller that inherits Umbraco.Web.Mvc.RenderMvcController.
Override the Index action with a signature of ActionResult Index(Umbraco.Web.Models.RenderModel model).
Call the mapper, and return your view.
In your view / template, you will then be able to use
#model MyNewModel
instead of
#inherits Umbraco.Web.Mvc.UmbracoTemplatePage
Here is a very good tutorial / explanation on the approach.
Be sure to read the follow up post too

Related

Asp.Net MVC View function and ViewData

I have a small confusion in Asp.Net MVC
How rendering works in Asp.net MVC? We invoke View function - > Which will find the view and ask ViewEngine to parse it. Because of ViewEngine final outcome is HTML.
1)Whatever ViewData we create its available inside View. My understanding is ViewData and View function both are part of controller base class which makes ViewData available inside View function. Is it correct?
2)Finally Whats the point with WebViewPage class. ViewData keyword we use inside View(.cshtml) page is coming from the WebViewPage class. What role WebViewPage plays here.
I will really appreciate If you can point me with some good resource to understand the same
1) ViewData is merely a dictionary of objects that you can fill in the Controller and retrieve within the view. Since it is a dictionary of objects you need to cast the data back into the type it was to make full use of it.
2) WebViewPage is the base type of a razor page. It is the defined class which razor pages are compiled into at runtime. The web.config inside the views folder specifies the pageBaseType of the razor pages specifically to WebViewPage. These are two good resources regarding why its use and how you can extend it. Link1 and Link2.
Go peek inside he source code that renders the views
visit msdn

Using #Html.Partial In Sitecore

I would like to use the generic razor helper function Html.Partial to render views that have common html in them.
For instance, I have two views set up in Sitecore Payment Information.cshtml and Agent Payment Information.cshtml. These are rendered using the Sitecore rendering engine. Both of these views have very similar html in them that I would like to put in razor views not set in Sitecore and call them with #Html.Partial as appose to #Html.Sitecore().Rendering() as the latter forces me to set up a view and model in Sitecore which I am not sure is necessary.
My question is, is there anything that Sitecore does behind the scenes that makes it necessary to usethe #Html.Sitecore().Rendering() helper method instead of the #Html.Partial() helper method? Everything seems to work fine and I believe the entire view should get cached since the #Html.Partial call is nested inside either the Payment Information view or the Agent Payment information view set up in Sitecore.
Thanks in advance.
I have Html.Partial working in an MVC solution using Glass for ORM. There are two ways I've used this, one where the assumed model being passed to the partial is the same as the parent rendering and another where we create the model on the fly.
Assumes parent rendering model is passed:
#Html.Partial("~/Views/Components/MyPartialView.cshtml")
Instantiates a new model that is passed in:
#Html.Partial("~/Views/Components/Navigation/SecondaryNavigationRendering.cshtml", new SecondaryNavigation())
The parent view will need to have a mapped model in Sitecore. The secondary view does not have a mapped model in Sitecore but is typed to receive the model being passed (so in my first example that would be my IBasePage model, in my second it would be my SecondaryNavigation model).
Hope this helps.

Populating the model for a shared view, embedding a shared view within another view

I'm trying to embed a small view snippet that steps through a model fragment that works fine when I embed it in a single controller and pass it to a view like so;
Controller:
return View(_entities.formTemplate.ToList());
View:
http://www.pastie.org/666366
The thing is that I want to be able to embed this particular select box in more than just this single action / view, from the googling I've been doing this appears that it should go into a shared view, but I'm not clear then on how I could populate the model within that view from the controller? (or maybe I'm completely missing the purpose for shared views?)
In the other MVC framework I'm accustomed to working with there is the concept of a filter where you can call code before or after any action and mod the model as it passes the controller and goes to the view, is such a thing possible in .net mvc?
Any assistance appreciated.
You'll want to use the HtmlHelper method DropDownList() in order to create a input:
<%= Html.DropDownList("id", new SelectList(formBuilder, "ID", "Name")) %>
You probably want to use a ViewUserControl here.
You have a couple of options if you go that route. If it's model data that is easily available, recreate it at the call site of your RenderPartial like so:
<%=Html.RenderPartial("ViewName", new ModelData())%>
If it's data that is dependent on the current model data, then you'll need to pass that data somehow to your partial view.
ASP.Net MVC also has the concept of before/after controller actions. You decorate your controller method with an Attribute that derives from ActionFilterAttribute. In there, you have access to OnActionExecuting and OnActionExecuted.

ModelFactory in ASP.NET MVC to solve 'RenderPartial' issue

The 'RenderPartial()' method in ASP.NET MVC offeres a very low level of functionality. It does not provide, nor attempt to provide a true 'sub-controller' model *.
I have an increasing number of controls being rendered via 'RenderPartial()'. They fall into 3 main categories :
1) Controls that are direct
descendants of a specific page that
use that page's model
2) Controls that are direct
descendants of a specific page that
use that page's model with an
additional key of some type.
Think implementation of
'DataRepeater'.
3) Controls that represent unrelated
functionality to the page they appear
on. This could be anything from a
banner rotator, to a feedback form,
store locator, mailing list signup.
The key point being it doesn't care
what page it is put on.
Because of the way the ViewData model works there only exists one model object per request - thats to say anything the subcontrols need must be present in the page model.
Ultimately the MVC team will hopefully come out with a true 'subcontroller' model, but until then I'm just adding anything to the main page model that the child controls also need.
In the case of (3) above this means my model for 'ProductModel' may have to contain a field for 'MailingListSignup' model. Obviously that is not ideal, but i've accepted this at the best compromise with the current framework - and least likely to 'close any doors' to a future subcontroller model.
The controller should be responsible for getting the data for a model because the model should really just be a dumb data structure that doesn't know where it gets its data from. But I don't want the controller to have to create the model in several different places.
What I have begun doing is creating a factory to create me the model. This factory is called by the controller (the model doesn't know about the factory).
public static class JoinMailingListModelFactory {
public static JoinMailingListModel CreateJoinMailingListModel() {
return new JoinMailingListModel()
{
MailingLists = MailingListCache.GetPartnerMailingLists();
};
}
}
So my actual question is how are other people with this same issue actually creating the models. What is going to be the best approach for future compatibility with new MVC features?
NB: There are issues with RenderAction() that I won't go into here - not least that its only in MVCContrib and not going to be in the RTM version of ASP.NET-MVC. Other issues caused sufficent problems that I elected not to use it. So lets pretend for now that only RenderPartial() exists - or at least that thats what I've decided to use.
Instead of adding things like MailingListSignup as a property of your ProductModel, encapsulate both at the same level in a class like ProductViewModel that looks like:
public class ProductViewModel() {
public ProductModel productModel;
public MailingListSignup signup;
}
Then get your View to be strongly-typed to the ProductViewModel class. You can access the ProductModel by calling Model.productModel, and you can access the signup class using Model.signup.
This is a loose interpretation of Fowler's 'Presentation Model' (http://martinfowler.com/eaaDev/PresentationModel.html), but I've seen it used by some Microsoft devs, such as Rob Conery and Stephen Walther.
One approach I've seen for this scenario is to use an action-filter to populate the data for the partial view - i.e. subclass ActionFilterAttribute. In the OnActionExecuting, add the data into the ViewData. Then you just have to decorate the different actions that use that partial view with the filter.
There's a RenderPartial overload I use that let's you specify a new ViewData and Model:
RenderPartial code
If you look at the previous link of the MVC source code, as well as the following (look for RenderPartialInternal method):
RenderPartialInternal code
you can see that if basically copies the viewdata you pass creating a new Dictionary and sets the Model to be used in the control. So the page can have a Model, but then pass a different Model to the sub-control.
If the sub-controls aren't referred directly from the main View Model, you could do the trick Marc Gravell mentions to add your custom logic.
One method I tried was to use a strongly typed partial view with an interface. In most situations an agregated ViewModel is the better way, but I still want to share this.
<%# Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl<IMailingListSignup>" %>
The Viewmodel implements the interface
public class ProductViewModel:IMailingListSignup
Thats not perfect at all but solves some issues: You can still easily map properties from your route to the model. I am not shure if you can have a route parameter map to the properties of MailingListSignup otherwise.
You still have the problem of filling the Model. If its not to late I prefer to do it in OnActionExecuted. I dont see how you can fill a Model in OnActionExecuting.

Where to put master page's code in an MVC application?

I'm using a few (2 or 3) master pages in my ASP.NET MVC application and they must each display bits of information from the database. Such as a list of sponsors, current fundings status etc.
So my question was, where should I put these master-page database calling code?
Normally, these should goes into its own controller class right? But then that'd mean I'd have to wire them up manually (e.g. passing ViewDatas) since it is out of the normal routing framework provided by the MVC framework.
Is there a way to this cleanly without wiring ViewData passing/Action calls to master pages manually or subclassing the frameworks'?
The amount of documentation is very low... and I'm very new to all this including the concepts of MVC itself so please share your tips/techniques on this.
One way to do this is to put in the masterpage view the hook for the ViewData and then you define a BaseController : Controller (or multiple base classes) where you do all the db calls you need.
What you wanna do is quite the same thing described in this articles.
I hope this helps!
Regards
Great question. You have several options available to you.
Have a jQuery call on your masterpage that grabs the data you need from a controller and then populate your fields using jQuery again.
Your second option is to create user controls that make their own calls to the controller to populate their information.
I think the best choice is creating controls for the region of your masterpage that has data that needs to be populated. Thus leaving your masterpage to strictly contain design elements. Good luck.
If you don't mind strongly typed view data, you can put all the master page data in a common base class for viewData. You can set this data in the base class's constructor. All your views requiring additional data will then need strongly typed viewdata that inherits from this base class.
To allow a call to View() in your controllers without any explicit viewdata you can override View in your ControllerBase:
protected override ViewResult View(string viewName, string masterName, object model)
{
if (model == null)
{
model = new ViewDataBase();
}
return base.View(viewName, masterName, model);
}

Resources