I am new to MVC and learning some stuff of views, partial views etc.
I would like to make a simple page where lets consider "Login" and "Register" both comes together.
Like facebook.
I have found all the examples which is all having one view on page. I guess, to make a big view (complete page) we need to have partical views to use in one big view.
unfortunately, i am not able to find perfect example, may be lake of searching power or exact term to use for MVC.
I want to make a page where many partial views use in one big view and create a big page.
Can any one please help me to get video link or help link which can be useful and how exactly it works?
Check out the partial views in
http://www.pluralsight-training.net/microsoft/players/PSODPlayer?author=scott-allen&name=mvc3-building-views&mode=live&clip=0&course=aspdotnet-mvc3-intro
Using #Html.Partial is fairly easy, I generally prefer #Html.Action to render another controllers action method in line, and it makes more sense for me in a situation like you mentioned above.
Something else to consider are the ajax type dialogs for login, now in the mvc4 developer preview templates at: http://www.asp.net/mvc/mvc4
Related
Currently i am investigating if MVC is the way to go for the new major version of our web application. We have an existing web application with webparts, dynamically rendered according to some user settings. Each webpart has its own data and own logic (for example, one webpart with user information, one webpart with currently logged-in users, one webpart with appointments etc. etc.).
What we need to accomplish (i think) is to render a single view, which contains several partial views. Each partial view represents a different model, and has its own logic.
I figured out how to put multiple partial views within a single view, but i don't know how to handle the business logic for each view (in "partial controllers"? if possible at al?), and handle the model for each view?
So the main purpose is to render a page with multiple dynamic views (according to what the user has configured), each with its own logic and data. And then when, for example, a button is clicked in a partial view, the corresponding controller is called to handle the event, and returns the updated partial view. The partial views need to be loosely coupled, and updated async.
From what i've seen so far the most tutorials and documentation are focussing on MVC in general, not on how to separete the business logic and model for eachr partial view.
So I'm not asking how to do this, but:
Is it possible to easy accomplish this with MVC 4 or 5?
Does anybody know a good real-life example or tutorial about this?
I hope anyone can point me in the right direction or share some thoughts on this...
You could make one or more controllers with an action for each webpart.
Group all related webparts in the same controller but make an action and View+ViewModel for each webpart. Then use the Html.RenderAction method to call these actions (and have your webparts placed) on your page/main view.
DISCLAIMER: This said, each call to Html.RenderAction creates a complete mvc flow, instanciating a controller, model and view and finally renders the whole thing and passes the value to your page/main view. Having lots of Html.RenderAction has the potential to slow your page creation a lot. You could look into DI/IoC like Unity and consider reusing controllers, or just look into System.Web.Mvc.DependencyResolver to handle the creation of controllers yourself.
I'm very much a web forms man and am coming over to mvc using mvc 4.
Am I missing something or is the norm with a thank you or response page to create a separate view and direct off to that.
So for instance if a user fills in a contact us form, clicks submit, the user then needs to see a thank you message on the page.
This would be done using the same web form but am i right in thinking i should create a new view?
If this is the case doesn't a site soon fill up with a LOT of very simple views?
If you are referring to PRG pattern, then the answer is yes, preferred way is to redirect user to the separate action which will in turn return a "Thank you" view.
However, nothing stops you from creating such an action that will for example bind to your specific model and according to that decide in your view what to render.
That way, you shouldn't and up with many "Thank you" views.
EDIT:
ASP.NET MVC technology itself is a set of best practices and conventions. There is nothing to stop you to use it the 'wrong' way.
But what exactly would be wrong way here?
using a lot of small views could reduce the mess and give you some flexibility; imagine the situation where suddenly you have to change each of "Thank you" views in the way to tell the user something about the action completed and to point him toward the next one
using some view-related logic in template can in extreme cases reduce all of those "Thank you" views to few or just one; in the other hand you could end up with a big and ugly Razor template
using partial view could help you with the first problem, but then you have to be careful where you put your partals - you want to reduce mess, not generate more
using helpers in views could be helpful to encapsulate a small parts of the view that repeats throughout multiple views
How do I create a view in ASP.Net MVC 3 that defers creation/rendering of a portion of the view to another view/controller, without knowing at design time what view/controller will be deferred to?
I have a Dashboard view/controller that uses a Layout page. the dashboard view does most of the work of rendering the overall screen. However a certain placeholder section of the overall screen will differ based on business rules, configuration, user interaction etc. There are three separate plugin views/controllers that may need to be rendered in the placeholder section. How do I instruct the Dashboard view to render a specific plugin view once the Dashboard controller has determined which plugin should be visible. I have accomplished this already by putting flags in the Dashboard model and then having conditional logic in the Dashboard view call Html.RenderAction with the appropriate parameters based on the flags. This seems unsatisfactory and I would assume there is already a simple built in functionality for this kind of scenario, please advise.
Thank you
You are really asking "how do I dynamically render partial views who's identity is known at design time."
One can get there two ways, either through Html.RenderPartial or Html.RenderAction. And both have their place. If the main page "knows" enough to have the view data, then RenderPartial is your the better bet as it is a bit more efficient than RenderAction. If you only know, say, a unique identifier for your portal widget than RenderAction works because you've now got a fully capable controller method that can do things like go back to a database and render a view.
You could write your own htmlhelper and use that in your view instead of using the flags.
I am currently considering the best way of building a relatively complex page in asp.net mvc. The page (and pages like it) will contain numerous 'controls' such as a shopping basket, recent news widget, login controls and more. In other words, it will be very component based.
My question is, what is the best way of building something like this in asp.net MVC? In regular webforms the answer would be simple thanks to user controls and the fact they can be nicely self contained. In MVC, I understand that in theory I should probably build a viewmodel that includes all the data needed for all my widgets and then render partial views in whatever page I'm building.
Could an alternative approach be to use javascript to load widgets 'dynamically' (think jQuery load) by simply calling into controllers that render partial views. That way I could have a basket controller, which when called renders out a basket. Of course, this relies on javascript....
Whats the best practise for situations like this?
Thanks
You could of course use JavaScript to populate the page sections but then this content will not be accessible to search engines (but that probably does not concern you).
What you need to understand that there is currently no way to make these partial views perform independently. Like talking to their own controller and posting data while having the rest of the stay unchanged (like it could have been done with WebForms and user controls). If you think postbacks and control state these things do not exist any longer. Your "control" makes a post, the controller has to process the request and then recreate the complete view along with all element values, states and other "user controls".
Unless you do it asynchronously with JavaScript of course. But then it's not gonna be an accessible page any more.
You can try SubControllers from MvcContrib or Steve Sanderson`s "Partial Request" approach.
But i warn you - communication between (partial requests, i haven't tried subcontrollers myself) them might get tricky and lead to mega failure. Use them only if you are completely sure that they are completely independent.
Anyway - that's a bad idea and should be avoided through controller/viewmodel inheritance or something....
My understanding of MVC is not yet up with WebForms, however is the generally accepted approach for stuff like this to simply throw these things in the ViewBag rather than include them in the ViewModel?
You could send down a main view model with some simple checks on it. Then render the appropriate Action if required. Then each partial could use it's own viewmodel and you wouldn't need to send everything down initially on the same viewmodel.
Razor:
#if (model.ShowShoppingCart)
{
#Html.Action("Index","ShoppingCart")
}
#if (model.blah)
{
#Html.Action("Index","blah")
}
I really like the way ASP.NET MVC works. I'd love to implement it on all new web projects moving forward, but I hit a snag in a prototype the other day that I really haven't found a good solution for, so I ask you, how would you design an MVC app that doesn't fit the typical REST pattern? As an example, the prototype I was designing would have several pages, but the pages themselves aren't necessarily bound to a domain model. For example, take a simple registration site, which might have the following pages:
/Default.aspx
/Register.aspx
/ThankYou.aspx
Occasionally, such a program might require an admin section to deal with such details as moderating sign ups or reviewing data. In a standard ASP.NET web app, I might add the following
/Admin/Default.aspx
/Admin/ListRegistrations.aspx
/Admin/ViewReports.aspx ...
Would it be an unacceptable deviation from the MVC pattern, in this case, to have two controllers such as:
Home->Index
Home->Register
Home->ThankYou
Admin->Index
Admin->ListRegistrations
Admin->Reports
My frustration with this is compounded by the fact that there is no real solid implementation of subcontrollers and areas yet. I'm aware of the "Areas" prototype put together by Phil Haack, but it's not very mature, and quite frankly, I'm not sure I like the way it's setup, but I don't really know how I'd like to see that work either.
I guess when I think MVC, I tend to think REST as well, and having controller actions that represent pages rather than actual entities or actions doesn't sit right with me. What do you think?
You can always mix ASP.NET Web Forms with MVC.
Just add
routes.IgnoreRoute("Pages/{*path}");
to your routing table and add traditional Web form pages to Pages folder of the application.
One mistake that newcomers to MVC make is to group actions into a controller for display reasons. In your case, instead of grouping the Register and ThankYou actions in with the homepage try separating them out into an AccountController as the MVC team has done in the sample project. You can use routing to set the Url's up however you want for the end-user.
As for your other actions, how about a ReportController? You could then additionally have an AdministrationController whose Index action/view contains links to various admin actions, including those on the ReportController.
Short Version: Group actions into a controller by function, not site navigation.
I usually ditch the "Home" controller as the first thing in a project and replace it with a "Page" controller. I use that one for anything that is "just" a page. Things like "FAQ", "Contact Us", etc. I do this at least partially because the default approach to the Home controller requires a new method being added every time you need even a basic, static page.
In that controller, I only have the one action: Display. That action gives all of those pages the same context object. I actually store the content for those pages in the database with a lookup "slug" and tie it into NVelocity templating, but even just static HTML or NVelocity templates in files would work too.
Anything else, like the others said, gets split into controllers by the "thing" being managed. So, a ReportController, User or AccountController, CartController, etc. Then the actions make much more sense.
When you're talking about listing the registered users, it's actually a list of users, so I'd have a UserController and do /User/Display/Registered/MostRecent or something similar. For the registration itself, /User/Register which would post to /User/SaveRegistration which could, in turn, redirect to /User/DisplayProfile/NewUserID or /Page/Display/Home from there.
You can have as many controllers as makes sense; that layout looks reasonable. Note that routes don't have to map directly to {controller}/{action}, but it keeps things simple. Looks fine to me - except I'd probably have ThankYou as a view - i.e. the Register [GET] perhaps uses a different view to Register [POST]