I scaffolded a new MVC controller, along with a corresponding view and repository for an IEnumerable collection of a POCO class. In the resulting view is a table that will list every entry in the collection of that class. However, the table also contains a column for every property in that class, and I only want to display a subset of them in this view. Is it a bad idea if I now manually edit the view to remove what I don't want to display in the generated HTML?
I'm not clear on whether the scaffolding features that are part of ASP.NET MVC (version 3 and later) are designed to generate the basic functionality for your web application, giving you the freedom to do what you want with the results afterwards, or if it's considered a best practice to leave the generated results alone and find another way to do what I want to accomplish. I know that you can customize your own scaffolding templates, but that seems like a lot of work for such a simple change.
Thanks!
It's definitely OK to edit the scaffolded view. This is just a feature that's there to quickly build the basics, but that will never suffice.
So you can just edit it all you want. Keep in mind though that if you edit your model, you will have to manipulate your view manually, but that's normal I think.
Scaffold will HELP you to generate a View strongly typed to a Model. Of course, if you want, you can update the html in your views. Another good tip: Instead of using your Model, create a ViewModel based on this Model, and put only the properties you need to display in the View.
View this content:
https://stackoverflow.com/a/11064362/1384539
Related
In the app I'm working on the administrator has the ability to select a customer to work with in a drop down list. Thing is that there are a large number of views that the administrator can go through and each time they'd have to select the customer again. In webforms this was rather easy... store it in a Session variable and reset it when another page loads.
MVC not so much. I seem to be stuck at the point where I pass this value to the view from the controller. We are storing the value in a Session variable which we access using a base controller like this:
MyController.CurrentUser.CurrentCustomerId
The question I can't solve is how I pass this value to a partial view. The customer selector tool is in a partial view which is added to pages that need it.
I thought of using the ViewBag, but that means that in every single action in my controllers that requires this value I would have to add:
ViewBag.CurrentCustomerId = CurrentUser.CurrentCustomerId;
And even then I'm not sure if the ViewBag data is carried through to the partial view. I think it is.
Seems like there should be a more efficient way to do this and still abide by MVC rules?
#Andre Calil provided a very good solution for carrying user information between controllers and views and I ended up using this approach.
See his answer at the following link: Razor MVC, where to put global variables that's accessible across master page, partiview and view?
I am new to MVC and I'm having some teething trouble. I'm working on a project where I have a couple of tables - Firm and User. Each Firm can have multiple Users. I have created a registration View which effectively merges the fields of both into a single View. I also have a separate View for editing Users, and another for creating Users within an existing Firm. It makes sense to me to use a partial View so I only need to update the UI in one place. However, I am hitting a bit of a problem. When I use the partial in Create/Edit, it works fine as I just use it as
#Html.Partial("UserDetails",Model)
However, when I use it within Register, I try to do
#Html.Partial("UserDetails",Model.AutoFirstUser)
AutoFirstUser is a property that I created that automatically creates a user if none exists, otherwise it just returns the first user in the firm. This seemed like the easiest way to merge the data into a single View. Thinking about it now, I realise that I could just use User as the model and use User.Firm for the other fields, but that would just shift the problem to the FirmDetails Partial View instead.
Anyway, the problem that I am finding is that although the fields for the user are visible and validate properly, when I post the form back, they are not finding their way back into the model, presumably because the models are effectively in different "namespaces" as the Partial View expects the main Model to be a User and the Register View expects it to be a Firm.
It appears that Partials were not what I wanted - I have solved this with Editor Templates
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'm familiar with the various bits of functionality of the MVC plugin to create things. For example you can create a controller, write an Action method on it, then use the "create view" function in the context menu to create a view for it.
The question is, which is it recommended to do first?
I'm thinking I might start myself a methodology like this:
Plan out what the UI etc will look like and how it will work.
Write unit tests for the controller actions I think I might need.
Create Controller (maybe with default CRUD actions if it's to be that kind of controller).
Create ViewModel class for each controller action.
Create a strongly-typed view for each ViewModel.
Start building the view, working back through the ViewModel to the Controller as the View is built up.
What do you think of this approach, and what do you do?
Sounds like you're on the right track. Controllers are the most easily tested component of the three. Going controller-first will make it easier to follow Test-Driven Development practices.
I've not been perfectly happy with the default view templates, but every MVC guru will point you to T4 templates, which let you roll your own. They, like the out-of-the-box view templates, will be more effective with existing view models and controllers.
I'd be tempted to define the ViewModel first, the VM(s) can consist of all or a subset of the entities required for the various Views. How you segregate your VMs would depend on your app and how you are breaking up logical units within that.
Once I had the VM(s) in a basic form I would move to Model necessary for my chosen data store (unless I had an existing data store in which case I'd have started with the Model). Then onto the controllers. You can then apply TDD with a mocked data source to verify that the VM objects returned by the controller actions match expectations. Lastly, I'd generate basic strongly typed Views (based on the ViewModel objects) for each controller action that actually resulted in UI.
Then it's play time with Jquery and CSS to make it look presentable.
I read the Pro .Net Asp.net MCV book over the weekend and it provides some good examples on setting it up and using it. However my question is what is the structure of an MVC project should be. I ran into problems once I started trying to transfer control from one controller to another. It seems that you can have multiple views within one controller. Also when you execute the Redirect("Action", "Controller") command it seems that the routing wants to look for the view within a sub of that controller. So my questions are:
Is there rule of thumb of 1 controller to 1 view?
Should you call another controller from a controller?
What is the proper way to transfer control from one controller to another?
You can have as many views/partial views per controller. The rule of thumb as far as one can deduce it from the MVC samples is, that a controller encapsulates a set of functionality that belongs together, e.g. listing products and creating, updating, deleting as single product.
You can use Html.ActionLink to route from one view to another. To call one controller from another, IMHO, makes only sense for partial views - however that depends on the problem.
Html.ActionLink or Html.RouteLink.