First, I apologize if this is a dumb question, but I'm new to MVC and am trying to get up to speed as quickly as possible. I have spent hours searching for answers and even went and bought a book on MVC 4, but it still didn't answer my question.
I have a form I'd like a user to fill out to add a new product to the catalog. They choose the category, enter the name, a description, etc.. On the same page I'd like them to be able to add sizes or product options such as Small, Medium, Large, etc.. The problem is I'm not sure how to go about this.
I need to temporarily store the size options for example in some sort of collection until the user actually 'saves' the product, then I need to be able to read the collection. What I'm trying to avoid is to have the user add the basic product info, then save it, then select it, then choose to add options to it. I'm trying to just do it all on one form. Any help would be greatly appreciated!
There is nothing preventing you creating a view model with its own collections for the detail items and have those mapped to some sort of javascript control for selecting multiple items such as one that writes to an mvc hidden form control.
The controller handling the postback will simply create the master model from the postback data (the updated view model) and then create the child records. The whole thing could be achieved with ajax calling a controller action that returns a partial view of the updated ui.
Similar to this but have the list as a property of the master model
http://www.stevefenton.co.uk/Content/Blog/Date/201002/Blog/How-To-Handle-Multiple-Select-Lists-In-ASP-NET-MVC/
A little more advanced on how to manage your own bindings http://www.dotnetcurry.com/ShowArticle.aspx?ID=584
Sounds like u need to roll your sleeves up and get a control written in javascript that allows child items to be added client side whist serializing e.g. Into json when they save and saving it to an mvc hidden control ready for postback. Use json.net to hydrate these values into your pocos. http://erraticdev.blogspot.co.uk/2010/12/sending-complex-json-objects-to-aspnet.html
Related
yeah the question is: can mcv display on the details and index form the text data values vs just ID value that gets stored in the database .
It seems that mvc is very limited in what it can display to the screen. All of the demos and tutorials seem to stop short of showing this is a possibility most just show the user typing in the the full text value. So for example the user has a user interface form that has a list of values drop down element. THey click the value and the ID gets stored to the database.
Later on recall the user wants to pull the data back up for review... in mvc it seems you are stuck with displaying the ID field in the textbox.
but in most other systems you can make a datatable and return the text value of the field back to the form... Is this possible with MVC or are you limited to saving the full text value to the the database?
enter image description here
enter image description here
yeah the answer is: Make a view in SQL Server and then Link that View to the application via the EDMX. Details below.
Finally! I was able to figure out and I will post the solution so that it may help some one get around the mvc / normalized database limitation that seems to exist when you try to follow some of the tutorials.
The key is to build a SQL view outside of MVC. This can then be linked to the application and it will appear to be a table.
So if you use the database first method and you are using SQL server you will need to simply make a view in SQL server. This take mvcs out of the picture all and is much easier.
Step 1: Make a SQL view... that has everything you need joined in one big super view for what you need to display.
So in my case I made a sql server view that has the storage table linked to the support tables. Think of the query builder in MS Access where you link your tables to make a query.
You draw out your tables and links.
Add that to your Database First EDMX and in your controller use that new super view... and in your index and details forms you change the #model to your new super sql view and change the field name in the textboxfor... Boom problem solved... pretty swell how it all works... in this way you don't have to build some complicated view model. You just take the class that the wizard builds and then make a partial class to rename fields to give them user friendly names.
And you are no longer limited by mvc limitations
hope this helps!
On Telerik demo site we can see an example of how to implement kind of functionality: "check all checkbox in a grid's column". But in my case it has 2 disadvantages:
It didn't check all checkbox on all pages.
It didn't save a state of checkboxes on different pages.
Is anybody know how to resolve these issues? Thanks in advance.
As long as I know there's no built-in functionality to do so. The same problem happens when you select records on page one and change to page two, you loose whatever you selected before.
To achieve that functionality you have 2 options (I've used both on previous projects)
1) On each check make an Ajax call to one of your controllers and store whatever you selected on a Session Variable (This can be inefficient if you have a lot of records)
2) Create a javascript variable and store your selections there, and send back to the controller using a json variable or a comma separated values string
As I said, I've used both approachs so it depends on if this works for you or not
Hope it helps
I can't test this, so I'm not 100% sure, but looking at Telerik's example, one reason it's not persisted is because every "page" of the grid requires a postback, and in the controller action result method, they aren't passing in the model (or view model) for the items that are bound to the grid, they're only returning that list of items back to the view, so it will never "save" which items are checked/selected and which ones aren't. You should be able to get around this by making your view model a parameter into the HttpPost action result method and then passing that list back to the view after the post so that it retains which items are selected instead of creating a new one. This won't solve the issue with not selecting all the items, but it should at least retain which ones are selected throughout the pages. I think the reason for it not working with all items is it can only select the ones that are actually being displayed at the time. You may want to do a post (or ajax) to select "all" items.
One of the major reasons for using paging in grids is so that you don't have to retrieve all of the data from the data store and generate a lot of HTML to push to the client.
It's been my experience that most users understand that a "select all" check box only checks the items on the current page. I've not seen a site where checking such a check box would actually check all records, even those I can't see.
If you have an action which will affect more than the current page of records, I would suggest that you add a button which clearly indicates that the action will affect all records, then send a command to your data layer which will perform that action. This will perform better (you don't have to send a potentially long list of ids across the wire) and allow users to understand the repercussions of their action.
In my web application framework (currently WebForms) I have a control that behaves like a classic propertygrid. It is initialized with an object ID (database key), then it reads metadata to determine the type of the object and the attributes of the object. It displays the attributes, string attributes as textboxes, bool attributes as checkboxes, enum attributes as dropdown lists. On page submit there is a method of the control ctrl.SaveData() that saved the changed attribute values back to the database.
The WebForm control tree and event model supports this approach quite nicely. Now I am asking myself if it is possible to achieve a similar solution for ASP.NET MVC. The main objective is to have a generic, reusable component that can be applied in a variety of situations with not much hassle. Additionally the solution must be flexible enough to put multiple instances of the component for multiple objects on a single page. Here the auto-generated WebForms HTML IDs also helped.
I am very curious about your ideas! Thanks a lot for answering!
You could achieve this effect using a custom ViewModel that contains enough metadata to identify the object being edited/saved. You would use this in conjunction with a partial view that renders the ViewModel. The main page would use the metadata in the ViewModel to either direct the post to a specific controller action to save that particular object or pass the metadata back to a common action (as hidden inputs, perhaps) in order that that action can choose the proper table in which to persist the data.
Personally, I would not take this approach. My feeling is that the more general you make a view/action, the more work it becomes to adapt it for different circumstances. I have done similar things for viewing sets of objects, but for a detail view or editing I like to work with more specific models and views.
The contents of my MVCContrib grid come from the Model on a strongly typed View. When a post is made, the contents of the grid are not in the model object when it returns to the controller. I can see that this is because the grid renders as just a table with text in cells. Is there something I can do so that when the post occurs, the list data I sent down to the grid comes back in the post?
You can use TempData to persist this information server side. The information in TempData will persist for one request. I do not really like this option however.
Can you not repopulate your model from the db? If the user is not changing the information why do you need to post back all the same unchanged information? Just grab it again from where you got it before.
If you want to recreate the model as it was serialised into the grid, you will have to embed correctly named form elements within the grid ( or maybe outside the grid ) and within the same form as the one containing the button that is posting back to the action where you want your Model recreated.
While this is doable, you are essentially recreating __VIEWSTATE, and that defeats much of the joy of working with MVC ( read "it's an ugly hack and you should uninstall your IDE for even thinking it").
It is hard to point you in the right direction without having a better understanding of the scenario you are trying to solve. The usual workflow in these situations is
get the model
generate the page
record any changes to the model in a
form on the page
submit the changes to an action
get the model again
use TryUpdate to persist the changes
from the post into the model
If you are suffering performance issues ( you have proved you've got a perf problem right? You aren't optimising prematurely?), address them where they occur ( i.e. caching in your data access ), rather than bending MVC in ways it really shouldn't be.
Ok, so this is an alternative to this question.
I'm trying to produce an MVC application using LinqToSql that allows for bulk editing of data on a single page.
Imagine a simple table Item with ItemId, ItemName, ItemPrice as fields.
There are many examples out there of extrmely simple MVC applications that show you a list of these items with an edit button next to each and an add button at the bottom.
From a UI perspective I find this very time consuming when a lot of data needs entering / updating.
I'm after a single page containing the items names and prices in textboxes that can all be edited in one go and then a single "Save" button pressed to update the data.
I've seen a number of examples that perform various stages of this but have yet to find one that implements the full solution. In particular the interaction with Linq.
I have a number of methods I've tried which all work, however, my gut feeling tells me my methods "smell" and therefore I'd like to see some examples of how other people have attempted this.
So, put simply, my question is can anyone provide some links to some examples please?
I have written about how to do this with MvcContrib's FluentHtml. Steve Sanderson has written about how to do it without FluentHtml. Both of our articles have a sample solution you can download and look at.
As far as LinqToSql, I would consider any interaction between bulk editing mechanism (controller and view) and LinqToSql to be a smell. That is to say, as far as possible your UI should be ignorant of your persistence mechanism.
What I would probably do to get around this is use jQuery to call a jsonResult when you switch rows. This jsonResult would call the code in the model to save the ItemId, ItemName, ItemPrice for only the row you are switching off of. More on general jsonResult w/ jQuery usage here : http://www.dev102.com/2008/08/19/jquery-and-the-aspnet-mvc-framework/
The other thing you could do is do model binding to a list of Items, iterating thru the list saving each item -- Phil Haack has an example of list binding here: http://haacked.com/archive/2008/10/23/model-binding-to-a-list.aspx With either method you'll want to do something to signify the row has changed so you're not updating every field if you're just changing a handful of rows.
What is your goal exactly, are you trying to commit a series of information all at once? Or do you simply not want your page to postback every time you change something. In either case jQuery is your best bet. If you want to do everything in one pass it is going to get complex unless you use a jQuery control that will do this for you. There are some great ones out there such as the Flexigrid.