One view having multiple button in asp.net mvc - asp.net-mvc

I am not able to understand the flow on this page
how they are doing in MVC http://demo.nopcommerce.com/onepagecheckout
till now i created only one button for one page (view ) or provide me some similar link or similar code so i can understand
i want to implement same in my application
Thanks in Advance

The page is using AJAX to achieve the effect. Let's go through how it works.
The page is divided up into four sections.
Billing Address
Payment Method
Payment Information
Confirm Order
Each section is treated separately and are likely rendered using partial views. Each section has it's own form. When the user fills out a section and then submits that section, the form is submitted to a particular action. The Billing Address section submits its form to /checkout/OpcSaveBilling, the Payment Method section submits its form to /checkout/OpcSavePaymentMethod and so on.
When these forms are submitted (asynchronously, remember), the server handles the business logic and the validation and returns a result in the form of JSON. The JSON describes what happened, i.e. the result of the validation (success or fail), any errors that occurred and also contains HTML that the page can use to redisplay that particular section.
How is this data being remembered? Sessions. When forms are successful in their submission, the form data is stored per user in the session data. This way the system knows each user's settings and also knows where they are up to in the process.
The final step, Confirm Order, doesn't bother sending any form data because the server already knows everything through the session information.

Related

Best practice/design for a multi-page form in .NET MVC3

I am working on a web application that involves the user filling out a multi-step form that spans several pages. The form has tabbed navigation across the top (these links do not submit the current page) and a next button at the bottom (which does submit). I am considering several strategies for handling form submission/validation:
one action method and view per form page. When you hit next, it submits the form to the action method for the next page. If there are validation errors, you are redirected back to the previous page:
URL's are descriptive and can be copy-pasted
Only redirects in the error case
Since the redirect does not have the form data, we lose context about the submission which makes it hard to display certain error messages
The same validation logic works for redirecting the user if they try to visit a step in the flow that they aren't ready for yet
one action method and view per form page. When you hit next, it submits the form to the current page action. If there are validation errors, the same view is returned. Otherwise, we redirect to the next page action:
URL's are descriptive and can be copy-pasted
Redirects are very common (not sure if this is bad)
When displaying validation errors, we are in the same request as the form submission so we have full access to the invalid input
Have to pass additional context if we want the ability to, for example, add a "Previous" button which also submits
one action method for ALL pages. URL's contain additional context about the step being submitted (e.g. MyController/MyAction/{step}). The controller message selects which view page to return depending on validation and the current step.
URL's are not descriptive (e. g. if I submit step 1 to go to step 2, then the URL the user sees will be the same regardless of whether page 1 (invalid) or page 2 is returned
No redirects
When displaying validation errors, we are in the same request as the form submission so we have full access to the invalid input
A different method I haven't listed here
I have tried to enumerate what I see as some of the pros and cons of each method, but I would be interested to know:
What are other pros and cons of these methods? Are mine correct? Could some of the cons I've listed be designed around?
Is there a standard approach to this problem which I should be using? If so, why is it the standard approach?
I would highly recommend option 2 with a minor modification. You may want to think about also creating one view model per action/view as well. If you have one model that spans all the pages, validation will occur across ALL properties, meaning that even though the user can only edit part of the model on each screen, they could get validation warnings for properties they can't see. We did this recently in a project and it worked beautifully. You have to do some data manipulation in the back-end to combine everything back together, but it was worth it in the end.
As you said, your URLs would be deep-linkable, which means users can Copy/Paste, and more importantly, they can add the page as a favorite in their browser, allowing them to come back to the same place very easily. In my opinion this makes option 3 obsolete.
You will also benefit from the fact that all of your logic for navigation is occurring in one place. You'll have to store the state of the "wizard" on the client (which page you're currently on) so that your controller knows what to do on submit. You'll want to analyze the state of the wizard and make a decision for where the user needs to go next. If you go with option 1, you won't know where you "came from" and server-validation errors will be difficult to display to the client. This is a beautiful example of the POST - REDIRECT - GET pattern. Each page would have 2 actions, a GET that takes simple ids, and a POST which takes more complex models. Post the server, figure out where to go next, redirect to a GET.
Lastly, consider your previous button simply linking directly to the previous step, instead of submitting the form. Otherwise, the user could potentially get stuck on an invalid step. This happened to us and again, worked very nicely.
Hopefully this was helpful. Good luck!

How to persist a model across multiple requests in ASP.NET MVC 2

I'm building a web application that has a particular model representing some events. Users need to be able to add N number of people to a given event. Choosing people is handled by a partial view.
I'm trying to build a menu that displays when users click "add a person" to the event. Because the event hasn't been filled out completely yet, there is nothing in the database to persist between requests.
I also have validation logic on the event page.
My proposed solution is to add the form to search or add for people on the event form itself and have a submit button that sends the values that have been added back to the server, where I can store them in ViewData or Session.
Unfortunately, doing this flags the validation.
My second solution is to load a partial view responsible for loading the UI to add/search for a person. I could add a little code on the method in the controller that returns a partial view storing the existing data in a session variable or viewdata. Trouble is, I have to submit the form to do it--again tripping the validation!!!
I'm wondering if perhaps I chose the wrong tool to do this...because in webforms, there would probably be a postback and you would just perform an operation on that postback. I'd like to avoid rewriting the application in webforms and am wondering if there are ways I'm overlooking in ASP.NET MVC.
Thanks in advance for the ideas!
I would probably have the partial view send it's data to the main page (with javascript). That way there is only one post to the server and it is when all of the data the user needs to enter has been filled out. How are you displaying the partial view? Is it on the main page (in a div), or is it a separate pop-up window? Either way, you should be able to use javascript to store this data on the main page and post all of the data back at one time.
HTH

data submission during form submission

i have a form which has two textboxes and a submit button.
on entering data and submitting data gets stored in the database.but if i again refresh the page the same data again gets stored.
How should this be prevented?
One way to solve this common problem is to redirect to another ActionResult, where you inform of the success/failure of the form submission.
Also, try to submit a ViewModel instance (see strongly typed views), not form values. That simplifies data validation.
You should implement a PRG redirect to a confirmation / thank you page.

Rails: GoogleDocs-Style Autosave

I'm trying to build a Rails app in which you can edit the same model from several different locations on the page. I want changes to be saved automatically every X seconds, with an option of manually triggering a save.
I have come up with a solution, but it seems very complicated, and I assume other Rails users have already faced similar questions.
The solution I came up with, is to have a hidden form on my page that is the one actually submitted, and then have multiple "dummy" forms scattered around the page that update the hidden form.
Once submitted, the hidden form updates the model, and the model contains logic to determine which RJS files should be returned in response. These are bundled up and sent as an update response.
some limitations:
Can't wrap the whole page in one form tag (there are multiple models/controllers on the page)
The same field might be editable from multiple locations
Anyone have a more efficient way?
create as much form as you need in your page even of the same instance of the same model
triggering the update would be either a javascript setInterval call, or onblur on your form fields.
your controller should be a REST one, and it will return success or error messages in json variables and a HTTP status (200, 422)
Forget rjs, think client side. Each form in your page will be submitting the form to the update method of your controller. The javascript submitting the form will have a error or success callback which will then show the success or error messages. The idea is that the javascript sending the form "knows" which form it is currently submitting, and it should be able to show error or success by itself dependending of the form it is submitting, it's not the controller job.
Saving the whole page is just serializing all the fields from all the forms and sending it to the update method. (see serialize)

Parameters through postback

I'm working with Ruby on rails 2.3.4 and I'd like to pass some parameters from one page to another ones the first one is submitted.
For example:
On the first page, I have a form that when it's filled a Preview button can be clicked to check all the info entered before submitting the form. That button redirects to another page with the info entered before, but I don't know how to get it in the second page.
There are two possible solutions:
You can emulate the stepped form filling by creating a record in first form and saving it with status "unverified" or "pending". This way you won't have to deal with hidden form fields in 2nd and 3rd pages. All you'll need to pass is the id of pending record. You'll just need to update record status to "active" once the data is confirmed.
Use client side paginated from (all popular JS frameworks have plugins for this). Hence you will only display different <div>s in single loaded page (something like an interface for a setup wizard).

Resources