(1) Start the process on the server to do the work. Immediately return a page that has a Javascript refresh (or a meta refresh) that calls another job on the server to check the status and return the same waiting page. Make the "refresh" interval a couple of seconds. This won't abort the work process, but at least you could do things like calculate a percentage complete. Sometimes just giving the user the impression of work being done is enough to grant them a few more seconds of patience.
(2) You might consider running your app in a separate window. The first page you hit when someone goes to the site is let's say index.htm. This page can be nothing more but Javascript to immediately open a new window, and you can do so without the command bar or menus, thereby removing the possibility of the user clicking Stop. They can still generally do that with keyboard shortcuts, but it'll eliminate probably most users from doing it.
(3) If your site runs in frames already, or if you can change it to frames, you could have a hidden frame (just set it's size to 0). Have the hidden frame constantly checking the status of the main frame's document via Javascript. Before submitting the form to do the database query, set a flag in that hidden frame that tells it you are going to do the query. Then, when the main page returns the results, clear the flag in the hidden frame. All the while, have the hidden frame checking the status of the main frame, and when it sees that it's done loading, check if it was a complete query result (by checking the flag that the main frame sets upon return) or an aborted query (which I *THINK* will happen when you hit stop, but that return flag wasn't set). When this condition arises, call a process on the server to terminate the query operation.
The common thread here of course is you will almost certainly need some sort of client-side scripting, or an applet as someone else suggested. As I recall, the newest HTTP spec actually DOES allow for bi-directional communications between servers and clients, and that would open up some other possibilities (sort of like event handlers on one side or the other). I don't think this helps you now of course, just an interesting side note.
Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies www.omnytex.com
From: Woodchuck <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: struts <[EMAIL PROTECTED]> Subject: detecting form data changes? Date: Mon, 13 Sep 2004 10:05:40 -0700 (PDT)
hihi all,
what is the best way to detect changes on a form without using any client side methods?
i have a very typical requirement to implement something that could warn the user that they made changes to the form but have not saved yet these changes yet.
is the only way to do this by keeping a copy of the last saved form data in session and then comparing this with the form data?
can anyone share any good strategies for doing this? i'd like to avoid any client side code as much as possible, but is this a good case for using javascript?
any comments/opinions welcome!
please and thanks, woodchuck
_______________________________ Do you Yahoo!? Shop for Back-to-School deals on Yahoo! Shopping. http://shopping.yahoo.com/backtoschool
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Check out Election 2004 for up-to-date election news, plus voter tools and more! http://special.msn.com/msn/election2004.armx
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
