I am currently creating a ASP.Net MVC 3.0 # order processing application. The application allows users to add products to their order, add a payment and then submit the order.
I am currently at the phase of submitting the order. I looking for suggestions as to how to achieve the following. A users clicks the submit button to submit the order. At this point I would like a processing icon to display while the order is processed, if an error occurs user gets redirected to a payment page, if processing completes successfully, redirect to the confirmation page.
What I was thinking of doing is, when the submit button is pressed, a View is returned to the user containing the processing icon, while in the background via an async Task or async controller, the order is processing and when complete, a redirect occurs to the applicable page. Does this sound like the best way achieving such?
Next question I have on this, what is the best way to prevent double submitting eg. user pressing the F5 key in the web browser?
Finally my last question, as order processing handles a number of events I may need to make it transactional, one fails all fail etc. What is the best way of achieving this?
Use can use AJAX.BeginForm. It will alllow for asynchronous post avoiding a post back until the onsuccess method is fired.
Here is post with an example.
Using Ajax.BeginForm with ASP.NET MVC 3 Razor
Good luck
Related
I have a new message page that can only be accessed if you are replying to a message or you click to message a user (unless of course you guess the URL). The cancel button currently will send you back to the previous page you were on using javascript:history.back().
I'm wondering if this is the best practice or if I should be using something on the server side to set where the cancel button takes you.
I took a look at this similar question: Does using javascript:history.back(); have any unknown issues?
I don't understand the cache problem mentioned in that post or the javascript being disabled because the site has a lot of javascript that this feature would be the least of the concern if the user does not have javascript. I'm also not too worried about the user not having a page to go back to because as I said, this new message page can only be accessed by clicking on a button on a site unless you guess the URL or copy the URL into a new window.
I'm wondering if there's any other issues on doing it one way or another.
Thanks!
Well, one issue you did mention was when the user types in the URL? Maybe we're crazy, and/or hate buttons! Joking aside, using history.back is mainly frowned upon due to its static nature (who knows if there is a page to go back to).
What the guy is trying to say in the link you provided about caching is that, for example, say you had a sign in page. If you hit your button using history.back, the browser would use a cached version of the webpage, and in turn, clear out anything you filled in. It would also show that you weren't logged in on the users end.
If you do have server side logic. I think your best bet in this case would be to just put in an windows.location.href to your previous page. That way, this issue is resolved, and you know exactly where the user is going.
Actually i am getting a dataset from DB but it is consuming sometime (>1 minutes).
So i use ajax to run asynchronously to check whether the dataset has returned result and at the same time displaying a waiting page.
However , for times, if the user want to navigate to other page instead of waiting the returned result, is there anyone who can give
me a hint on doing that?
I would first try to optimize your query from the database. Any query that is running > 1 minute is is either ridiculously huge (which you could implement pagination to circumvent) ... or is in need of some optimizing perhaps even the indexing on the tables as well.
If that still doesn't yield fast enough response times then here are two approaches for your problem:
Whenever the user wants to hit this long running query, run it in a pop up window. This will allow the user to continue navigation in the main web app.
Take your pages and start showing them in an iframe. You can then make the request in the parent frame while the user is navigating other pages (which are being loaded in the child frame). Since the parent frame won't be reloaded in this scenario, the ajax request can complete uninterrupted in the parent frame.
Whatever the scripts and codes your are using in this scenario will not help you!
Better optimize your Database model.
create tables with clustered index.
use stored procedure,
if that too slow create your own Function and Views.
Users will not view more than 10,000 records on a single page. Depends on the process can restrict your data and its optional.... but not the right way!
Once you have sent any request you cannot stop it or navigate when loader is running up.
for Asynchronous data Processing Loader (waiting page) is not Required.
Try this hope It will Help....
I need to ask the user if he/she wants to continue an operation (say, save operation).
So, after the user clicks the Save button, some stuff is checked on the server side. If one condition is met, the user must be asked if he/she wants to proceed.
Based on user's answer, the postback should be automatically performed carrying the user's reponse back to the server, so the server will now ask again. Is it possible to do it?
Thanks.
EDIT:
To be more specific, I want this:
The user clicks Save button. The postback is performed
I need to make some validations/checks on SERVER SIDE (this is important!)
In the middle of the postback I want to stop if a certain condition is met and ask the user if he/she really wants to continue.
If the user clicks Yes, I need to re-post the request, but now I need to carry the user's response.
If that "certain condition" is met again, I will just ignore it because the user wanted that.
So the solution to add the confirmation dialog right when the button is pressed is not an option because the checks are not simple and require some complex stuff involved (impossible to do it on client side).
Ajax/JS/Telerik, all OK.
You can use
btnExample.Attributes.Add("onclick", "javascript:return confirm('continue?')";
just one of the options...
EDIT:
for your needs you will want to use AJAX, call a method on the server and upon callback open the confirm window.
2nd Edit:
if the server side work isn't long I would this using AJAX.
AJAX works asynchronously and you want a synchronous procedure, right?
instead of posting back, call an AJAX method from the javascript, which will look something like this:
Service.ProccessRequest(data, OnSucceedJSFunction, OnFailJSFunction);
this way when the server side method finishes the OnSucceedJSFunction on the JS will be called.
in this function you can do something like
if (confirm('are you sure?'))
{
call another server method...
}
if you need to resend the data to the same server side method or to another server side method you can do this again and call a different OnSucceed js function.
Im not sure though about what you want to happen at the end of all the procedure...
Quick and dirty is to use javascript confirm function, tons of example on how to avoid the postback when user clicks cancel or ok.
if you need better ui control surely you can use javascript / jquery or whatever to show a nice dialog box and prevent the postback to happen or invoke it.
If non-JS users do not bother you then something like jQuery or AjaxControlToolkit could provide a modal popup solution.
If you are conscious or perhaps work for a company that needs to provide non-JS solutions then you could consider sending the user to another page asking for confirmation, you could carry any relevant info in either the Session or the Query String.
Let say...
If we ASP.net banking application. When user press a button then it will debit $100 from his account.
Issue:
What happened if user two or three times click on this button without waiting for first inform or it press F5/refresh page.
How we can prevent or get data integrity.
If you are using any ASP.Net ajax, Postback Ritalin will help prevent multiple postbacks.
The easiest way to prevent users from submitting the same form multiple times is to simply disable the button, posting your form back. That way they can't accidentaly re-submit it before the page gets processed.
Also, passing through a random piece of string alongside with the other form variables can help you as well. In that case you could compare the string (alongside with other information) to see if previously you've processed a request that had matching details.
Am guessing/hoping this is an exam question of some kind?
Anyways, here a couple of pointers;
look into transactions (for the sum to add up) and perhaps optimistic concurrency (to avoid changing what have been updated by others)
good luck!
BR
Daniel
I have an ASP.NET (C#) page that has a long load time (like 2 minutes). The user is presented with a little animation and a "please wait" message. If the user accidentally loads this page, they need to wait for it to load.
My question is: Is there a way to stop the page load?
Thank you
If you want to stop the server side processing then its a tricky operation. Generally once a request is made that page is rendering on its own independant of other thigns going on. What you would probably need to do is re-engineer that page to check at regular intervals whether a stop command has been issued and abort whatever it is doing at that point. The stop flag could be put in session and should be cleared out after the stoppage.
You may also need to consider how to properly identify the right one to stop (in case there is more than one running). This could be done by returning a unique ID that can be used in part of a call to the "abort" page.
My approach though rather than this complciated rigmarole is to make efforts to stop the user from making this accident. Possibly make whatever link they are clicking pop up an alert saying "the following page will take several minutes to render, do you wish to continue" and then hopefully you will effectively be aborting the page request before it is even made.
I should note that I've never tried to do this sort of thing before so there may be easier ways to do it but this is how I'd probably think abotu going about the problem.
Try window.stop() in JavaScript.