bkhong
asked on
Is it possible to control whether to reload a page after saving the data on a web page to the database
Typically in a web application, a user can save the data entered on a web page by clicking the SAVE/SUBMIT button whereby the data is saved to the database, while the user can remain to perform further edits on the page.
In terms of the standard request-response sequence with the web browser, does the response always automatically refresh the page (using latest data from the database) ?
Can this sequence be altered such that the page is not automatically reloaded, as a means to minimise traffic from the web server to browser ?
The preferred sequence of control is as follows :-
1) browser sends request to save data to the database via the web server (triggered by the user clicking SAVE/SUBMIT button.
2) while the database transation is in progress, the SAVE/SUBMIT button on the browser should be disabled (to prevent user inadventently initiating excessive database SAVE transactions), and preferreably the web server provides a work in progress indication (eg. hourglass or message) for the browser
3) when the database SAVE transaction has completed, the web server provides a response by removing the work in progress signal on the browser and re-enble the SAVE/SUBMIT button, but not reloading the entire page.
Will such a sequence minimise the traffic between browser & server ? We have remote users on low bandwidth accessing the web applications and we want ot xplore means to reduce data traffic to the browser.
In terms of the standard request-response sequence with the web browser, does the response always automatically refresh the page (using latest data from the database) ?
Can this sequence be altered such that the page is not automatically reloaded, as a means to minimise traffic from the web server to browser ?
The preferred sequence of control is as follows :-
1) browser sends request to save data to the database via the web server (triggered by the user clicking SAVE/SUBMIT button.
2) while the database transation is in progress, the SAVE/SUBMIT button on the browser should be disabled (to prevent user inadventently initiating excessive database SAVE transactions), and preferreably the web server provides a work in progress indication (eg. hourglass or message) for the browser
3) when the database SAVE transaction has completed, the web server provides a response by removing the work in progress signal on the browser and re-enble the SAVE/SUBMIT button, but not reloading the entire page.
Will such a sequence minimise the traffic between browser & server ? We have remote users on low bandwidth accessing the web applications and we want ot xplore means to reduce data traffic to the browser.
ASKER
thanx cd&
1) so with the disconnected nature of HTTP, it is not feasible to report progress on DB updates even for an intranet web appl when bandwidth is not an issue ?
2) as for the standard request-response sequence, if we just let the server reloads the (submitted) page, the visual content of the page is the same and the user cannot readily tell if the DB update has completed.
Also to prevent the user clicking save excessively, is it ok to implement something like what is suggested in the link //aspzone.com/artiles/207.
1) so with the disconnected nature of HTTP, it is not feasible to report progress on DB updates even for an intranet web appl when bandwidth is not an issue ?
2) as for the standard request-response sequence, if we just let the server reloads the (submitted) page, the visual content of the page is the same and the user cannot readily tell if the DB update has completed.
Also to prevent the user clicking save excessively, is it ok to implement something like what is suggested in the link //aspzone.com/artiles/207.
It is possible even on the internet, but it means you have to have something to keep sending across to the server for the uspdated status. An applet, activex control, or scripting in a hidden from. It would also require additional coding on the server to response to the requests after determining the status on the request activitiy. the lag time means it would not be particularly accurate. Generally when such status reporting is considered it is because there is a prformance problem, and any method used is going to make the response time even worse so it is not something commonly don with web clients, even for intranet apps.
The only problem I see with the disabling approach is if you have a lot of form validation to do, then disabling could get in the way. As for the page coming back; you have control of what gets sent as a response. Just put a message on the page that indicates whether or not the update was successful.
This is really a very straight forward operation it is done millions of times every day. There is no gain in looking for ways to turn it into something complicated. The server gets the form; The form is parsed and the database is updated; a response gets generated based on the result; the page gets sent back to the client. Millions of times every day that happens on all kinds of sites including this one. Am I missing something that reequires som additional level of complexity?
Cd&
The only problem I see with the disabling approach is if you have a lot of form validation to do, then disabling could get in the way. As for the page coming back; you have control of what gets sent as a response. Just put a message on the page that indicates whether or not the update was successful.
This is really a very straight forward operation it is done millions of times every day. There is no gain in looking for ways to turn it into something complicated. The server gets the form; The form is parsed and the database is updated; a response gets generated based on the result; the page gets sent back to the client. Millions of times every day that happens on all kinds of sites including this one. Am I missing something that reequires som additional level of complexity?
Cd&
ASKER
thanx cd&.
You're right, I was too ambitious to look for a solution that :-
1) can stop a user clicking excessive saves while waiting for respsone in a low bandwidth situation
2) in the meantime keeping the user informed that work is in progress
the disabling is sort of an approach but as you point out with some complications. Agree that your suggestion of using the standard approach of adding a message to the returned page will suffice.
As you can see, I'm very green in this and just appreciate another couple of expert advice and I'll close the call :-
1) as a matter of interest, the disabling approach is directed at the one button, and appeared to me as client script (javascript ?), how come it adversely affects the rest of form validations
2) to implement a simple alert for a user who attempts to navigate away from a web page after updates but forget to save them, is that mainly under client side or server side control
You're right, I was too ambitious to look for a solution that :-
1) can stop a user clicking excessive saves while waiting for respsone in a low bandwidth situation
2) in the meantime keeping the user informed that work is in progress
the disabling is sort of an approach but as you point out with some complications. Agree that your suggestion of using the standard approach of adding a message to the returned page will suffice.
As you can see, I'm very green in this and just appreciate another couple of expert advice and I'll close the call :-
1) as a matter of interest, the disabling approach is directed at the one button, and appeared to me as client script (javascript ?), how come it adversely affects the rest of form validations
2) to implement a simple alert for a user who attempts to navigate away from a web page after updates but forget to save them, is that mainly under client side or server side control
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
thanx very much cd& for your expert advice to educate me,
appreciate your microslop humour, we here refer to it as M$
appreciate your microslop humour, we here refer to it as M$
Glad I could help. Thanks for the A. :^)
Cd&
Cd&
Cd&