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
Related
I have a User model with some validations behind it.
What I'd like to do is have a signup form on every page of the app, even the mostly static ones.
I figured the best way to do this would be through helper methods in application_helpers.rb, which works fine, but validations don't seem to work.
I can also serve the form through an iframe, but that seems a bit hacky.
I'm using partials now, but my client side validation (github.com/bcardarella/client_side_validations) only works on the /new page, not the application page.
What's the best practice in this case?
I would recommend extracting the signup form into a shared partial, which you then explicitly could render wherever you want it.
One could render the signup form directly in the layout file (app/views/layout/application.html.erb) if the placement is static no matter of what page you're currently on.
One of the basic solutions is to use partial. The benefit is: it's built in, it's simple. The downside is: You'll be busy to feed it some session details for proper rendering.
Another solution is to use Cells for this kind of case.
Cells works like a lightweight controller which can do anything a controller can do, and it's independent on any controller. One good use case of Cells is shopping cart, and login form is also a good use case in my opinion.
This more of an out of interest question than an urgently need an answer one, but I have been trying to find a good example of how to deal with a full postback from a partial view in asp.net MVC. The obvious example is the case where you have a small login form on every page. You can easily accomplish this through an asynchronous post back using jquery, but I am wondering if there is a way to do it without the use of javascript. I know it may be pedantic, but I don't like the idea of assuming the client has javascript enabled, particularly in this day and age where responsive design/ progressive enhacements are the big buzzwords around, so having you log in tied to javascript means that anyone on a simple mobile device won't be able to use it since their device probably won't support it.
Anyone have any ideas / examples of how to accomplish this? It's such a simple thing to implement in web forms I can't believe it's as tricky as I've heard it made out to be in MVC.
You just need a form within the view, that's all. The form will POST to its controller action method and generate a full page refresh (if that's what you mean by a full postback - I guess it is) irrespective of whether its a partial or not.
You can have multiple forms on a MVC view, and each one of them will give you a full page refresh, whereas with WebForms the pattern was one main form per page.
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
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]