I'm trying to get all the data that is submitted into textboxes at a view back to a controller so i can save the data to the database.
Some background information:
Teacher Task Quotation setup
The first view that the teacher sees are all the tasks he has given (dropdown). He can chose one of those tasks and click submit then he gets a view back where he can quote the students that submitted there tasks before the deadline.
So for each student he can change the points if he made a mistake or quote the task.
After that is done there are some points that need to be submitted. What i want to know is how i get all those points back (that are in the textboxes) from the form so i can easily submit them to the DB.
Edit:
It seems that my question is kinda hard to understand so i made a little sketch of the current situation and the problem - you can view it here - http://i43.tinypic.com/xap54m.jpg
Possible problems: i allready use a viewmodel to require the submission of a task.
Is it possible to have to viewmodels in a view?
This is a really basic MVC question. You should probably read the MVC music store tutorial/pdf or the Nerd Dinner tutorial as both will show how to save/insert to the database using Entity framework.
I'llpost some code a little later.
Use another viewmodel. To use two viewmodels in one view, either bind them together in a model class or use a tuple in a view like this:
#model Tuple<model1, model2>
Then you access it like this.
Model.Item1.Something and Model.Item2.Something
Related
In cases where new items need to be added to a list via ajax, what is the biggest benefit of using something like Knockout.
So far what I have been doing is, on my view, use an editortemplate (with asscociated viewmodels) to render a list of items. Then to add a new item, I make a request to an action that loads a server-side viewmodel, and returns an EditorTemplte object which just gets appended to the list. Like this:
return Json(new { this.RenderPartialViewToString("MyEditorTemplate", model) });
The knockout way of doing things requires the implementation of another view model to display items, and then another template to display it. But doing it this way requires duplication of code since the view model has to be represented in 2 places: in the cserver side code and then the view for the knockout viewmodel. Isn't that bad practice?
Am I missing something, or understanding the purpose of knockout and MVVM?
The biggest benefit that you will see from Knockout is that you will not need to hit the server in order to add a new item to your list - everything happens client side. This has multiple benefits including:
You reduce load on your server.
You improve the end-user's experience.
You can keep multiple elements on the page up-to-date with your model without any server interactions.
Two great examples of this can be found at these Knockout tutorials:
Working with Lists and Collections
Loading and Saving Data
As far as duplicating code, if you take a look at those two tutorials, you'll notice that you don't need to duplicate code. For example:
Create a view to display your entire list.
To add a new item to the list, create a partial view that you load when you add a new item to the page - that partial view is bound to Knockout
When you submit the entire form, everything in that list will be submitted - including those items you added via Knockout.
Your ViewModel will be specific to your list item (you don't need to create an entire ViewModel for everything, necessarily). And your view is specific to a single list item.
Hope that's clear. Knockout is pretty straightforward and they have some great documentation and tutorials to help you move forward.
IMHO, the following is cleanest option for the architecture of knockout and asp mvc mixed together.
Have your ASP.net acting as a webservice and have knockout control all your view templating and logic.
Otherwise, yes there will be potential replication of viewmodels and having to refactor both front and backend code when you need to change your model.
I am buiding a UI screen for editing the details of an Ecommerce Order. The model for my view (OrderModel) has everything I need (in properties that are also ViewModels), but the UI isn't designed to be able to edit all of it at once.
For example, one part of the UI is for customer data..another for order details, and another for tracking information, each having their own "Save" buttons.
I realize that I could use one giant form and use hidden form fields to populate the non-editable fields, making each "Save" button post all the data, but that smells bad.
I'd like to segment the editable chunks into smaller ViewModels that are posted and validated individually while retaining the strong typing but I'm unsure of how to achieve this in MVC3. Will I need partial views that are called from the primary view?
FYI, I'm using ASP.NET MVC 3 with Razor syntax and client side FluentValidation.
Partial Views are a good solution. You can pass different ViewModels to each partial view. But if only sections of the overall view are updated at a time I would not do a post back on the whole page. Instead I would use Ajax calls using JQuery/Javascript to update the individual information back to the controller. I would also look into something like Knockout.js to handle the data binding on the page.
I am writing a Grails app and I have a quick question about the best way to do something. My controller has 2 lists of data, both of which are displayed on the view in separate HTML tables. What I want to do is to have a button that will allow you to move an item from one list to the other. What is the best way to do this?
I have done some research and using some form of AJAX seems to be the general consensus on the best way to do this. Is there any other way? The heart of the problem is that I can't figure out how to update the data contained in the contoller based on the button the user presses in the view.
Thanks
I solved this by just updating the model to reflect the new lists and rerendering the page
I think I'm finally starting to get MVC 3, but if someone can validate this approach I'd feel better about it.
I have a website, let's say, and I have models for NormalPage and EventPage. EventPage has an EventDate, but that's the only difference, and let's just say that EventPage inherits from NormalPage if that makes life easier.
Two views handle these two (slightly) different models, one just showing the page, and the other displaying the date and showing a registration form. They have different designs, so different views are in order.
All the tutorials will say "yup, now write two Controllers: Events and Pages". That seems silly - both are just passing the model to a (appropriate) view. I can use a single "Page" controller and choose the appropriate view using reflection, right? typeof(Model), once I've pulled the data from the database, can tell me whether or not I should pull the Event view or the Page view.
Is that dumb, or asking for trouble, or misusing the framework? Thanks.
What do you intend to do with reflection? You don't need to do anything like that to return views dynamically. From any controller action, you can return View("EventView", eventModel) or View("NormalView", normalModel) and it will return that view.
On a different note, I'm not sure what tutorials suggested that it's typical to have one view per controller but it's not. It's typical to have several views and actions in one controller.
I'm developing an app which has a large amount of related form data to be handled. I'm using a MVC structure and all of the related data is represented in my models, along with the handling of data validation from form submissions. I'm looking for some advice on a good way to approach laying out my controllers - basically I will have a huge form which will be broken down into manageable categories (similar to a credit card app) where the user progresses through each stage/category filling out the answers. All of these form categories are related to the main relation/object, but not to each other.
Does it make more sense to have each subform/category as a method in the main controller class (which will make that one controller fairly massive), or would it be better to break each category into a subclass of the main controller? It may be just for neatness that the second approach is better, but I'm struggling to see much of a difference between either creating a new method for each category (which communicates with the model and outputs errors/success) or creating a new controller to handle the same functionality.
Thanks in advance for any guidance!
My preference would be to create triplet Form-Controller-Model for every form displayed to the user. Whenever user clicks on 'Next' button on a form its controller should talk to the back end manager which takes care of dispatching submit request to the next form in chain. Vice verse if 'Back' button is clicked. Last form has a 'Finish' button which will go to the manager and pass the last bits of information.
This will avoid inheritance, make your code more robust and testing of forms possible in isolation.
My preference would be to keep it all in one controller. It keeps all the relevant processes for filling out the application/form in one place, although I'm not sure how "massive" you're talking about. If you do decide to split it out, I would not subclass off of the main controller, but just make a handful of independent controllers, perhaps related by name for ease of use down the road.