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.

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The server has to respond with something.  This could be a simple, small page with a success message an a button to reload the page.  If the page is static and the user is allowing cahing, then the page will get reloaded from cache without have to go back to the server.  if you have a low bandwidth problem you do not want to even think about truing to report progress during database updates.  The only way to do that reliabley is with an open pipe and continuous traffic.

bkhongAuthor Commented:
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   //   and can you pls advise any downside with such an approach ?
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?

Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

bkhongAuthor Commented:
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

1) Normally if you have client side validations that fail it would require re-entry by the user and the form would not get submitted until they correct the data and re-submit.  A disable submit buton would prevent them from doing that so the validation code requires additional coding to re-enable the disabled submit.  Depending on oncomplex the validations are, and how well written the routines are, it could be a lot or a little code to incorproate the disabling functionality.

2) It is strictly client side.  There is no way for the server to detect that the user has left the site.  On the client you can attempt to fire a beforeunload event to alert the user but it is unreliable, and will irritate most users:

Before exiting you can do this!   IE only!!!

window.onbeforeunload=afunction;  //notice no arguments

function afunction()
  // statements you want to execute
  return "message";    //if a text string is returned it will be used
}                      //for a dialog box

The event cannot be trigger from an HTML tag, the event
call has to go in the HEAD of the document

I do not recommend this.  It is non-standard, unreliable, browser specific, ans subject to change by Microslop without notice.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
bkhongAuthor Commented:
thanx very much cd& for your expert advice to educate me,

appreciate your microslop humour, we here refer to it as M$

Glad I could help.  Thanks for the A. :^)

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Web Browsers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.